From report at bugs.python.org  Thu Mar  1 00:17:50 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Thu, 01 Mar 2018 05:17:50 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519881470.89.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Mark, you have some good ideas. A fraction modulo a float is a float, and an integer modulo infinity produces itself as a float, so it seems reasonable that a fraction modulo infinity should be itself converted to a float.

I tried assigning __mod__ and __rmod__ using _operator_fallbacks, like most of the binary operators, and calculations involving infinity behaved as I expected, but one test failed (1.0 % Fraction(1, 10) was no longer 0 because of rounding error).

But then I tried assigning only __mod__ using _operator_fallbacks, and leaving __rmod__ alone, and all the tests passed (including some ones I added to make sure that modulo calculations involving infinity behave like both of us think they should).

As for the floordiv operator, I'm not sure what to think. It would be a bit strange if mod with a float returns a float and floordiv with a float returns an int. It wouldn't be a big deal IMO but it may be easy to change. I tried a simple change to make floordiv with a float to return a float, and changed one test to make sure that it works, and all of the tests passed.

I can make a pull request if anyone wants.

----------

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

From report at bugs.python.org  Thu Mar  1 00:44:18 2018
From: report at bugs.python.org (Abhilash Raj)
Date: Thu, 01 Mar 2018 05:44:18 +0000
Subject: [issue32975] mailbox: It would be nice to move mailbox.Message from
 legacy email.message.Message API to new EmailMessage API
Message-ID: <1519883058.82.0.467229070634.issue32975@psf.upfronthosting.co.za>


New submission from Abhilash Raj <raj.abhilash1 at gmail.com>:

Since Python 3.6 the new EmailMessage API seems to be the default but mailbox.Message still subclasses from the old email.message.Message API.

It would be nice to get EmailMessage from mailbox so that one can rely on the new methods and content managers. Also, while it is possible to  pass a constructor to mailbox.mbox to get the new EmailMessage style message, it is different from mailbox.Message which has some extra methods.

----------
components: email
messages: 313082
nosy: barry, maxking, r.david.murray
priority: normal
severity: normal
status: open
title: mailbox: It would be nice to move mailbox.Message from legacy email.message.Message API to new EmailMessage API
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar  1 01:00:32 2018
From: report at bugs.python.org (Abhilash Raj)
Date: Thu, 01 Mar 2018 06:00:32 +0000
Subject: [issue32975] mailbox: It would be nice to move mailbox.Message from
 legacy email.message.Message API to new EmailMessage API
In-Reply-To: <1519883058.82.0.467229070634.issue32975@psf.upfronthosting.co.za>
Message-ID: <1519884032.01.0.467229070634.issue32975@psf.upfronthosting.co.za>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

I should also mention probably that I went ahead and made changes to make this work and I can pass most of the tests, one is failing due to missing `\n` character in the header's value obtained from `msg.get_all('Received')`.

I can make a pull request on Github if that would be a good place to start the discussion instead.

----------

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

From report at bugs.python.org  Thu Mar  1 01:10:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 06:10:13 +0000
Subject: [issue32056] Improve exceptions in Lib/wave.py
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519884613.3.0.467229070634.issue32056@psf.upfronthosting.co.za>


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

I have no idea why this was classified as a vulnerability. I don't think it can crash an application. If you have an example of crashing please provide it.

I would not classify this issue even as a bug. It is obvious that invalid files can cause an exception. It may be good to detect some of errors earlier and raise more specific exception (Error would be more appropriate here than ValueError). But in general validating the wave file is not the purpose of this module, and this task can't be performed without reading the whole file, not only the header.

All changes in wave.py should be ported to aifc.py and sunau.py and needs tests.

----------
title: bug in Lib/wave.py -> Improve exceptions in Lib/wave.py
type: crash -> enhancement
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Thu Mar  1 03:12:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 08:12:06 +0000
Subject: [issue27069] webbrowser creates zombi processes in the background mode
In-Reply-To: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>
Message-ID: <1519891926.53.0.467229070634.issue27069@psf.upfronthosting.co.za>


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

Isn't this a duplicate of issue5993?

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

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

From report at bugs.python.org  Thu Mar  1 04:14:04 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 01 Mar 2018 09:14:04 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519895644.83.0.467229070634.issue32903@psf.upfronthosting.co.za>


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


New changeset 3e197c7a6740d564ad52fb7901c07d5ff49460f5 by Xiang Zhang (Alexey Izbyshev) in branch 'master':
bpo-32903: Fix a memory leak in os.chdir() on Windows (GH-5801)
https://github.com/python/cpython/commit/3e197c7a6740d564ad52fb7901c07d5ff49460f5


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

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

From report at bugs.python.org  Thu Mar  1 04:15:10 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 01 Mar 2018 09:15:10 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519895710.46.0.467229070634.issue32903@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5713

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

From report at bugs.python.org  Thu Mar  1 04:17:07 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 01 Mar 2018 09:17:07 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519895827.62.0.467229070634.issue32903@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5714

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

From report at bugs.python.org  Thu Mar  1 04:37:53 2018
From: report at bugs.python.org (zhangdeyue)
Date: Thu, 01 Mar 2018 09:37:53 +0000
Subject: [issue32056] Improve exceptions in Lib/wave.py
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519897073.07.0.467229070634.issue32056@psf.upfronthosting.co.za>


zhangdeyue <abcdyzhang at 163.com> added the comment:

ok, I found this bug when I use librosa-0.5.1 to read audio file in the audio-classification project -- an ASR project. (https://github.com/nextco/audio-classification)

In the project, librosa.load function read audio file, and it called wave.open function finally. But all of the functions don't validate the audio file which lead to the project dividing by zero. 

Although the bug is easy and small, I think the bug should be fixed because there are so many python-library(such as librosa, audioread) use it without validation in more and more popular ASR project.

My program backtrace is as follow:
https://github.com/BT123/testcasesForMyRequest/blob/master/wave-1.png
https://github.com/BT123/testcasesForMyRequest/blob/master/wave-2.png

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

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

From report at bugs.python.org  Thu Mar  1 04:41:05 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 01 Mar 2018 09:41:05 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519897265.25.0.467229070634.issue32903@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
pull_requests: +5715

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

From report at bugs.python.org  Thu Mar  1 04:50:28 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Mar 2018 09:50:28 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519897828.1.0.467229070634.issue32968@psf.upfronthosting.co.za>


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

> It would be a bit strange if mod with a float returns a float and floordiv with a float returns an int.

Agreed: if there are floats involved (Fraction // float or float // Fraction), I think the rule should be that we simply fall back to float behaviour, and do whatever float // float does - i.e., return a float. (I'd actually prefer that a mixed Fraction-float operation be a TypeError, but that ship sailed long ago.)

OTOH, if there's a test that's explicitly checking that `my_fraction // my_float` returns something of type `int`, then the behaviour is clearly intentional. That means that we should be cautious about changing it, and also means that we probably can't change it in 3.6 or 3.7; it'll have to wait for 3.8. (But I think that's fine; this seems like a minor consistency cleanup that I would expect to affect very few people.)

It looks as though this was a part of PEP 3141 that was never fully implemented: the "Real" type there has a __floordiv__ method that looks like this:

    @abstractmethod
    def __floordiv__(self, other):
        """The floor() of self/other. Integral."""
        raise NotImplementedError

But float // float does *not* currently return an Integral:

    >>> import numbers
    >>> x = 2.3
    >>> isinstance(x, numbers.Real)
    True
    >>> isinstance(x // x, numbers.Integral)
    False

And that definitely shouldn't change: I'd argue against such a change in any case, but backwards compatibility considerations alone mean that we shouldn't change this now to return an integer. Given that, I think it's acceptable to have a mixed fraction-float floor division return a float.

A pull request would be great. Yes, please!

----------

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

From report at bugs.python.org  Thu Mar  1 05:01:22 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Mar 2018 10:01:22 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519898482.22.0.467229070634.issue32968@psf.upfronthosting.co.za>


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

> I'd argue against such a change in any case

And apparently I already did: see issue 22444 for previous discussion on the topic.

----------

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

From report at bugs.python.org  Thu Mar  1 05:27:36 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 01 Mar 2018 10:27:36 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519900056.91.0.467229070634.issue32903@psf.upfronthosting.co.za>


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


New changeset aa40f92240adea7067c3add8e09cec09dcf24d7f by Xiang Zhang (Alexey Izbyshev) in branch '2.7':
[2.7] bpo-32903: Fix a memory leak in os.chdir() on Windows (GH-5801). (#5947)
https://github.com/python/cpython/commit/aa40f92240adea7067c3add8e09cec09dcf24d7f


----------

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

From report at bugs.python.org  Thu Mar  1 05:28:43 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 01 Mar 2018 10:28:43 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519900123.79.0.467229070634.issue32903@psf.upfronthosting.co.za>


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


New changeset 6ae75d9d1221459ab18c2599e42fcc45f9f65617 by Xiang Zhang (Miss Islington (bot)) in branch '3.7':
bpo-32903: Fix a memory leak in os.chdir() on Windows (GH-5801) (#5945)
https://github.com/python/cpython/commit/6ae75d9d1221459ab18c2599e42fcc45f9f65617


----------

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

From report at bugs.python.org  Thu Mar  1 05:29:40 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 01 Mar 2018 10:29:40 +0000
Subject: [issue32903] os.chdir() may leak memory on Windows
In-Reply-To: <1519259862.55.0.467229070634.issue32903@psf.upfronthosting.co.za>
Message-ID: <1519900180.07.0.467229070634.issue32903@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

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

From report at bugs.python.org  Thu Mar  1 06:03:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 11:03:33 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519902213.28.0.467229070634.issue32968@psf.upfronthosting.co.za>


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

Not all Fractions can be converted to float.

>>> Fraction(2**2000, 3) // 1.0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/fractions.py", line 432, in __floordiv__
    return math.floor(a / b)
  File "/home/serhiy/py/cpython/Lib/fractions.py", line 378, in forward
    return fallback_operator(float(a), b)
  File "/home/serhiy/py/cpython/Lib/numbers.py", line 291, in __float__
    return self.numerator / self.denominator
OverflowError: integer division result too large for a float

What is surprising that the modulo operation can fail even if the end result could be converted to float.

>>> Fraction(2**2000, 3) % 1
Fraction(1, 3)
>>> Fraction(2**2000, 3) % 1.0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/fractions.py", line 440, in __mod__
    div = a // b
  File "/home/serhiy/py/cpython/Lib/fractions.py", line 432, in __floordiv__
    return math.floor(a / b)
  File "/home/serhiy/py/cpython/Lib/fractions.py", line 378, in forward
    return fallback_operator(float(a), b)
  File "/home/serhiy/py/cpython/Lib/numbers.py", line 291, in __float__
    return self.numerator / self.denominator
OverflowError: integer division result too large for a float

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

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

From report at bugs.python.org  Thu Mar  1 06:15:27 2018
From: report at bugs.python.org (Cyril Martin)
Date: Thu, 01 Mar 2018 11:15:27 +0000
Subject: [issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
In-Reply-To: <1517423175.51.0.467229070634.issue32732@psf.upfronthosting.co.za>
Message-ID: <1519902927.35.0.467229070634.issue32732@psf.upfronthosting.co.za>


Cyril Martin <mcoolive at gmail.com> added the comment:

Hello Vinay,

I strongly disagree with you. In the Python documentation (https://docs.python.org/3/library/logging.html), we can read the following for the debug function:

> The third keyword argument is extra which can be used to pass a dictionary
> which is used to populate the __dict__ of the LogRecord created for the
> logging event with user-defined attributes.

It never says 'BUT IF you use the LoggerAdapter'. So the current behavior differs from what is explained in the documentation: there is an issue.

By the way, I don't ask to fix the documentation, I prefer a consistent logging API. I simply cannot think a use case where we want extras of the logging statement be ignored.

Regards,

----------

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

From report at bugs.python.org  Thu Mar  1 07:06:40 2018
From: report at bugs.python.org (Segev Finer)
Date: Thu, 01 Mar 2018 12:06:40 +0000
Subject: [issue32818] multiprocessing segmentfault under Windows compatibility
 mode
In-Reply-To: <1518323274.11.0.467229070634.issue32818@psf.upfronthosting.co.za>
Message-ID: <1519906000.37.0.467229070634.issue32818@psf.upfronthosting.co.za>


Segev Finer <segev208 at gmail.com> added the comment:

Windows seems to dereference lpStartupInfo->lpAttributeList, despite it being NULL since we had no attributes to set. Smells like a Windows bug in the compatibility shim, since it doesn't crash in non compatibility mode.

Not setting EXTENDED_STARTUPINFO_PRESENT when lpStartupInfo->lpAttributeList is NULL will fix this. Not sure about lpStartupInfo->cb, I think Windows only checks it's large enough.

Also attached is a crash dump with symbols and used source revision of a reproduction of this.

Stack Trace:
00 00fee690 5ad47c1c AcLayers!NS_ElevateCreateProcess::APIHook_CreateProcessW+0x110
01 00fee740 5ad45f79 python38_d!_winapi_CreateProcess_impl+0x15c [cpython\modules\_winapi.c @ 1046]
02 00fee798 5ad78e75 python38_d!_winapi_CreateProcess+0x79 [cpython\modules\clinic\_winapi.c.h @ 326]
03 00fee7f8 5ad77b64 python38_d!_PyMethodDef_RawFastCallKeywords+0x245 [cpython\objects\call.c @ 651]
04 00fee81c 5aed8f9f python38_d!_PyCFunction_FastCallKeywords+0x84 [cpython\objects\call.c @ 730]
05 00fee854 5aee038f python38_d!call_function+0x15f [cpython\python\ceval.c @ 4532]
06 00fee8f4 5ad7b336 python38_d!_PyEval_EvalFrameDefault+0x59bf [cpython\python\ceval.c @ 3128]
07 00fee92c 5ad77ce4 python38_d!function_code_fastcall+0xe6 [cpython\objects\call.c @ 283]
08 00fee994 5ad79be7 python38_d!_PyFunction_FastCallDict+0x134 [cpython\objects\call.c @ 322]
09 00fee9d8 5ad79aa6 python38_d!_PyObject_FastCallDict+0xc7 [cpython\objects\call.c @ 98]
0a 00feea14 5ae0b8f7 python38_d!_PyObject_Call_Prepend+0xf6 [cpython\objects\call.c @ 904]
0b 00feea50 5ae10a97 python38_d!slot_tp_init+0x47 [cpython\objects\typeobject.c @ 6597]
0c 00feea74 5ad7a28e python38_d!type_call+0x187 [cpython\objects\typeobject.c @ 949]
0d 00feeae0 5aed91d1 python38_d!_PyObject_FastCallKeywords+0x37e [cpython\objects\call.c @ 199]
0e 00feeb18 5aedc95b python38_d!call_function+0x391 [cpython\python\ceval.c @ 4576]

----------
Added file: https://bugs.python.org/file47465/crash32818.zip

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

From report at bugs.python.org  Thu Mar  1 07:07:25 2018
From: report at bugs.python.org (Segev Finer)
Date: Thu, 01 Mar 2018 12:07:25 +0000
Subject: [issue32818] multiprocessing segmentfault under Windows compatibility
 mode
In-Reply-To: <1518323274.11.0.467229070634.issue32818@psf.upfronthosting.co.za>
Message-ID: <1519906045.0.0.467229070634.issue32818@psf.upfronthosting.co.za>


Change by Segev Finer <segev208 at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  1 07:52:50 2018
From: report at bugs.python.org (Mike Schmidt)
Date: Thu, 01 Mar 2018 12:52:50 +0000
Subject: [issue32976] linux/random.h present but cannot be compiled
Message-ID: <1519908769.96.0.467229070634.issue32976@psf.upfronthosting.co.za>


New submission from Mike Schmidt <mikeschmidt at schmidtgracen.com>:

I am attempting to install python 3.6.4 to my home directory on a linux cluster where I do not have root access. A warning, "linux/random.h present but cannot be compiled", was emitted from the config process requesting that I report this here. A summary of commands used follows:

    $ wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tar.xz
    $ tar -xvf Python-3.6.4.tar.xz
    $ cd Python-3.6.4.tar.xz
    $ mkdir ~/python364
    $ ./config --prefix /home/mikes/python364 --enable-optimizations

The following may also be relevant:

    $ uname -a
Linux JJM4 2.6.18-308.el5 #1 SMP Tue Feb 21 20:06:06 EST 2012 x86_64 x86_64 x86_64 GNU/Linux

And the config.log is attached.

----------
components: Build
files: config.log
messages: 313095
nosy: mfschmidt
priority: normal
severity: normal
status: open
title: linux/random.h present but cannot be compiled
type: compile error
versions: Python 3.6
Added file: https://bugs.python.org/file47466/config.log

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

From report at bugs.python.org  Thu Mar  1 09:54:50 2018
From: report at bugs.python.org (Aaron Christianson)
Date: Thu, 01 Mar 2018 14:54:50 +0000
Subject: [issue32977] added acts_like decorator to dataclasses module
Message-ID: <1519916090.48.0.467229070634.issue32977@psf.upfronthosting.co.za>


New submission from Aaron Christianson <ninjaaron at gmail.com>:

I'm always writting these wrapper classes where I want to selectively want to expose the interface of some of the methods of certain attributes to co the containing object. This can mean I spend a lot of time implementing wrapper methods. That's no good. I wrote a class decorator to make this easy, and I realized it's a perfect complement to the new dataclasses module, though it can also be used with normal classes. I figured I'd check if you're interested in that. The interface looks like this:

>>> from dataclasses import dataclass, acts_like
>>> @acts_like('weight', ['__add__'])
... @acts_like('still_fresh', ['__bool__'])
... @dataclass
... class Spam:
...     weight: int
...     still_fresh: bool
>>> s = Spam(42, False)
>>> s + 3
45
>>> if not s:
...     print('the spam is bad')
the spam is bad

It's a handy way to build objects with composition, but still get some of the benefits of inheritance in a *selective* and *explicite* way.

Here's the code: https://github.com/ninjaaron/cpython/blob/acts_like/Lib/dataclasses.py#L978

May require some addtional twiddling to make it work with frozen dataclasses, but I don't think it should be a problem.

----------
components: Library (Lib)
messages: 313096
nosy: eric.smith, ninjaaron
priority: normal
severity: normal
status: open
title: added acts_like decorator to dataclasses module
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Thu Mar  1 10:52:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 15:52:24 +0000
Subject: [issue32056] Improve exceptions in Lib/wave.py
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519919544.61.0.467229070634.issue32056@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5717

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

From report at bugs.python.org  Thu Mar  1 11:00:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 16:00:55 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519920055.57.0.467229070634.issue32056@psf.upfronthosting.co.za>


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

PR 5951 adds explicit checks for the number of channels and sample width when read audio files in aifc, sunau and wave and converts some struct.error to EOFError when the file is truncated in wave.

This change can break an existing code that currently successfully opens corrupted audio files and read only headers, but not audio samples. Therefore it is safer to not backport it, even if classify this issue as a bug.

----------
title: Improve exceptions in Lib/wave.py -> Improve exceptions in aifc, sunau and wave
versions: +Python 3.8

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

From report at bugs.python.org  Thu Mar  1 11:50:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 16:50:35 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
Message-ID: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

The frequency rate is saved as a 80-bit floating point value in AIFC files. There are issues with reading large values.

1. Values with maximal exponent are read as aifc._HUGE_VAL which is less then sys.float_info.max. Thus greater values can be read as lesser values.

>>> aifc._read_float(io.BytesIO(b'\x7f\xff\xff\xff\xff\xff\xff\xff\xf8\x00'))
1.79769313486231e+308
>>> aifc._read_float(io.BytesIO(b'\x43\xfe\xff\xff\xff\xff\xff\xff\xf8\x00'))
1.7976931348623157e+308
>>> aifc._read_float(io.BytesIO(b'\x43\xfe\xff\xff\xff\xff\xff\xff\xff\xff'))
inf

2. If exponent is not maximal, but large enough, this cause an OverflowError. It would be better consistently return the maximal value or inf.

>>> aifc._read_float(io.BytesIO(b'\x44\xfe\xff\xff\xff\xff\xff\xff\xf8\x00'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.7/Lib/aifc.py", line 198, in _read_float
    f = (himant * 0x100000000 + lomant) * pow(2.0, expon - 63)
OverflowError: (34, 'Numerical result out of range')

OverflowError when read a broken aifc file can be unexpected.

The proposed PR tries to make reading floats more consistent. I'm not sure it is correct.

----------
components: Library (Lib)
messages: 313098
nosy: mark.dickinson, serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: Issues with reading large float values in AIFC files
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/issue32978>
_______________________________________

From report at bugs.python.org  Thu Mar  1 11:52:09 2018
From: report at bugs.python.org (Felix)
Date: Thu, 01 Mar 2018 16:52:09 +0000
Subject: [issue32979] dict get() function equivalent for lists.
Message-ID: <1519923129.67.0.467229070634.issue32979@psf.upfronthosting.co.za>


New submission from Felix <felix at meyerwolters.de>:

Hi there!

I hope this wasn't suggested before. I couldn't find any issues related to it.

The `get()` function on the dictionary object is such a convenient way for retrieving items from a dict that might not exists. I always wondered why the list object does not have an equivalent?

I constantly run into something like this:

    myval = mylist[1] if len(mylist) > 1 else None

or worse like this:

    try:
        myval = mylist[1]
    except IndexError:
        myval = None

While I think it would be nice to do it like this:

    myval = mylist.get(1)

Any love for this?

Cheers! :)

----------
messages: 313099
nosy: feluxe
priority: normal
severity: normal
status: open
title: dict get() function equivalent for lists.
type: enhancement

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

From report at bugs.python.org  Thu Mar  1 11:53:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 16:53:30 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1519923210.58.0.467229070634.issue32978@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar  1 11:57:13 2018
From: report at bugs.python.org (Thomas Nyberg)
Date: Thu, 01 Mar 2018 16:57:13 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
Message-ID: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>


New submission from Thomas Nyberg <tomnyberg at gmail.com>:

The `_PyFrame_Init()` and `PyByteArray_Init()` functions are called in these two locations in the `_Py_InitializeCore()` function:

	https://github.com/python/cpython/blob/master/Python/pylifecycle.c#L693-L694
	https://github.com/python/cpython/blob/master/Python/pylifecycle.c#L699-L700

But their function definitions appear to do nothing:

	https://github.com/python/cpython/blob/master/Objects/frameobject.c#L555-L561
	https://github.com/python/cpython/blob/master/Objects/bytearrayobject.c#L24-L28

I can understand leaving the functions in the source for backwards-compatibility, but why are they still being called in `_Py_InitializeCore()`? Seems like it just adds noise for those new to the cpython internals (I certainly found it confusing myself).

Ned Batchelder recommended possibly making a change:

	https://mail.python.org/pipermail/python-list/2018-March/731402.html

----------
messages: 313100
nosy: thomas.nyberg
priority: normal
severity: normal
status: open
title: Remove functions that do nothing in _Py_InitializeCore()
type: enhancement

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

From report at bugs.python.org  Thu Mar  1 12:05:32 2018
From: report at bugs.python.org (Thomas Nyberg)
Date: Thu, 01 Mar 2018 17:05:32 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1519923932.02.0.467229070634.issue32980@psf.upfronthosting.co.za>


Change by Thomas Nyberg <tomnyberg at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  1 12:09:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 17:09:15 +0000
Subject: [issue32979] dict get() function equivalent for lists.
In-Reply-To: <1519923129.67.0.467229070634.issue32979@psf.upfronthosting.co.za>
Message-ID: <1519924155.51.0.467229070634.issue32979@psf.upfronthosting.co.za>


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

It was suggested a year ago. See the topic "get() method for list and tuples" on the Python-ideas mailing list.

https://mail.python.org/pipermail/python-ideas/2017-February/044839.html

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

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

From report at bugs.python.org  Thu Mar  1 13:12:46 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Mar 2018 18:12:46 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1519927966.85.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

I'm finding it hard to imagine why you'd ever have a sample rate greater than 1e308 in an audio file. (In fact, it's hard to imagine needing a sample rate greater than 1e6.) Raising an OverflowError for a value that's too large to fit in an IEEE 754 binary64 float seems entirely reasonable.

----------

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

From report at bugs.python.org  Thu Mar  1 13:16:16 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Mar 2018 18:16:16 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519928176.06.0.467229070634.issue32968@psf.upfronthosting.co.za>


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

Serhiy: I think both those results are reasonable, and not too surprising. It should be easy to understand that the mixed-type operation converts one of the arguments to float, and if that conversion overflows we get an exception. A similar thing happens when doing something like `math.sqrt(2**1024)`, even though the result is representable.

----------

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

From report at bugs.python.org  Thu Mar  1 13:47:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Mar 2018 18:47:01 +0000
Subject: [issue32979] dict get() function equivalent for lists.
In-Reply-To: <1519923129.67.0.467229070634.issue32979@psf.upfronthosting.co.za>
Message-ID: <1519930021.57.0.467229070634.issue32979@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Yes, this was discussed and rejected several years ago.

Thank you for the suggestion.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  1 13:48:12 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 01 Mar 2018 18:48:12 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1519930092.83.0.467229070634.issue15873@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:


New changeset 0e06be836ca0d578cf9fc0c68979eb682c00f89c by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7':
Add What's new entry for datetime.fromisoformat (GH-5559) (GH-5939)
https://github.com/python/cpython/commit/0e06be836ca0d578cf9fc0c68979eb682c00f89c


----------

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

From report at bugs.python.org  Thu Mar  1 13:50:17 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 01 Mar 2018 18:50:17 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1519930217.25.0.467229070634.issue15873@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/issue15873>
_______________________________________

From report at bugs.python.org  Thu Mar  1 13:58:05 2018
From: report at bugs.python.org (Felix)
Date: Thu, 01 Mar 2018 18:58:05 +0000
Subject: [issue32979] dict get() function equivalent for lists.
In-Reply-To: <1519923129.67.0.467229070634.issue32979@psf.upfronthosting.co.za>
Message-ID: <1519930685.61.0.467229070634.issue32979@psf.upfronthosting.co.za>


Felix <felix at meyerwolters.de> added the comment:

Thanks for the link! Interesting read.

I have to disagree with the statement that this is something that happens very rarely. Just have a look at the mess on stackoverflow alone (these are only the top results I got after a minute of googling):

https://stackoverflow.com/questions/5125619/why-doesnt-list-have-safe-get-method-like-dictionary

https://stackoverflow.com/questions/2492087/how-to-get-the-nth-element-of-a-python-list-or-a-default-if-not-available

https://stackoverflow.com/questions/2574636/getting-a-default-value-on-index-out-of-range-in-python

https://stackoverflow.com/questions/12186388/get-value-at-list-array-index-or-none-if-out-of-range-in-python

https://stackoverflow.com/questions/17721748/default-value-for-out-of-bounds-list-index

----------

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

From report at bugs.python.org  Thu Mar  1 14:01:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Mar 2018 19:01:43 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1519930903.68.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

I'm fine with an OverflowError, but it looks inconsistent to me that for some huge values an OverflowError is not raised, but aifc._HUGE_VAL is returned instead. And I think that using math.ldexp() can be more preferable that pow(2.0, ...), especially for exponent around sys.float_info.max_exp and sys.float_info.min_exp.

----------

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

From report at bugs.python.org  Thu Mar  1 14:19:31 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Mar 2018 19:19:31 +0000
Subject: [issue32937] Multiprocessing worker functions not terminating with a
 large number of processes and a manager
In-Reply-To: <1519481823.24.0.467229070634.issue32937@psf.upfronthosting.co.za>
Message-ID: <1519931971.31.0.467229070634.issue32937@psf.upfronthosting.co.za>


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

I don't know, maybe someone with a Mac wants to try and debug it?

----------

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

From report at bugs.python.org  Thu Mar  1 15:14:20 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 01 Mar 2018 20:14:20 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1519935260.75.0.467229070634.issue18855@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
versions: +Python 3.8 -Python 3.5

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

From report at bugs.python.org  Thu Mar  1 16:02:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Mar 2018 21:02:58 +0000
Subject: [issue30607] Extract documentation theme into a separate package
In-Reply-To: <1496981279.71.0.300273355047.issue30607@psf.upfronthosting.co.za>
Message-ID: <1519938178.39.0.467229070634.issue30607@psf.upfronthosting.co.za>


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


New changeset bf63e8d55fd2853df3bb99d66de7f428107aadb3 by Ned Deily (Jon Wayne Parrott) in branch 'master':
bpo-30607: Use external python-doc-theme (GH-2017)
https://github.com/python/cpython/commit/bf63e8d55fd2853df3bb99d66de7f428107aadb3


----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Mar  1 16:07:07 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Mar 2018 21:07:07 +0000
Subject: [issue30607] Extract documentation theme into a separate package
In-Reply-To: <1496981279.71.0.300273355047.issue30607@psf.upfronthosting.co.za>
Message-ID: <1519938427.21.0.467229070634.issue30607@psf.upfronthosting.co.za>


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

Thanks, Jon, and every one else who helped with and commented on the PR.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Thu Mar  1 16:09:23 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 01 Mar 2018 21:09:23 +0000
Subject: [issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW
 64-bit
In-Reply-To: <1494605988.92.0.550577143248.issue30353@psf.upfronthosting.co.za>
Message-ID: <1519938563.83.0.467229070634.issue30353@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  1 16:13:07 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Mar 2018 21:13:07 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519938787.98.0.467229070634.issue32056@psf.upfronthosting.co.za>


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

@zhangdeyue, can you please request that the CVE be unassigned?  I think we all agree this is *not* a security issue.

----------
keywords:  -security_issue
nosy: +ned.deily

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

From report at bugs.python.org  Thu Mar  1 16:17:44 2018
From: report at bugs.python.org (Preston Landers)
Date: Thu, 01 Mar 2018 21:17:44 +0000
Subject: [issue23102] distutils: isinstance checks fail with
 setuptools-monkeypatched Extension/Distribution
In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za>
Message-ID: <1519939064.78.0.467229070634.issue23102@psf.upfronthosting.co.za>


Change by Preston Landers <planders at gmail.com>:


----------
nosy: +planders

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

From report at bugs.python.org  Thu Mar  1 16:23:19 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 01 Mar 2018 21:23:19 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1519939399.7.0.467229070634.issue18855@psf.upfronthosting.co.za>


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

Thanks. I'm going to reject this and to keep the readme files as is.
The consequence of renaming files, now that we are on GitHub, is that GitHub doesn't retain the complete file history.
So while on GitHub, clicking the file's "History" will only show the history of the file after the rename.
In addition, locally you need to do `git log --follow` to see the complete history.
I find that to be an inconvenience.

----------
nosy: +Mariatta
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  1 16:41:32 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 01 Mar 2018 21:41:32 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1519940492.49.0.467229070634.issue32980@psf.upfronthosting.co.za>


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


----------
nosy: +vstinner

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

From report at bugs.python.org  Thu Mar  1 16:42:19 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 01 Mar 2018 21:42:19 +0000
Subject: [issue32971] Docs on unittest.TestCase.assertRaises() should clarify
 context manager details
In-Reply-To: <1519840682.18.0.467229070634.issue32971@psf.upfronthosting.co.za>
Message-ID: <1519940539.55.0.467229070634.issue32971@psf.upfronthosting.co.za>


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


----------
title: Docs on unittest.TestCase.assertRaises() should be improved -> Docs on unittest.TestCase.assertRaises() should clarify context manager details

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

From report at bugs.python.org  Thu Mar  1 17:00:13 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Thu, 01 Mar 2018 22:00:13 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519941613.4.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Mark, you said "if there's a test that's explicitly checking that `my_fraction // my_float` returns something of type `int`, then the behaviour is clearly intentional". I see exactly that. See https://github.com/python/cpython/blob/bf63e8d55fd2853df3bb99d66de7f428107aadb3/Lib/test/test_fractions.py#L404  In fact, when I said I made floordiv return a float, and "changed one test to make sure that it works", it was that test. So maybe that means we should be more cautious about changing the behavior of floordiv, if we decide to change it.

----------

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

From report at bugs.python.org  Thu Mar  1 17:10:32 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Thu, 01 Mar 2018 22:10:32 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519942232.05.0.467229070634.issue32968@psf.upfronthosting.co.za>


Change by Elias Zamaria <mikez302 at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  1 17:16:47 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Thu, 01 Mar 2018 22:16:47 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1519942607.15.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

I added the pull request. It includes only my changes to modulo, and not the ones to floordiv.

----------

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

From report at bugs.python.org  Thu Mar  1 17:24:35 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 01 Mar 2018 22:24:35 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
 patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1519943075.02.0.467229070634.issue10507@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Since `blurb` says to write a simple ReST paragraph and that is code reviewed with the PR, is this issue still needed?

----------
nosy: +csabella

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

From report at bugs.python.org  Thu Mar  1 18:00:42 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 01 Mar 2018 23:00:42 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1519945242.17.0.467229070634.issue32493@psf.upfronthosting.co.za>


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

If it is a bug in OpenBSD how do you propose we "fix" this.

imho, the problem is "outside" python.

however, until it is fixed in openbsd, would you accept an 3error macro that prevents the mod from being built on the specific version of openbsd that fails?

----------

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

From report at bugs.python.org  Thu Mar  1 18:01:40 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 01 Mar 2018 23:01:40 +0000
Subject: [issue32493] UUID Module - FreeBSD build failure
In-Reply-To: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>
Message-ID: <1519945300.47.0.467229070634.issue32493@psf.upfronthosting.co.za>


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

oops, sain openbsd, should be freebsd

----------

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

From report at bugs.python.org  Thu Mar  1 18:20:59 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 01 Mar 2018 23:20:59 +0000
Subject: [issue32977] added acts_like decorator to dataclasses module
In-Reply-To: <1519916090.48.0.467229070634.issue32977@psf.upfronthosting.co.za>
Message-ID: <1519946459.92.0.467229070634.issue32977@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Since this has to wait until 3.8 and I'm swamped with 3.7, this is going to have to wait for me to look at it.

Is there a reason it needs to be part of dataclasses itself? I'd suggest separating it out, putting it on PyPI, and getting some traction there, first.

----------
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Thu Mar  1 19:36:19 2018
From: report at bugs.python.org (James Davis)
Date: Fri, 02 Mar 2018 00:36:19 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
Message-ID: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>


New submission from James Davis <davisjam at vt.edu>:

Hi Python security team,

My name is James Davis. I'm a security researcher at Virginia Tech.

The python core (cpython) has 2 regular expressions vulnerable to catastrophic backtracking that look like potential DOS vectors.
The vulnerable expressions are listed below.

Each vulnerability has the following keys, explained in more detail below:
 - pattern
 - filesIn (as of December/January; I excluded any appearances in irrelevant-looking dirs, and in '.min' files)
 - stringLenFor10Sec
 - nPumpsFor10Sec
 - attackFormat
 - blowupCurve

The attack format describes how to generate an attack string.
On my machine, an attack string generated using nPumpsFor10Sec repetitions ("pumps") of the pump string(s)
blocks the python regex engine for 10 seconds, though this will vary based on your hardware.

Compose an attack string like this:
  'prefix 1' + 'pump 1' X times + 'prefix 2' + 'pump 2' X times + ... + suffix
Example:
  With pumpPairs: [{'prefix': 'a', 'pump': 'b'}], suffix: 'c', an attack string with three pumps would be:
    abbbc

Catastrophic backtracking blows up at either an exponential rate or a super-linear (power law) rate.
The blowupCurve indicates how severe the blow-up is.
The 'type' is either EXP(onential) or POW(er law) in the number of pumps (x).
The 'parms' are the parameters for the two curve types. The second parameter is more important, because:
  EXP: f(x) = parms[0] * parms[1]^x
  POW: f(x) = parms[0] * x^parms[1]

JSON formatted:

Vuln 1:

{
   "attackFormat" : {
      "pumpPairs" : [
         {
            "pump" : "<a",
            "prefix" : "+OKa"
         }
      ],
      "suffix" : "+"
   },
   "blowupCurve" : {
      "parms" : [
         2.71096268836868e-08,
         1.83422078906374
      ],
      "type" : "POWER",
      "r2" : 0.997503282766243
   },
   "stringLenFor10Sec" : 96655,
   "nPumpsFor10Sec" : "48325",
   "pattern" : "\\+OK.*(<[^>]+>)",
   "filesIn" : [
      [
         "Lib/poplib.py"
      ]
   ]
}

Vuln 2:

{
   "blowupCurve" : {
      "parms" : [
         1.31911634447601e-08,
         1.89691808610459
      ],
      "r2" : 0.998387790742004,
      "type" : "POWER"
   },
   "stringLenFor10Sec" : 48328,
   "attackFormat" : {
      "pumpPairs" : [
         {
            "pump" : "\t",
            "prefix" : "\t"
         }
      ],
      "suffix" : "##"
   },
   "pattern" : "\\s*#?\\s*$",
   "filesIn" : [
      [
         "Lib/difflib.py"
      ]
   ],
   "nPumpsFor10Sec" : "48325"
}

----------
components: Library (Lib)
messages: 313119
nosy: davisjam
priority: normal
pull_requests: 5723
severity: normal
status: open
title: Catastrophic backtracking in poplib and difflib
type: security

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

From report at bugs.python.org  Thu Mar  1 20:25:41 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Mar 2018 01:25:41 +0000
Subject: [issue32975] mailbox: It would be nice to move mailbox.Message from
 legacy email.message.Message API to new EmailMessage API
In-Reply-To: <1519883058.82.0.467229070634.issue32975@psf.upfronthosting.co.za>
Message-ID: <1519953941.66.0.467229070634.issue32975@psf.upfronthosting.co.za>


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

This is a reasonable request (a good way to use EmailMessage), but EmailMessage is not yet the default even for the email package.  You have to specify policy=default to get it (or use it to construct a message).

Mailbox probably needs some backward compatible way for the user to specify the policy.

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

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

From report at bugs.python.org  Thu Mar  1 20:46:24 2018
From: report at bugs.python.org (Ma Lin)
Date: Fri, 02 Mar 2018 01:46:24 +0000
Subject: [issue32818] subprocess crash under Windows compatibility mode
In-Reply-To: <1518323274.11.0.467229070634.issue32818@psf.upfronthosting.co.za>
Message-ID: <1519955184.67.0.467229070634.issue32818@psf.upfronthosting.co.za>


Change by Ma Lin <malincns at 163.com>:


----------
title: multiprocessing segmentfault under Windows compatibility mode -> subprocess crash under Windows compatibility mode

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

From report at bugs.python.org  Thu Mar  1 21:20:02 2018
From: report at bugs.python.org (zhangdeyue)
Date: Fri, 02 Mar 2018 02:20:02 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519957202.79.0.467229070634.issue32056@psf.upfronthosting.co.za>


zhangdeyue <abcdyzhang at 163.com> added the comment:

I agree that it is very small, but I still think it is indeed a security issue, because it can crash real world program when called by some library used in Deep Learning ASR project. 

Does a CVE assigned have any negative impact on you?

----------

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

From report at bugs.python.org  Thu Mar  1 21:29:36 2018
From: report at bugs.python.org (Abhilash Raj)
Date: Fri, 02 Mar 2018 02:29:36 +0000
Subject: [issue32975] mailbox: It would be nice to move mailbox.Message from
 legacy email.message.Message API to new EmailMessage API
In-Reply-To: <1519883058.82.0.467229070634.issue32975@psf.upfronthosting.co.za>
Message-ID: <1519957776.78.0.467229070634.issue32975@psf.upfronthosting.co.za>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Can you suggest what would be the best way go about doing that?

Given that mailbox.Message subclasses from Message, I am not sure how to proceed about this to make this configurable with a flag.

I haven't yet made a PR, but this[1] is the URL to the change I made.

[1]: https://github.com/python/cpython/compare/master...maxking:fix-mailbox

----------

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

From report at bugs.python.org  Thu Mar  1 22:43:44 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Mar 2018 03:43:44 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519962224.6.0.467229070634.issue32056@psf.upfronthosting.co.za>


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

> I agree that it is very small, but I still think it is indeed a security issue, because it can crash real world program when called by some library used in Deep Learning ASR project. 

That sounds like a programming error, not a security bug.  The case you describe causes a Python exception to be raised.  As noted in the Python Language Reference: "Exceptions are a means of breaking out of the normal flow of control of a code block in order to handle errors or other exceptional conditions."  Any program using Python libraries needs to be prepared to handle a wide variety of exception, particularly if the program is dealing with external data, like an arbitrary audio file.  If a program is failing because it fails to properly check for exceptions, like by using a "try" block, that's a bug in the program, not a security problem in Python.

> Does a CVE assigned have any negative impact on you?

Yes, because it implies that there is some security problem in Python that downstream vendors and users need to be concerned about and should expect some fix or other mediation from the responsible project.  That is not the case here.

Now, as Serhily noted, it might be nice if the exception produced a more meaningful message but changing that would not change the end result for a program: it will still see an exception and either need to handle it or be terminated like with any other Python exception.

----------

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

From report at bugs.python.org  Thu Mar  1 22:54:49 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 02 Mar 2018 03:54:49 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
 patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1519962889.72.0.467229070634.issue10507@psf.upfronthosting.co.za>


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

This is out of date. I'm closing it.

Thanks.

----------
nosy: +Mariatta
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  1 23:14:47 2018
From: report at bugs.python.org (zhangdeyue)
Date: Fri, 02 Mar 2018 04:14:47 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1519964087.4.0.467229070634.issue32056@psf.upfronthosting.co.za>


zhangdeyue <abcdyzhang at 163.com> added the comment:

I'm confused now. For any program which receive external file, to check the input file is necessary to do, isn't it? And program error lead to security bug, that's not right? 

The program itself check input file, catch and show some exceptions or asserts means that the error has been taken into account and the program is robust. 

However, I got the message from the system's check.

----------

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

From report at bugs.python.org  Thu Mar  1 23:18:50 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 02 Mar 2018 04:18:50 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1519964330.97.0.467229070634.issue16806@psf.upfronthosting.co.za>


Anthony Sottile <asottile at umich.edu> added the comment:

Still a problem in 3.7:

$ python3.7
Python 3.7.0b2 (default, Feb 28 2018, 06:59:18) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("""x = '''foo\n'''""").body[-1].value
<_ast.Str object at 0x7fcde6898358>
>>> ast.parse("""x = '''foo\n'''""").body[-1].value.col_offset
-1

----------
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.4

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

From report at bugs.python.org  Thu Mar  1 23:59:54 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 02 Mar 2018 04:59:54 +0000
Subject: [issue29890] Constructor of ipaddress.IPv*Interface does not follow
 documentation
In-Reply-To: <1490306388.92.0.69250411121.issue29890@psf.upfronthosting.co.za>
Message-ID: <1519966794.76.0.467229070634.issue29890@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

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

From report at bugs.python.org  Fri Mar  2 00:04:09 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Mar 2018 05:04:09 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1519967049.2.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


----------
nosy: +tim.peters

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

From report at bugs.python.org  Fri Mar  2 01:04:50 2018
From: report at bugs.python.org (Franklin? Lee)
Date: Fri, 02 Mar 2018 06:04:50 +0000
Subject: [issue32982] Parse out invisible Unicode characters?
Message-ID: <1519970690.52.0.467229070634.issue32982@psf.upfronthosting.co.za>


New submission from Franklin? Lee <leewangzhong at gmail.com>:

The following line should have a character that trips up the compiler.
  ?indices = range(5)

The character is \u200e, and was inserted by Google Keep. (I've already reported the issue to Google as a regression.)

Here's the error message:
"""
  File "<stdin>", line 3
    ?indices = range(5)
           ^
SyntaxError: invalid character in identifier
"""

Depending on the terminal or editor, it may not be possible to tell the problem just from looking. Without knowledge/experience of Unicode, it may not be possible to figure out the problem at all.

Since Python source now uses Unicode by default, should certain invisible characters be stripped out during compilation?

----------
components: Unicode
messages: 313127
nosy: ezio.melotti, leewz, vstinner
priority: normal
severity: normal
status: open
title: Parse out invisible Unicode characters?
type: behavior

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

From report at bugs.python.org  Fri Mar  2 04:53:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Mar 2018 09:53:59 +0000
Subject: [issue32964] Reuse a testing implementation of the path protocol in
 tests
In-Reply-To: <1519760407.45.0.467229070634.issue32964@psf.upfronthosting.co.za>
Message-ID: <1519984439.05.0.467229070634.issue32964@psf.upfronthosting.co.za>


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


New changeset b21d155f57d284aecf9092a9bd24258293965c2f by Serhiy Storchaka in branch 'master':
bpo-32964: Reuse a testing implementation of the path protocol in tests. (#5930)
https://github.com/python/cpython/commit/b21d155f57d284aecf9092a9bd24258293965c2f


----------

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

From report at bugs.python.org  Fri Mar  2 04:54:11 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 02 Mar 2018 09:54:11 +0000
Subject: [issue32964] Reuse a testing implementation of the path protocol in
 tests
In-Reply-To: <1519760407.45.0.467229070634.issue32964@psf.upfronthosting.co.za>
Message-ID: <1519984451.77.0.467229070634.issue32964@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5724

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

From report at bugs.python.org  Fri Mar  2 05:07:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Mar 2018 10:07:12 +0000
Subject: [issue32964] Reuse a testing implementation of the path protocol in
 tests
In-Reply-To: <1519760407.45.0.467229070634.issue32964@psf.upfronthosting.co.za>
Message-ID: <1519985232.46.0.467229070634.issue32964@psf.upfronthosting.co.za>


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


----------
pull_requests: +5725

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

From report at bugs.python.org  Fri Mar  2 05:17:56 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 02 Mar 2018 10:17:56 +0000
Subject: [issue32964] Reuse a testing implementation of the path protocol in
 tests
In-Reply-To: <1519760407.45.0.467229070634.issue32964@psf.upfronthosting.co.za>
Message-ID: <1519985876.98.0.467229070634.issue32964@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a13b65422a1078104e9f53ad41945ea380a80798 by Miss Islington (bot) in branch '3.7':
bpo-32964: Reuse a testing implementation of the path protocol in tests. (GH-5930)
https://github.com/python/cpython/commit/a13b65422a1078104e9f53ad41945ea380a80798


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Mar  2 06:22:40 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Mar 2018 11:22:40 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1519989760.15.0.467229070634.issue32980@psf.upfronthosting.co.za>


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

(Bringing my response from core-mentorship over to the main tracker)

These APIs are exposed to embedding applications via the pylifecycle header: https://github.com/python/cpython/blob/master/Include/pylifecycle.h#L143

While we technically *could* deprecate & remove them (since we're not currently using them for anything), the current cost/benefit assessment is that it isn't worth the API churn (even for the underscore prefixed _PyFrame_Init API) when it's relatively cheap to keep them around as no-ops.

Given that they exist in the code base in order to continue exporting the symbols though, future maintainers are entitled to expect that we'll keep calling them in the appropriate places, such that if anyone *does* add code to them in the future, that code will "just work".

----------
nosy: +ncoghlan
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  2 07:12:03 2018
From: report at bugs.python.org (cosven)
Date: Fri, 02 Mar 2018 12:12:03 +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: <1519992723.6.0.467229070634.issue30811@psf.upfronthosting.co.za>


cosven <yinshaowen241 at gmail.com> added the comment:

It is actually a bug in virtualenv instead of venv.

> the outer environment's pip leaks into the inner environment;

This is true, but why? In short, the inner-env python binary
use `outer-env/` directory as its `prefix` direcotry,
but the `inner-env/` directory is the right `prefix` directory.

When the Python binary is executed, it attempts to determine
its `prefix` (which it stores in sys.prefix), which is then used
to find the standard library and other key files, and by the
`site` module to determine the location of the site-package directories.

However, virtualenv has its own `site` module, which is different
implemented from the site module in stdlib. It makes the inner-python
get a wrong `prefix` value.

> (Could a fix on virtualenv's side help?)
In my own opinion, if virtualenv change its implementation of site.py,
there is a change to fix this.

----------
nosy: +cosven

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

From report at bugs.python.org  Fri Mar  2 07:36:16 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 02 Mar 2018 12:36:16 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1519994176.47.0.467229070634.issue32430@psf.upfronthosting.co.za>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

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

From report at bugs.python.org  Fri Mar  2 08:20:54 2018
From: report at bugs.python.org (Jiri Prajzner)
Date: Fri, 02 Mar 2018 13:20:54 +0000
Subject: [issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in
 position - ordinal not in range(128)
Message-ID: <1519996854.15.0.467229070634.issue32983@psf.upfronthosting.co.za>


New submission from Jiri Prajzner <dr3dwerkz at gmail.com>:

Locate "Barra de navegaci?"->"T?rmino de b?squeda o direcci?n" and browse "http://www.columbia.edu/~fdc/utf8/" website - results in:
Exception UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 73: ordinal not in range(128)

If i correct the word navegaci? to navegaci?n, there's no UnicodeDecodeError

----------
components: Unicode
messages: 313132
nosy: Jiri Prajzner, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal not in range(128)
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar  2 09:26:38 2018
From: report at bugs.python.org (Jiri Prajzner)
Date: Fri, 02 Mar 2018 14:26:38 +0000
Subject: [issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in
 position - ordinal not in range(128)
In-Reply-To: <1519996854.15.0.467229070634.issue32983@psf.upfronthosting.co.za>
Message-ID: <1520000798.48.0.467229070634.issue32983@psf.upfronthosting.co.za>


Jiri Prajzner <dr3dwerkz at gmail.com> added the comment:

Locate "URL \u307e\u305f\u306f\u691c\u7d22\u8a9e\u53e5\u3092\u5165\u529b\u3057\u307e\u3059"->"URL \u307e\u305f\u306f\u691c\u7d22\u8a9e\u53e5\u3092\u5165\u529b\u3057\u307e\u3059" and browse "http://www.google.com" website throws the same error. if the first "URL \u307e\u305f\u306f\u691c\u7d22\u8a9e\u53e5\u3092\u5165\u529b\u3057\u307e\u3059" is replaced with "\u30ca\u30d3\u30b2\u30fc\u30b7\u30e7\u30f3\u30c4\u30fc\u30eb\u30d0\u30fc" that is actually expected, there's no error.

----------

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

From report at bugs.python.org  Fri Mar  2 09:36:42 2018
From: report at bugs.python.org (Jiri Prajzner)
Date: Fri, 02 Mar 2018 14:36:42 +0000
Subject: [issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in
 position - ordinal not in range(128)
In-Reply-To: <1519996854.15.0.467229070634.issue32983@psf.upfronthosting.co.za>
Message-ID: <1520001402.29.0.467229070634.issue32983@psf.upfronthosting.co.za>


Jiri Prajzner <dr3dwerkz at gmail.com> added the comment:

Locate "\u179a\u1794\u17b6\u179a\u200b\u17a7\u1794\u1780\u179a\u178e\u17cd\u200b\u179a\u17bb\u1780\u179a\u1780\u200b"->"\u179f\u17d2\u179c\u17c2\u1784\u179a\u1780 \u17ac\u200b\u1794\u1789\u17d2\u1785\u17bc\u179b\u200b\u17a2\u17b6\u179f\u1799\u178a\u17d2\u178b\u17b6\u1793" and browse "http://www.google.com" website 

versus 

Locate "\u179a\u1794\u17b6\u179a\u200b\u1798\u17c9\u17ba\u1793\u17bb\u1799"->"\u179f\u17d2\u179c\u17c2\u1784\u179a\u1780 \u17ac\u200b\u1794\u1789\u17d2\u1785\u17bc\u179b\u200b\u17a2\u17b6\u179f\u1799\u178a\u17d2\u178b\u17b6\u1793" and browse "http://www.columbia.edu/~fdc/utf8/" website - this is km_KH.utf8 locale. msg313133 is ja_JP.utf8 locale

it looks like python unicode decode cannot compare strings well in these locales.

----------

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

From report at bugs.python.org  Fri Mar  2 10:47:45 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Mar 2018 15:47:45 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1520005665.56.0.467229070634.issue32968@psf.upfronthosting.co.za>


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

[Elias Zamaria]

> I see exactly that.

Understood; that's how I interpreted your "changed one test to make sure that it works". It seems we understand each other. :-)

So yes, one always needs to be very cautious about changing deliberate, tested behaviour. But in this case I'm satisfied that I understand what the intent was when that test was written, namely that `Real.__floordiv__` returns an `Integral`. And since that part of PEP 3141 didn't actually get implemented for float // float (and the agreement on #22444 was that the PEP should be changed rather than the behaviour), that intent is now a little bogus, and I think it's reasonable to change the behaviour in this case. The change would make the overall behaviour of mixed-type operations simple to state and understand, and fix a consistency bug. It's also sufficiently much of a corner case that the change seems unlikely to break existing code.

In short, I'm +1 on making your suggested change to __floordiv__ as well as to __mod__.

I'm adding Jeffrey Yasskin (the original PEP 3141 author) to the nosy list, in case he has any comment. (I don't believe Jeffrey is still watching Python development, but would be happy to be proved wrong.)

----------
nosy: +jyasskin

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

From report at bugs.python.org  Fri Mar  2 10:49:12 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Mar 2018 15:49:12 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520005752.73.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

> And I think that using math.ldexp() can be more preferable that pow(2.0, ...)

Yes, absolutely agreed. I'll take a look at the PR.

----------

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

From report at bugs.python.org  Fri Mar  2 11:09:59 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 02 Mar 2018 16:09:59 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1520006999.6.0.467229070634.issue32973@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

PEP 489 ("Multi-phase extension module initialization") is relevant here, so I've nosied Petr.

----------
nosy: +encukou

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

From report at bugs.python.org  Fri Mar  2 11:21:11 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 02 Mar 2018 16:21:11 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1520007671.01.0.467229070634.issue32973@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Well, PEP 489 basically punts this to module authors: generally, C globals are bad, but if you do have global state, please manage it, keeping in mind that multiple module objects can be created from the extension.

That's required to make everything work with subinterpreters.

See: https://www.python.org/dev/peps/pep-0489/#subinterpreters-and-interpreter-reloading

CCing Marcel, who's working on PEP 489-related stuff now.

----------
nosy: +Dormouse759

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

From report at bugs.python.org  Fri Mar  2 12:06:15 2018
From: report at bugs.python.org (Socob)
Date: Fri, 02 Mar 2018 17:06:15 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1520010375.59.0.467229070634.issue3177@psf.upfronthosting.co.za>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

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

From report at bugs.python.org  Fri Mar  2 12:11:55 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Mar 2018 17:11:55 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1520010715.58.0.467229070634.issue32980@psf.upfronthosting.co.za>


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

Future maintainers of what exactly can expect these functions to be called? CPython? If we need to do initialization of frameobject.c later, we can simply add _PyFrame_Init back. We certainly don't support ELF-interposition of _PyFrame_Init as an API.

Historically, we've been sloppy about putting private and public APIs in the same header files. But the leading underscore still means private; such APIs serve at our pleasure.

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

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

From report at bugs.python.org  Fri Mar  2 12:13:39 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2018 17:13:39 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
Message-ID: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

'python somefile.py' sets main.__file__ to 'somefile.py'. 'python' leaves __file__ unset.  If PYTHONSTARTUP is set to somefile.py, 'python' executes somefile.py in main with __file__ set to 'somefile.py', then unsets __file__ before the >>> prompt, as if somefile has not been executed.  Any explicit setting of __file__ in somefile is undone.

tem2.py:
print(__name__, __file__)
__file__ = 'abc.py'

> F:\dev\3x> set PYTHONSTARTUP=f:/python/a/tem2.py
> F:\dev\3x> python
...
__main__ f:/python/a/tem2.py
>>> __file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '__file__' is not defined

With IDLE, when 'python -m idlelib.idle' is run with '-s' or '-r f:/python/a/tem2.py', NameError is raised for the print in tem2.py. This was reported this SO question.
https://stackoverflow.com/questions/49054093/cannot-use-file-when-opening-module-in-idle 

In both cases, the file is run with execfile(filename).

    def execfile(self, filename, source=None):
        "Execute an existing file"
        if source is None:
            with tokenize.open(filename) as fp:
                source = fp.read()

My guess is that wrapping the source with f"__file__ = {filename}\n" and "del __file__\n" should work.

----------
assignee: terry.reedy
components: IDLE
messages: 313140
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: set and unset __file__ for startup files
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  2 12:14:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Mar 2018 17:14:29 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520010869.56.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

Thank you for your review Mark.

If left the OverflowError propagated I would catch it at the caller place (_read_float() is used only once) and reraise as aifc.Error. OverflowError is not expected exception. It never is raised for valid AIFC files, and the probability of raising it rather of aifc.Error for a random binary file is very small. I suppose that most users of this module don't catch it. See also issue32056.

But on other side, if there are files with an exponent of 0x7fff in wild, they are currently opened without errors. Raising an exception can be a regression.

----------

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

From report at bugs.python.org  Fri Mar  2 12:17:46 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Fri, 02 Mar 2018 17:17:46 +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: <1520011066.83.0.467229070634.issue30811@psf.upfronthosting.co.za>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

@cosven you are correct! I made some additional observation while working on adding venv support to pew, in this thread: https://github.com/berdario/pew/pull/173. I?ll try to summarise below.

The root problem is indeed virtualenv?s custom site module, but even then it is possible for venv (or any tool built around it) to know where the ?original? Python is, since virtualenv stores the old sys.prefix in sys.real_prefix. Unfortunately, however, this is not as useful as it seems. What we really want in this situation is sys.exec_prefix, which may or may not be the same as sys.prefix. I did manage to cobble together a hack, but it is by no means bullet-proof.

To actually deal with this problem, we will need to amend the site module provided by virtualenv, as you mentioned. But this still can?t ?solve? it. Since the site module is vendored in the produced virtualenv, existing virtualenvs will stay broken even after we managed to upgrade the virtualenv installations.

----------

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

From report at bugs.python.org  Fri Mar  2 12:21:53 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Mar 2018 17:21:53 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520011313.04.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

> If left the OverflowError propagated I would catch it at the caller place (_read_float() is used only once) and reraise as aifc.Error.

Ah, if there's a dedicated exception type already then yes, agreed that raising aifc.Error (with a suitable message) makes much more sense than raising an OverflowError or a ValueError.

> if there are files with an exponent of 0x7fff in wild

I hope there aren't, and I'd consider any such file to be broken/corrupted. That is, unless there's a common practice of using NaNs or infinities for the frame rate. I suppose it's conceivable that people us this as a placeholder meaning "I don't know the sample rate". No idea whether that's true in practice: I'm not a frequent user of this format.

----------

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

From report at bugs.python.org  Fri Mar  2 12:27:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Mar 2018 17:27:31 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520011651.78.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

What if return 80-bit infinities and NaN as 64-bit infinities and NaN and raise an error in the case of finite numbers overflow?

----------

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

From report at bugs.python.org  Fri Mar  2 12:28:41 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Mar 2018 17:28:41 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520011721.98.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

> What if return 80-bit infinities and NaN as 64-bit infinities and NaN and raise an error in the case of finite numbers overflow?

That's certainly reasonable from a pure floating-point-conversion perspective: it's exactly what I'd expect a general purpose extended-precision to double-precision converter to do.

----------

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

From report at bugs.python.org  Fri Mar  2 12:30:37 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 02 Mar 2018 17:30:37 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1520011837.48.0.467229070634.issue32973@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
components: +Extension Modules
nosy: +scoder

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

From report at bugs.python.org  Fri Mar  2 12:31:25 2018
From: report at bugs.python.org (=?utf-8?q?Alicia_Boya_Garc=C3=ADa?=)
Date: Fri, 02 Mar 2018 17:31:25 +0000
Subject: [issue32985] subprocess.Popen: Confusing documentation for
 restore_signals
Message-ID: <1520011885.85.0.467229070634.issue32985@psf.upfronthosting.co.za>


New submission from Alicia Boya Garc?a <ntrrgc at gmail.com>:

The docs state:

> If restore_signals is true (the default) all signals that Python has set to SIG_IGN are restored to SIG_DFL in the child process before the exec. Currently this includes the SIGPIPE, SIGXFZ and SIGXFSZ signals. (POSIX only)

The first phrase and the second may seem contradictory for anyone that uses signal handling in their code.

I would definitely not describe the set of "SIGPIPE, SIGXFZ and SIGXFSZ" as "all signals that Python has set". It actually means "all the signals that Python set at startup"; the user could have changed different signals than these (e.g. SIGINT) for various purposes (e.g. not getting a KeyboardInterrupt while an interactive process is running).

The current wording may suggest that all signals changed by the user are reset in the child process, but this is not the case -- I could confirm by looking at _Py_RestoreSignals(). Only these three specific signals are restored.

----------
components: Library (Lib)
messages: 313146
nosy: ntrrgc
priority: normal
severity: normal
status: open
title: subprocess.Popen: Confusing documentation for restore_signals
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar  2 12:31:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Mar 2018 17:31:32 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520011892.14.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

But I don't know the exact format for infinities and NaNs.

----------

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

From report at bugs.python.org  Fri Mar  2 12:34:20 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 02 Mar 2018 17:34:20 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1520012060.54.0.467229070634.issue32973@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> change the extension module cache to key on filename and init function name

... or on the pointer to the PyInit function. If that's the same, we obviously have the same extension module. If it differs, even for the same module name, then other globals of the modules will probably also be distinct.

----------

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

From report at bugs.python.org  Fri Mar  2 12:45:16 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Mar 2018 17:45:16 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1520012716.83.0.467229070634.issue32978@psf.upfronthosting.co.za>


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

> But I don't know the exact format for infinities and NaNs.

>From the Intel software developer manuals:

For infinities:

Sign bit: 0 or 1 (positive or negative infinity)
Exponent field (15 bits): all ones
Significand (64 bits): first bit 1, all remaining bits 0.

NaN:

Sign bit: 0 or 1
Exponent field (15 bits): all ones
Significand (64 bits): first bit 1, at least one of the remaining bits 1.

----------

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

From report at bugs.python.org  Fri Mar  2 12:51:29 2018
From: report at bugs.python.org (M J Harvey)
Date: Fri, 02 Mar 2018 17:51:29 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
Message-ID: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>


New submission from M J Harvey <moonbug1970 at gmail.com>:

Hi,

multiprocessing's default assumption about Pool size is os.cpu_count() ie all the cores visible to the OS.

This is tremendously unhelpful when running multiprocessing code inside an HPC batch system (PBS Pro in my case), as there's no way to hint to the code that the # of cpus actually allocated to it may be fewer.

It's quite tedious to have to explain this to every single person trying to use it.

Proposal: multiprocessing should look for a hint for default Pool size from the environment variable "NCPUS" which most batch systems set. If that's not set, or its value is invalid, fall back to os.cpu_count() as before

----------
components: Library (Lib)
messages: 313150
nosy: M J Harvey
priority: normal
severity: normal
status: open
title: multiprocessing, default assumption of Pool size unhelpful
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar  2 12:52:55 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2018 17:52:55 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520013175.05.0.467229070634.issue32984@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When the IDLE GUI process is started, its main.__file__ is set to the idlelib .py file used to start the process.  If IDLE is started with -n, so that user code is run in the same process (the original mode), the -r or -s startup file and code entered at >>> sees this value*, rather than the user startup file name or a NameError.

* I am not sure why it does not see the value of __file__ in the pyshell module, which I would expect to be '.../idlelib/pyshell.py'.

The change proposed above would fix __file__ for -n also, but would disable any subsequently executed idle code that uses __file__ that gets unset.  So I think the wrapping should be conditioned on use_subprocess (True unless -n).

----------

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

From report at bugs.python.org  Fri Mar  2 12:53:16 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Mar 2018 17:53:16 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520013196.57.0.467229070634.issue32986@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar  2 13:00:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2018 18:00:19 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520013619.76.0.467229070634.issue32984@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Revised, more exact, URL:
https://stackoverflow.com/questions/49054093/cannot-use-file-when-running-startup-file-in-idles-normal-mode

----------

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

From report at bugs.python.org  Fri Mar  2 13:10:47 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Fri, 02 Mar 2018 18:10:47 +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: <1520014247.5.0.467229070634.issue28134@psf.upfronthosting.co.za>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

It would be nice if "python" accounted for such low level os things. None the less client.detach() method works fine.

I really did enjoy your talk, kinda bummed it was short and didn't get into more details.

Thanks for your help and patience Christian :)

----------

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

From report at bugs.python.org  Fri Mar  2 13:32:50 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Fri, 02 Mar 2018 18:32:50 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1520015570.41.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Any suggestions as to what I should do? I can either update my pull request with my floordiv change, or create a new pull request, or wait a while to see if anyone else has any opinion on changing the behavior.

----------

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

From report at bugs.python.org  Fri Mar  2 14:10:57 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 02 Mar 2018 19:10:57 +0000
Subject: [issue32982] Parse out invisible Unicode characters?
In-Reply-To: <1519970690.52.0.467229070634.issue32982@psf.upfronthosting.co.za>
Message-ID: <1520017857.96.0.467229070634.issue32982@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

For the record, '\u200e' is '\N{LEFT-TO-RIGHT MARK}'.

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Fri Mar  2 14:15:00 2018
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 02 Mar 2018 19:15:00 +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: <1520018100.76.0.467229070634.issue32378@psf.upfronthosting.co.za>


Bernard Spil <python at bachfreund.nl> added the comment:

My pleasure! Glad we sorted this out for no-nextprotoneg and LibreSSL :D

----------

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

From report at bugs.python.org  Fri Mar  2 14:19:44 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Mar 2018 19:19:44 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520018384.82.0.467229070634.issue32963@psf.upfronthosting.co.za>


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

If no one gets to this before the sprints at PyCon US I will take care of it, but anyone can feel free to submit a pull request to fix this.

----------
assignee: docs at python -> brett.cannon
keywords: +easy

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

From report at bugs.python.org  Fri Mar  2 14:39:22 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 02 Mar 2018 19:39:22 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520019562.58.0.467229070634.issue32963@psf.upfronthosting.co.za>


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

I'm not intending to work on this, nothing until after PyCon :) Feel free to pick it up.

----------

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

From report at bugs.python.org  Fri Mar  2 14:46:14 2018
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 02 Mar 2018 19:46:14 +0000
Subject: [issue32982] Parse out invisible Unicode characters?
In-Reply-To: <1519970690.52.0.467229070634.issue32982@psf.upfronthosting.co.za>
Message-ID: <1520019974.89.0.467229070634.issue32982@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Characters should not be stripped during compilation. But I can see where it might be helpful if the codepoint of the character, and the printed form just in case it is printable, could helpfully be included in the error message, as well as having the ^ pointer pointing to it.

----------
nosy: +v+python

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

From report at bugs.python.org  Fri Mar  2 14:53:42 2018
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 02 Mar 2018 19:53:42 +0000
Subject: [issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in
 position - ordinal not in range(128)
In-Reply-To: <1519996854.15.0.467229070634.issue32983@psf.upfronthosting.co.za>
Message-ID: <1520020422.13.0.467229070634.issue32983@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

The problem here is that the error message is trying to write to an output device using ASCII.  If there is no error, there is no error message print attempt. The error message, when written to an ASCII device, needs to be escaped.

You don't show the code, so it is hard to say more about the issue.

----------
nosy: +v+python

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

From report at bugs.python.org  Fri Mar  2 15:06:03 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2018 20:06:03 +0000
Subject: [issue32933] mock_open does not support iteration around text files.
In-Reply-To: <1519462718.87.0.467229070634.issue32933@psf.upfronthosting.co.za>
Message-ID: <1520021163.75.0.467229070634.issue32933@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, michael.foord, rbcollins
versions: +Python 3.8 -Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  2 15:09:33 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2018 20:09:33 +0000
Subject: [issue32955] IDLE crashes when trying to save a file
In-Reply-To: <1519654711.02.0.467229070634.issue32955@psf.upfronthosting.co.za>
Message-ID: <1520021373.68.0.467229070634.issue32955@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What do you mean by crash?  An exception from Python (which is not a crash)? or something from MacOS?

----------

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

From report at bugs.python.org  Fri Mar  2 15:45:14 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Mar 2018 20:45:14 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520023514.41.0.467229070634.issue32986@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

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

From report at bugs.python.org  Fri Mar  2 15:45:33 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 02 Mar 2018 20:45:33 +0000
Subject: [issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
In-Reply-To: <1517423175.51.0.467229070634.issue32732@psf.upfronthosting.co.za>
Message-ID: <1520023533.15.0.467229070634.issue32732@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The existing LoggerAdapter functionality has been around since Jan 2008, and it seems that no one in that time has raised this as a must-have. In summary:

1. If you want to pass different kwargs in every time, use a logger.
2. If you want to pass particular contextual information in which fits the "extra" parameter approach, use a LoggerAdapter.
3. If that doesn't do it for you, subclass LoggerAdapter and implement what you need.

You haven't really explained why you need this to work in this particular way, so I suspect it could be an XY problem.

----------

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

From report at bugs.python.org  Fri Mar  2 15:48:16 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Mar 2018 20:48:16 +0000
Subject: [issue32985] subprocess.Popen: Confusing documentation for
 restore_signals
In-Reply-To: <1520011885.85.0.467229070634.issue32985@psf.upfronthosting.co.za>
Message-ID: <1520023696.35.0.467229070634.issue32985@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +giampaolo.rodola, gregory.p.smith

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

From report at bugs.python.org  Fri Mar  2 16:30:38 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Mar 2018 21:30:38 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520026238.82.0.467229070634.issue32758@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5728
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Mar  2 16:32:44 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Mar 2018 21:32:44 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1520026364.18.0.467229070634.issue32958@psf.upfronthosting.co.za>


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

Thanks for the report.  The behavior you see can be further isolated to socket.gethostbyname:

>>> import socket
>>> h = "0123456789012345678901234567890123456789012345678901234567890123.example.com"
>>> socket.gethostbyname(h)
Traceback (most recent call last):
  File "/usr/lib/python3.6/encodings/idna.py", line 165, in encode
    raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or too long)

Other socket module calls accepting host names fail similarly, such as getaddrinfo.

----------
nosy: +ned.deily
stage:  -> needs patch
title: Urllib proxy_bypass crashes for urls containing long basic auth strings -> socket module calls with long host names can fail with idna codec error
type: crash -> 
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  2 16:46:33 2018
From: report at bugs.python.org (Aaron Black)
Date: Fri, 02 Mar 2018 21:46:33 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1520027193.92.0.467229070634.issue32958@psf.upfronthosting.co.za>


Aaron Black <aaron.black at jpl.nasa.gov> added the comment:

Just to be clear, I don't know if the socket needs to support 64 character long host name sections, so here's an example url that is at the root of my problem that I'm pretty sure it should support:

>>> import socket
>>> h = "username:long_api_key0123456789012345678901234567890123456789 at www.example.com"
>>> socket.gethostbyname(h)
Traceback (most recent call last):
  File "/Users/ablack/miniconda3/lib/python3.6/encodings/idna.py", line 165, in encode
    raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or too long)

----------

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

From report at bugs.python.org  Fri Mar  2 17:03:34 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Mar 2018 22:03:34 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520028214.37.0.467229070634.issue32963@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar  2 17:09:50 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Mar 2018 22:09:50 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520028590.88.0.467229070634.issue32758@psf.upfronthosting.co.za>


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

The PR adds the documentation warnings. Serhiy, can you double-check that I have the appropriate functions and the comment is acceptable?

----------

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

From report at bugs.python.org  Fri Mar  2 17:10:23 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Mar 2018 22:10:23 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520028623.76.0.467229070634.issue32963@psf.upfronthosting.co.za>


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


New changeset 20003f9162631c47b79202316036d13d74484e4c by Brett Cannon in branch '2.7':
bpo-32963: Fix the tutorial to state source has a default encoding of ASCII (GH-5961)
https://github.com/python/cpython/commit/20003f9162631c47b79202316036d13d74484e4c


----------

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

From report at bugs.python.org  Fri Mar  2 17:10:52 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Mar 2018 22:10:52 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520028652.5.0.467229070634.issue32963@psf.upfronthosting.co.za>


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

Thanks for the bug report, Martijn!

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

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

From report at bugs.python.org  Fri Mar  2 18:32:49 2018
From: report at bugs.python.org (Steve B)
Date: Fri, 02 Mar 2018 23:32:49 +0000
Subject: [issue32987] tokenize.py parses unicode identifiers incorrectly
Message-ID: <1520033569.84.0.467229070634.issue32987@psf.upfronthosting.co.za>


New submission from Steve B <steven.byrnes at gmail.com>:

Here is an example involving the unicode character MIDDLE DOT ? : The line

ab?cd = 7

is valid Python 3 code and is happily accepted by the CPython interpreter. However, tokenize.py does not like it. It says that the middle-dot is an error token. Here is an example you can run to see that:

    import tokenize
    from io import BytesIO
    
    test = 'ab?cd = 7'.encode('utf-8')
    
    x = tokenize.tokenize(BytesIO(test).readline)
    for i in x: print(i)

For reference, the official definition of identifiers is: 

https://docs.python.org/3.6/reference/lexical_analysis.html#identifiers

and details about MIDDLE DOT are at

https://www.unicode.org/Public/10.0.0/ucd/PropList.txt

MIDDLE DOT has the "Other_ID_Continue" property, so I think the interpreter is behaving correctly (i.e. consistent with the documented spec), while tokenize.py is wrong.

----------
components: Library (Lib), Unicode
messages: 313168
nosy: ezio.melotti, steve, vstinner
priority: normal
severity: normal
status: open
title: tokenize.py parses unicode identifiers incorrectly
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar  2 19:31:57 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Mar 2018 00:31:57 +0000
Subject: [issue25427] Remove the pyvenv script in Python 3.8
In-Reply-To: <1445033746.77.0.533143282748.issue25427@psf.upfronthosting.co.za>
Message-ID: <1520037117.05.0.467229070634.issue25427@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5730
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Mar  2 19:43:22 2018
From: report at bugs.python.org (Adam Williamson)
Date: Sat, 03 Mar 2018 00:43:22 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
Message-ID: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>


New submission from Adam Williamson <awilliam at redhat.com>:

Test script:

import pytz
import datetime
utc = pytz.timezone('UTC')
print(datetime.datetime(2017, 1, 1, tzinfo=utc).strftime('%s'))

Try running it with various system timezones:

[adamw at xps13k pagure (more-timezone-fun %)]$ TZ='UTC' python /tmp/test2.py
1483228800
[adamw at xps13k pagure (more-timezone-fun %)]$ TZ='America/Winnipeg' python /tmp/test2.py
1483250400
[adamw at xps13k pagure (more-timezone-fun %)]$ TZ='America/Vancouver' python /tmp/test2.py
1483257600

That's Python 2.7.14; same results with Python 3.6.4.

This does not seem correct. The correct Unix time for an aware datetime object should be a constant: for 2017-01-01 00:00 UTC it *is* 1483228800 . No matter what the system's local timezone, that should be the output of strftime('%s'), surely. What it seems to be doing instead is just outputting the Unix time for 2017-01-01 00:00 in the system timezone.

I *do* note that strftime('%s') is completely undocumented in Python; neither https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior nor https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior mentions it. However, it does exist, and is used in the real world; I found this usage of it, and the bug, in a real project, Pagure.

----------
components: Library (Lib)
messages: 313169
nosy: adamwill
priority: normal
severity: normal
status: open
title: datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri Mar  2 19:44:36 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 03 Mar 2018 00:44:36 +0000
Subject: [issue32989] IDLE: Incorrect signature in call from editor to
 pyparse.find_good_parse_start
Message-ID: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

>From msg312726 on issue32880.

The call to find_good_parse_start:

    bod = y.find_good_parse_start(self.context_use_ps1, 
                         self._build_char_in_string_func(startatindex))

sends 3 parameters.  And in pyparse.find_good_parse_start(), the signature allows 3.  However, the signature is:

    def find_good_parse_start(self, is_char_in_string=None,
                              _synchre=_synchre):


This means that the `False` value in `self.use_context_ps1` is the first value instead of the function, so pyparse is always executing:

    if not is_char_in_string:
        # no clue -- make the caller pass everything
        return None


Here's the commit that changed the signature:
https://github.com/python/cpython/commit/b17544551fc8dfd1304d5679c6e444cad4d34d97

----------
assignee: terry.reedy
components: IDLE
messages: 313170
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  2 19:44:56 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 03 Mar 2018 00:44:56 +0000
Subject: [issue32880] IDLE: Fix and update and cleanup pyparse
In-Reply-To: <1519093154.93.0.467229070634.issue32880@psf.upfronthosting.co.za>
Message-ID: <1520037896.13.0.467229070634.issue32880@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
dependencies: +IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

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

From report at bugs.python.org  Fri Mar  2 20:01:28 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sat, 03 Mar 2018 01:01:28 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
In-Reply-To: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>
Message-ID: <1520038888.89.0.467229070634.issue32988@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

adamwill: I think datetime's strftime is a wrapper around the system strftime, so it varies between platforms. Might be useful to specify which platform you are seeing this behavior on.

----------
nosy: +p-ganssle

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

From report at bugs.python.org  Fri Mar  2 20:05:24 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sat, 03 Mar 2018 01:05:24 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
In-Reply-To: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>
Message-ID: <1520039124.85.0.467229070634.issue32988@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

It seems that %s is not supported and the fact that it works at all is incidental. See issue 12750 and this SO thread:

https://stackoverflow.com/questions/11743019/convert-python-datetime-to-epoch-with-strftime

----------

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

From report at bugs.python.org  Fri Mar  2 20:09:54 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Mar 2018 01:09:54 +0000
Subject: [issue28124] Rework SSL module documentation
In-Reply-To: <1473762840.76.0.666078412099.issue28124@psf.upfronthosting.co.za>
Message-ID: <1520039394.4.0.467229070634.issue28124@psf.upfronthosting.co.za>


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


----------
pull_requests: +5731

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

From report at bugs.python.org  Fri Mar  2 20:14:32 2018
From: report at bugs.python.org (Adam Williamson)
Date: Sat, 03 Mar 2018 01:14:32 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
In-Reply-To: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>
Message-ID: <1520039672.44.0.467229070634.issue32988@psf.upfronthosting.co.za>


Adam Williamson <awilliam at redhat.com> added the comment:

Paul: right. This is on Linux - specifically Fedora Linux, but I don't think it matters. glibc strftime and strptime depend on an underlying struct called 'tm'. 'man strftime' says:

       %s     The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). (TZ) (Calculated from mktime(tm).)

And 'man mktime' says:

The  mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. ... On success, mktime() returns the calendar time (seconds since the Epoch), expressed as a value of type time_t."

I am finding it hard to determine whether various C standards require the tm struct and mktime and strftime and so on to handle timezones, but I'm sort of inclining to the answer that "no they don't".

Basically I suspect what's going on in this case is that the timezone information gets lost somewhere in the chain down from Python to system strftime to system mktime, and Python doesn't make any adjustment to the actual date / time values before calling system strftime to try and account for this.

I think Python must do *something* more than purely converting to a tm and calling system strftime, though, as %Z does work, which it wouldn't if Python was purely converting to a non-timezone-aware tm struct and calling system strftime, I don't think...

----------

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

From report at bugs.python.org  Fri Mar  2 20:18:50 2018
From: report at bugs.python.org (Adam Williamson)
Date: Sat, 03 Mar 2018 01:18:50 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
In-Reply-To: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>
Message-ID: <1520039930.71.0.467229070634.issue32988@psf.upfronthosting.co.za>


Adam Williamson <awilliam at redhat.com> added the comment:

I'd suggest that if that is the case, it would be better for the docs to *specifically mention* that `%s` is not supported and should not be used, rather than simply not mentioning it.

When it's used in real code (note someone in the SO issue mentions "I have been going crazy trying to figure out why i see strftime("%s") a lot, yet it's not in the docs") and just *not mentioned* in the docs, this tends to give the impression that it's something usable that was perhaps just forgotten from the docs, or something. The situation would be much clearer if the docs said "DO NOT USE THIS, IT'S DANGEROUS AND DOESN'T DO WHAT YOU THINK" in big letters. (And suggested using .timestamp() on Python 3.3+, and possibly arrow's .timestamp on 2.7?)

----------

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

From report at bugs.python.org  Fri Mar  2 20:24:34 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sat, 03 Mar 2018 01:24:34 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
In-Reply-To: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>
Message-ID: <1520040274.95.0.467229070634.issue32988@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I suspect discussion should be centralized in issue 12750, but if it were up to me %s would either work as expected or throw an error. Silently giving the wrong answer is a terrible compromise.

----------

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

From report at bugs.python.org  Fri Mar  2 20:50:07 2018
From: report at bugs.python.org (Adam Williamson)
Date: Sat, 03 Mar 2018 01:50:07 +0000
Subject: [issue12750] add cross-platform support for %s strftime-format code
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1520041806.99.0.467229070634.issue12750@psf.upfronthosting.co.za>


Adam Williamson <awilliam at redhat.com> added the comment:

On the "attractive nuisance" angle: I just ran right into this problem, and reported https://bugs.python.org/issue32988 .

As I suggested there, if Python doesn't try to fix this, I'd suggest it should at least *explicitly document* that using %s is unsupported and dangerous in more than one way (might not work on all platforms, does not do what it should for 'aware' datetimes on platforms where it *does* work). I think explicitly telling people NOT to use it would be better than just not mentioning it. At least for me, when I saw real code using it and that the docs just didn't mention it, my initial thought was "I guess it must be OK, and the docs just missed it out for some reason". If I'd gone to the docs and seen an explicit note that it's not supported and doesn't work right, that would've been much clearer and I wouldn't have had to figure that out for myself :)

For Python 2, btw, the arrow library might be a suitable alternative to suggest: you can do something like this, assuming you have an aware datetime object called 'awaredate' you want to get the timestamp for:

import arrow
ts = arrow.get(awaredate).timestamp

and it does the right thing.

----------
nosy: +adamwill

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

From report at bugs.python.org  Fri Mar  2 20:53:40 2018
From: report at bugs.python.org (Adam Williamson)
Date: Sat, 03 Mar 2018 01:53:40 +0000
Subject: [issue32988] datetime.datetime.strftime('%s') always uses local
 timezone, even with aware datetimes
In-Reply-To: <1520037802.51.0.467229070634.issue32988@psf.upfronthosting.co.za>
Message-ID: <1520042020.23.0.467229070634.issue32988@psf.upfronthosting.co.za>


Adam Williamson <awilliam at redhat.com> added the comment:

Yeah, I've added a comment there. I agree we can keep subsequent discussion in that issue. Closing this as a dupe.

I actually have the same thought as you, but I suspect making something that "worked" before start throwing an error might be a hard sell for some. Perhaps at least some kind of warning?

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  2 22:56:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Mar 2018 03:56:57 +0000
Subject: [issue32989] IDLE: Incorrect signature in call from editor to
 pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520049417.84.0.467229070634.issue32989@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To be clear, the signature that got changed in 2005 is the signature for find_good_parse_start ('fgps'), which was previously

def find_good_parse_start(self, use_ps1, is_char_in_string=None,
 _synchre=_synchre)

When the use_ps1 parameter was removed, the 'if use_ps1' code was moved to the else: branch of the new 'if not use_ps1: ... else: ' in the editor method, but the call in question, moved into the 'if not use_ps1' branch, was not changed.  The immediate fix is to remove the extra argument.

The similar call in the then new hyperparser module is correct.

 bod = parser.find_good_parse_start(
     editwin._build_char_in_string_func(startatindex))

The erroneous call has not been detected in execution because of this bug:
  not is_char_in_string
is too general.  It should have been specifically
  is_char_in_string is None
so False does not trigger the early return, but gets called, raising TypeError.  We should add a test that find_good_parse_start(False, lambda: True) does so, with reference to this issue.

Both calls to fgps (editor and hyperparser) pass _build_char_in_string_func(initial_start), which unconditionally returns a function.  So I think we can delete '=None' and the early return, rather than changing the early return condition.

----------
stage:  -> test needed

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

From report at bugs.python.org  Fri Mar  2 23:15:02 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Mar 2018 04:15:02 +0000
Subject: [issue32989] IDLE: Incorrect signature in call from editor to
 pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520050502.16.0.467229070634.issue32989@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If fgps never returns 0, then returning 0 instead of None would allow simplification of

                if bod is not None or startat == 1:
                    break
            parser.set_lo(bod or 0)

to
                if bod or startat == 1:
                    break
            parser.set_lo(bod)

If it can (or should) ever return 0, separate from None, I would like to see a test case for that.  We could then think about whether or not the loop should break on 0 as well as None.

Perhaps separate issue: the 'if use_ps1' statements in editor and hyperparser, and a couple of lines before, is nearly identical, and could be factored into a separate editor method that returns a parser instance ready for analysis.  It could then be tested in isolation.  The method should return a parser instance ready for analysis.

Both blocks have an explicit set_lo(0) call, which does nothing, and could be removed.

----------

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

From report at bugs.python.org  Fri Mar  2 23:27:05 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Mar 2018 04:27:05 +0000
Subject: [issue32989] IDLE: Incorrect signature in call from editor to
 pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520051225.24.0.467229070634.issue32989@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since _synchre is never passed, it should not be a parameter either.  I think we should either limit this to fixing the call, with no unit test added, or expand to 'fix find_good_parse_start and buggy call', with revised tests.

It might be interesting to verify that the time it takes to find a better start point is less that the time saved in later analysis.

----------

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

From report at bugs.python.org  Sat Mar  3 01:56:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Mar 2018 06:56:51 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1520060211.94.0.467229070634.issue32980@psf.upfronthosting.co.za>


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

Yeah, dropping _PyFrame_Init/Fini for 3.8+ would make sense.

It's PyByteArray_Init/Fini that probably aren't worth the hassle of removing, since the lack of a leading underscore means they'd need to go through a deprecation cycle.

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

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

From report at bugs.python.org  Sat Mar  3 03:01:35 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 03 Mar 2018 08:01:35 +0000
Subject: [issue32388] Remove cross-version binary compatibility
In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za>
Message-ID: <1520064095.68.0.467229070634.issue32388@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I'm ok with "removing" this "guarantee" (although it seems too late to apply this specific change to 3.7 now).

While Cython users do ask for a way to build cross-version binaries from time to time, it's neither supported nor planned, and the underlying problem is IMHO solved better via tooling like the manylinux wheel build.

I also generally consider it good to let user code take advantage of new features in new CPython releases, even if it means that they need to retranslate their Cython code from time to time. The 1.5 years release cycle of CPython should exceed that of most "still in maintenance" extension modules out there, and it's long enough to not impose a real burden on their maintainers.

----------

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

From report at bugs.python.org  Sat Mar  3 04:25:58 2018
From: report at bugs.python.org (Andrea Celletti)
Date: Sat, 03 Mar 2018 09:25:58 +0000
Subject: [issue32990] Supporting extensible format(PCM) for
 wave.open(read-mode)
Message-ID: <1520069158.75.0.467229070634.issue32990@psf.upfronthosting.co.za>


New submission from Andrea Celletti <celletti.andrea87 at gmail.com>:

The wave.Wave_read class currently supports 8, 16, 24, and 32 bit PCM files.
Wave files are only supported if the wFormatTag in the format chunk matches the flag WAVE_FORMAT_PCM, which is correct but incomplete for 24 bit files.

According to the specification the WAVE_FORMAT_EXTENSIBLE format should be used whenever the actual number of bits/sample is not equal to the container size. Based on this specification, most applications export 24 bit PCM with the WAVE_FORMAT_EXTENSIBLE flag since 24 is stored in container size 32. 
Importing these files causes wave.open to raise an exception.

The specification also explains how to detect 24PCM exported in this fashion as "The first two bytes of the GUID form the sub-code specifying the data format code, e.g. WAVE_FORMAT_PCM.". In essence, we have to look at the first two bytes of the SubFormat tag and that will tell us if this file is PCM.

Based on this premise, it appears to me that there is no reason for not adding support for both format specification as the rest of the file is exactly the same for both.

I am attaching a file that can be used to test the exception being raised.

Source: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html

----------
components: Library (Lib)
files: pluck-pcm24-ext.wav
messages: 313183
nosy: acelletti
priority: normal
severity: normal
status: open
title: Supporting extensible format(PCM) for wave.open(read-mode)
type: enhancement
Added file: https://bugs.python.org/file47467/pluck-pcm24-ext.wav

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

From report at bugs.python.org  Sat Mar  3 04:37:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Mar 2018 09:37:11 +0000
Subject: [issue32990] Supporting extensible format(PCM) for
 wave.open(read-mode)
In-Reply-To: <1520069158.75.0.467229070634.issue32990@psf.upfronthosting.co.za>
Message-ID: <1520069831.52.0.467229070634.issue32990@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.8

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

From report at bugs.python.org  Sat Mar  3 06:53:46 2018
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 03 Mar 2018 11:53:46 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520078026.7.0.467229070634.issue32963@psf.upfronthosting.co.za>


Martijn Pieters <mj at python.org> added the comment:

Thanks for the quick fix, sorry I didn't have a PR for this one!

----------

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

From report at bugs.python.org  Sat Mar  3 06:55:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Mar 2018 11:55:24 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520078124.4.0.467229070634.issue32758@psf.upfronthosting.co.za>


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

Thank you Brett! The comment LGTM.

Is it worth to add warnings to other functions?

* compile(), exec() and eval(). They are crashed due to recursion in the AST optimizer. This is a regression of 3.7. compile(..., PyCF_ONLY_AST) is the same as ast.parse() and crashed in older versions.

* dbm.dumb.open(). It calls ast.literal_eval(). The dbm.dumb databases are considered slow but portable. Before issue22885 this function was even more vulnerable due to using eval(). Since changing it to ast.literal_eval() some developers could consider it safe, but this is not true.

* A number of functions in the inspect module which directly or indirectly call ast.parse() on the __text_signature__ attribute. The risk of this vulnerability is very low.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Sat Mar  3 07:19:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Mar 2018 12:19:32 +0000
Subject: [issue32964] Reuse a testing implementation of the path protocol in
 tests
In-Reply-To: <1519760407.45.0.467229070634.issue32964@psf.upfronthosting.co.za>
Message-ID: <1520079572.57.0.467229070634.issue32964@psf.upfronthosting.co.za>


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


New changeset fbdd075c64a5229dfa26632cf1b2cf2361dc5003 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-32964: Reuse a testing implementation of the path protocol in tests. (GH-5930). (GH-5958)
https://github.com/python/cpython/commit/fbdd075c64a5229dfa26632cf1b2cf2361dc5003


----------

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

From report at bugs.python.org  Sat Mar  3 07:19:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Mar 2018 12:19:54 +0000
Subject: [issue32964] Reuse a testing implementation of the path protocol in
 tests
In-Reply-To: <1519760407.45.0.467229070634.issue32964@psf.upfronthosting.co.za>
Message-ID: <1520079594.35.0.467229070634.issue32964@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/issue32964>
_______________________________________

From report at bugs.python.org  Sat Mar  3 10:59:12 2018
From: report at bugs.python.org (Thomas Nyberg)
Date: Sat, 03 Mar 2018 15:59:12 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1520092752.24.0.467229070634.issue32980@psf.upfronthosting.co.za>


Change by Thomas Nyberg <tomnyberg at gmail.com>:


----------
pull_requests: +5732

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

From report at bugs.python.org  Sat Mar  3 10:59:59 2018
From: report at bugs.python.org (Thomas Nyberg)
Date: Sat, 03 Mar 2018 15:59:59 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1520092799.09.0.467229070634.issue32980@psf.upfronthosting.co.za>


Thomas Nyberg <tomnyberg at gmail.com> added the comment:

ince I originated this issue and I think I understand the concerns, I figured I could speed up the back and forth in this thread by opening this new PR which removes the `_PyFrame_Init()` function. I couldn't find any `_PyFrame_Fini()` function in the source so maybe you two are confused and there wasn't a corresponding Fini function? (I presume the more likely scenario is that I am the one who is confused so feel free to correct that confusion in that case. :) )

----------

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

From report at bugs.python.org  Sat Mar  3 12:53:46 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Mar 2018 17:53:46 +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: <1520099626.13.0.467229070634.issue32730@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Since I took the time to do a brain dump of my thinking here, feel free to review/contribute to https://github.com/zooba/PyLauncher/wiki

Note that the code in that repo doesn't match the wiki page, and while I think it's good code I do now think it's the wrong approach. So ignore that and just read the "spec"

----------

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

From report at bugs.python.org  Sat Mar  3 12:59:03 2018
From: report at bugs.python.org (Jon Janzen)
Date: Sat, 03 Mar 2018 17:59:03 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520099943.55.0.467229070634.issue26707@psf.upfronthosting.co.za>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

Hello,

I have attached a file extracted from the database of the 2Do App for iOS and macOS. The file contains information about tags used in the app.

plistlib cannot currently parse this file because it lacks the ability to read byte 0x80 (UID).

I believe the documentation for generating these type of files can be found at: https://developer.apple.com/documentation/foundation/nskeyedarchiver

----------
nosy: +bigfootjon
Added file: https://bugs.python.org/file47468/cat.plist

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

From report at bugs.python.org  Sat Mar  3 13:02:23 2018
From: report at bugs.python.org (Andrea Celletti)
Date: Sat, 03 Mar 2018 18:02:23 +0000
Subject: [issue32990] Supporting extensible format(PCM) for
 wave.open(read-mode)
In-Reply-To: <1520069158.75.0.467229070634.issue32990@psf.upfronthosting.co.za>
Message-ID: <1520100143.06.0.467229070634.issue32990@psf.upfronthosting.co.za>


Andrea Celletti <celletti.andrea87 at gmail.com> added the comment:

I am currently working on a patch for this.

When done can I try pushing this in 3.7 rather than 3.8?

It is not much of an enhancement but rather fixing the code that raises an error for a perfectly valid PCM wave file (bugfix).

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

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

From report at bugs.python.org  Sat Mar  3 13:09:46 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Mar 2018 18:09:46 +0000
Subject: [issue32990] Supporting extensible format(PCM) for
 wave.open(read-mode)
In-Reply-To: <1520069158.75.0.467229070634.issue32990@psf.upfronthosting.co.za>
Message-ID: <1520100586.45.0.467229070634.issue32990@psf.upfronthosting.co.za>


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

Thanks for working on this.  Please follow the process in our Developers Guide and submit a PR against the master branch (for 3.8).  After a core developer reviews it and if it is accepted, we can then decide about backports to other release branches.  Also, if you haven't already, please make sure to read the section on licensing and sign a contributor agreement:

https://devguide.python.org/pullrequest/

----------
nosy: +ned.deily
versions: +Python 3.8

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

From report at bugs.python.org  Sat Mar  3 13:59:41 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Mar 2018 18:59:41 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520103581.68.0.467229070634.issue32758@psf.upfronthosting.co.za>


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

You're probably right and it's worth propagating the warning a bit wider.

----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Sat Mar  3 14:00:27 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Mar 2018 19:00:27 +0000
Subject: [issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded
In-Reply-To: <1519722263.23.0.467229070634.issue32963@psf.upfronthosting.co.za>
Message-ID: <1520103627.82.0.467229070634.issue32963@psf.upfronthosting.co.za>


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

No need to apologize! We all only have so much free time.

----------

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

From report at bugs.python.org  Sat Mar  3 15:51:59 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Mar 2018 20:51:59 +0000
Subject: [issue32919] csv.reader() to support QUOTE_ALL
In-Reply-To: <1519361723.9.0.467229070634.issue32919@psf.upfronthosting.co.za>
Message-ID: <1520110319.17.0.467229070634.issue32919@psf.upfronthosting.co.za>


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

QUOTE_ALL only makes sense as an output control parameter, IMO.  It is an output discipline but doesn't say anything about semantics.  In csv format, an empty field and a field containing the empty quoted string are completely equivalent.  I would be -1 on adding an option that differentiated them.

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

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

From report at bugs.python.org  Sat Mar  3 18:39:13 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 03 Mar 2018 23:39:13 +0000
Subject: [issue32989] IDLE: Incorrect signature in call from editor to
 pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520120353.35.0.467229070634.issue32989@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5734
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Mar  3 19:01:48 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 00:01:48 +0000
Subject: [issue32989] IDLE: Incorrect signature in call from editor to
 pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520121708.53.0.467229070634.issue32989@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I didn't incorporate all the suggestions into the first PR for this so that it could focus on the parameter change and the tests.  `newline_and_indent_event` does a lot, so I want to make sure the tests look good.  I was also going to add tests for the other indent methods (some are called from `newline_and_indent_event`), but, again, wanted to focus on the bug fix.

Oddly enough, I don't know how to show in the tests that the bug fix makes any difference.  Finding a "good parse start" is more about parsing faster, but, as the tests show from running all the tests with the `context_use_ps1` set to True and False, the results are the same.  Of course, with one or two lines of code, they would be because there isn't much text to parse and ignore.  I did have some tests that had longer text to show that `bod` was being calculated, but I wasn't sure if I should include those for the main goal of testing  the newline and indent.

>  Both calls to fgps (editor and hyperparser) pass _build_char_in_string_func(initial_start), which unconditionally returns a function.  So I think we can delete '=None' and the early return, rather than changing the early return condition.

I'd like to address the on another PR that focuses more on refactoring pyparse than this one.

> If fgps never returns 0

It can return 0, separately from None, as some of the tests on this PR show.

> Perhaps separate issue: the 'if use_ps1' statements in editor and hyperparser, and a couple of lines before, is nearly identical, and could be factored into a separate editor method that returns a parser instance ready for analysis.  It could then be tested in isolation.  The method should return a parser instance ready for analysis.

I agree.  The duplicated code is bugging me.  :-)

---------
One addtional note:  I think that all the indent-related methods in EditorWindow can be factored out into their own class.   It will help make EditorWindow a little more manageable.

----------
stage: patch review -> test needed

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

From report at bugs.python.org  Sat Mar  3 19:16:44 2018
From: report at bugs.python.org (Zac Medico)
Date: Sun, 04 Mar 2018 00:16:44 +0000
Subject: [issue21998] asyncio: support fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1520122604.28.0.467229070634.issue21998@psf.upfronthosting.co.za>


Zac Medico <zmedico at gentoo.org> added the comment:

I'm not sure about possible use cases that might conflict with this approach, but using a separate event loop for each pid seems very reasonable to me, as follows:

_default_policy = asyncio.get_event_loop_policy()
_pid_loop = {}

class MultiprocessingPolicy(asyncio.AbstractEventLoopPolicy):
	def get_event_loop(self):
		pid = os.getpid()
		loop = _pid_loop.get(pid)
		if loop is None:
			loop = self.new_event_loop()
			_pid_loop[pid] = loop
		return loop

	def new_event_loop(self):
		return _default_policy.new_event_loop()

asyncio.set_event_loop_policy(MultiprocessingPolicy())

----------
nosy: +zmedico

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

From report at bugs.python.org  Sat Mar  3 23:47:12 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Mar 2018 04:47:12 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
Message-ID: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In Python 3.6, one could find doctests on a namespace package:

```
$ mkdir foo
$ python3.6
Python 3.6.4 (v3.6.4:d48ecebad5, Dec 18 2017, 21:07:28)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
>>> foo.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'foo' has no attribute '__file__'
>>> import doctest
>>> doctest.DocTestFinder().find(foo)
[]
```

In recent builds of Python 3.7, these namespace packages inherited a `__file__` attribute whose value is `None`, which causes DocTestFinder.find to fail:

```
$ python
Python 3.7.0b2 (tags/v3.7.0b2:b0ef5c979b, Feb 27 2018, 20:38:21)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import doctest
>>> import foo
>>> foo.__file__
>>> doctest.DocTestFinder().find(foo)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/doctest.py", line 893, in find
    file = inspect.getsourcefile(obj)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 687, in getsourcefile
    if any(filename.endswith(s) for s in all_bytecode_suffixes):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 687, in <genexpr>
    if any(filename.endswith(s) for s in all_bytecode_suffixes):
AttributeError: 'NoneType' object has no attribute 'endswith'
```

Scanning through the recent changes, issue32305 seems to be related, but when I look at the code ancestry, I can't see the related commits on the 3.7 branch, so I couldn't immediately confirm if it is indeed implicated.

I encountered this issue when testing jaraco.functools on Python 3.7.0b2 on macOS, but did not encounter it on Python 3.7.0a4+ as found on the Travis nightly builds. More details are logged in https://github.com/pytest-dev/pytest/issues/3276.

I'm not sure yet whether inspect.getfile should be adapted to raise a TypeError in this case, or if doctest.DocTestFinder.find should account for getfile returning None.

If we choose to update inspect.getfile, I should caution there's a bit of copy/paste there, so two branches of code will need to be updated.

Barry, I'd love to hear what your thoughts are on this and what you'd like to do. And definitely let me know if I can help.

----------
components: Interpreter Core, Library (Lib)
keywords: 3.7regression
messages: 313197
nosy: barry, jason.coombs
priority: normal
severity: normal
status: open
title: AttributeError in doctest.DocTestFinder.find
versions: Python 3.7

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

From report at bugs.python.org  Sun Mar  4 00:33:36 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 05:33:36 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520141616.14.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


New changeset 0e6c8ee2358a2e23117501826c008842acb835ac by Benjamin Peterson (Jamie Davis) in branch 'master':
bpo-32981: Fix catastrophic backtracking vulns (#5955)
https://github.com/python/cpython/commit/0e6c8ee2358a2e23117501826c008842acb835ac


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

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

From report at bugs.python.org  Sun Mar  4 00:33:43 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 04 Mar 2018 05:33:43 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520141623.08.0.467229070634.issue32981@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


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

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

From report at bugs.python.org  Sun Mar  4 00:36:10 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Mar 2018 05:36:10 +0000
Subject: [issue32874] IDLE: Add tests for pyparse
In-Reply-To: <1519055766.11.0.467229070634.issue32874@psf.upfronthosting.co.za>
Message-ID: <1520141770.74.0.467229070634.issue32874@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

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

From report at bugs.python.org  Sun Mar  4 00:41:38 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Mar 2018 05:41:38 +0000
Subject: [issue31500] IDLE: Tiny font on HiDPI display
In-Reply-To: <1505674446.46.0.331613884884.issue31500@psf.upfronthosting.co.za>
Message-ID: <1520142098.28.0.467229070634.issue31500@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I assume that the 2nd patch, by Serhiy, fixed the issue.

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

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

From report at bugs.python.org  Sun Mar  4 00:44:44 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 05:44:44 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520142284.8.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


----------
pull_requests: +5736

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

From report at bugs.python.org  Sun Mar  4 00:47:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 05:47:22 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520142442.93.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


----------
pull_requests: +5737

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

From report at bugs.python.org  Sun Mar  4 00:55:09 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 05:55:09 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520142909.87.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


New changeset 0902a2d6b2d1d9dbde36aeaaccf1788ceaa97143 by Benjamin Peterson (Miss Islington (bot)) in branch '3.7':
bpo-32981: Fix catastrophic backtracking vulns (GH-5955)
https://github.com/python/cpython/commit/0902a2d6b2d1d9dbde36aeaaccf1788ceaa97143


----------

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

From report at bugs.python.org  Sun Mar  4 01:06:03 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 06:06:03 +0000
Subject: [issue32980] Remove functions that do nothing in _Py_InitializeCore()
In-Reply-To: <1519923433.61.0.467229070634.issue32980@psf.upfronthosting.co.za>
Message-ID: <1520143563.59.0.467229070634.issue32980@psf.upfronthosting.co.za>


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


New changeset 7023644e0c310a3006c984318c2c111c468735b4 by Benjamin Peterson (Thomas Nyberg) in branch 'master':
closes bpo-32980 Remove _PyFrame_Init (GH-5965)
https://github.com/python/cpython/commit/7023644e0c310a3006c984318c2c111c468735b4


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

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

From report at bugs.python.org  Sun Mar  4 01:18:19 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 06:18:19 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520144299.62.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


New changeset e052d40cea15f582b50947f7d906b39744dc62a2 by Benjamin Peterson in branch '2.7':
[2.7] bpo-32981: Fix catastrophic backtracking vulns (GH-5955)
https://github.com/python/cpython/commit/e052d40cea15f582b50947f7d906b39744dc62a2


----------

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

From report at bugs.python.org  Sun Mar  4 01:59:15 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Mar 2018 06:59:15 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520146755.04.0.467229070634.issue32981@psf.upfronthosting.co.za>


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


New changeset c9516754067d71fd7429a25ccfcb2141fc583523 by Benjamin Peterson in branch '3.6':
[3.6] bpo-32981: Fix catastrophic backtracking vulns (GH-5955)
https://github.com/python/cpython/commit/c9516754067d71fd7429a25ccfcb2141fc583523


----------

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

From report at bugs.python.org  Sun Mar  4 02:41:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Mar 2018 07:41:58 +0000
Subject: [issue31500] IDLE: Tiny font on HiDPI display
In-Reply-To: <1505674446.46.0.331613884884.issue31500@psf.upfronthosting.co.za>
Message-ID: <1520149318.14.0.467229070634.issue31500@psf.upfronthosting.co.za>


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

What about 2.7?

----------

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

From report at bugs.python.org  Sun Mar  4 03:38:05 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Mar 2018 08:38:05 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start and its bad
 editor call
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520152685.36.0.467229070634.issue32989@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with limiting the scope to the None bug and the faulty call.  However, we should think of the None fix as primary, and the new test thereof as the primary test.  Fixing the None check exposes the call bug, which we also fix.  I change the title here and on PR.

As you noted, the new editor TestCase is not directly relevant to testing the double fix except to show that there is no change in indent.  The way to do that is to pass None instead of the in-string function.  I did that (temporarily!) and the test passes, meaning that the indents are the same.  (I do however think some of them are dubious, and I want to mark those cases.)

We could have made editor tests that initially failed by exposing bod as an instance attribute (as we have done before), and including a longer test case for which bod is a positive int.  However, bod should remain local.

As an alternative, for experimentation, I added print(bod).  The values for the patch are 0, None, None, None, None, None, 0, 0, None.  I added '  a\n' to 'Block opener - indents +1 level.' and changed the mark and the 5th 'None' became '4'.

The fact that passing None and _build_char_in_string_func(startatindex) result in the same indents raises the question of whether the call has any benefit in reducing net time after the followup call to get_continuation_type().  Maybe tomorrow I will try to write a good timeit test.

In the meanwhile, to get some idea of how well find_good_parse_start finds good parse starts, I restarted IDLE in a console with the print still added, loaded editor.py, and hit RETURN followed by UNDO, in various places. The first non-zero bod, 812, comes with the cursor at the end of 'def _sphinx_version():'  812 is probably the beginning of the line.  After "if __name__ == '__main__':" near the end, 1416.  After the final "run(_editor_window)", 1654.  The highest value I got in about 10 tries past the middle, 1931.  To me, this is pathetically bad.

I tried turning on CodeContext and got the same results where I tested.  bod should just be the beginning of the last context line.  I am not optimistic about timing results.

----------
title: IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start -> IDLE: Fix pyparse.find_good_parse_start and its bad editor call

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

From report at bugs.python.org  Sun Mar  4 04:18:51 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Mar 2018 09:18:51 +0000
Subject: [issue31500] IDLE: Tiny font on HiDPI display
In-Reply-To: <1505674446.46.0.331613884884.issue31500@psf.upfronthosting.co.za>
Message-ID: <1520155131.89.0.467229070634.issue31500@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I take it you want this reopened.  I have not touched IDLE 2.7 for over a year, but since a) there have been no complaints about the patch in released 3.6.3/4, b) we recommend the same tk 8.5.18 for both 2.7 and 3.6, and c) this is a crippling regression upon equipment upgrade, I will review and manually test on Windows a combined backport of both PRs first tested on a Linux or Mac system.  It should be tested on a HiDPI system before a merge.

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Mar  4 05:41:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Mar 2018 10:41:51 +0000
Subject: [issue32857] tkinter after_cancel does not behave correctly when
 called with id=None
In-Reply-To: <1518787214.25.0.467229070634.issue32857@psf.upfronthosting.co.za>
Message-ID: <1520160111.47.0.467229070634.issue32857@psf.upfronthosting.co.za>


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


New changeset 74382a3f175ac285cc924a73fd758e8dc3cc41bb by Serhiy Storchaka (Cheryl Sabella) in branch 'master':
bpo-32857: Raise error when tkinter after_cancel() is called with None. (GH-5701)
https://github.com/python/cpython/commit/74382a3f175ac285cc924a73fd758e8dc3cc41bb


----------

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

From report at bugs.python.org  Sun Mar  4 05:42:56 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 04 Mar 2018 10:42:56 +0000
Subject: [issue32857] tkinter after_cancel does not behave correctly when
 called with id=None
In-Reply-To: <1518787214.25.0.467229070634.issue32857@psf.upfronthosting.co.za>
Message-ID: <1520160176.84.0.467229070634.issue32857@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5738

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

From report at bugs.python.org  Sun Mar  4 05:44:56 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 04 Mar 2018 10:44:56 +0000
Subject: [issue32857] tkinter after_cancel does not behave correctly when
 called with id=None
In-Reply-To: <1518787214.25.0.467229070634.issue32857@psf.upfronthosting.co.za>
Message-ID: <1520160296.07.0.467229070634.issue32857@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5739

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

From report at bugs.python.org  Sun Mar  4 05:57:02 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 04 Mar 2018 10:57:02 +0000
Subject: [issue28716] Fractions instantiation revisited
In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za>
Message-ID: <1520161022.01.0.467229070634.issue28716@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Just FYI and as further motivation, I reimplemented this dedicated parser for quicktions (in Cython, so the timings and speedups are not comparable).

https://github.com/scoder/quicktions/commit/cc034e07325ec492decdb7b1bcca69246cc780fd

I was able to get another quite visible improvement by caching the values of "10 ** shift" for 0 <= shift < 58 in a tuple. Higher values are very unlikely in practice, and the memory size of a tuple with 58 values gives a nice multiple of the usual cache line size. (I originally stored 64 values in my commit but then cut it down later.)

https://github.com/scoder/quicktions/commit/c20add53dc4936d70eb0daa370946a600adddca9

I suspect that the difference won't be as big for the Python implementation, but it still seems worth a try.

The overall speedup that I got, compared to the initial regex implementation, is 50-70%.

[regex]  $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("153456/789344")'
200000 loops, best of 5: 1.19 usec per loop
[native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("153456/789344")'
500000 loops, best of 5: 593 nsec per loop

[regex]  $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("15.3456789E+4")'
100000 loops, best of 5: 2.3 usec per loop
[native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 'F("15.3456789E+4")'
500000 loops, best of 5: 667 nsec per loop

It could be even higher if I additionally moved the int() integer parsing into Cython. Might try that at some point. But that's also not something that concerns the implementation in CPython.

----------
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Sun Mar  4 06:42:47 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 04 Mar 2018 11:42:47 +0000
Subject: [issue32857] tkinter after_cancel does not behave correctly when
 called with id=None
In-Reply-To: <1518787214.25.0.467229070634.issue32857@psf.upfronthosting.co.za>
Message-ID: <1520163767.34.0.467229070634.issue32857@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 73a43960c7be50e136c5482404980175cb99f611 by Miss Islington (bot) in branch '3.6':
bpo-32857: Raise error when tkinter after_cancel() is called with None. (GH-5701)
https://github.com/python/cpython/commit/73a43960c7be50e136c5482404980175cb99f611


----------
nosy: +miss-islington

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

From report at bugs.python.org  Sun Mar  4 07:00:35 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 04 Mar 2018 12:00:35 +0000
Subject: [issue32857] tkinter after_cancel does not behave correctly when
 called with id=None
In-Reply-To: <1518787214.25.0.467229070634.issue32857@psf.upfronthosting.co.za>
Message-ID: <1520164835.85.0.467229070634.issue32857@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a5303dd9c263b337f02dda0038f2f5a10208140c by Miss Islington (bot) in branch '3.7':
bpo-32857: Raise error when tkinter after_cancel() is called with None. (GH-5701)
https://github.com/python/cpython/commit/a5303dd9c263b337f02dda0038f2f5a10208140c


----------

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

From report at bugs.python.org  Sun Mar  4 07:39:17 2018
From: report at bugs.python.org (Petter Strandmark)
Date: Sun, 04 Mar 2018 12:39:17 +0000
Subject: [issue32992] unittest: Automatically run coroutines in a loop
Message-ID: <1520167156.98.0.467229070634.issue32992@psf.upfronthosting.co.za>


New submission from Petter Strandmark <petter.strandmark at gmail.com>:

I am wondering whether it would be useful for unittest.TestCase to automatically run test methods that are coroutines within the default asyncio loop.

Example:

	class TestAsync(unittest.TestCase):

		async def test_foo(self):
			result = await foo()
			self.assertEqual(result, 42)

the test runner would then run test_foo within the default loop. If needed, we could also add functionality for providing a loop other than the default to the test class.

It seems to me that this functionality would be pretty easy to add to Lib/unittest/case.py:615 .

Personally, I think it would be useful. Right now I have to append every test case with a personal @run_in_loop decorator and I think unittest.TestCase could do this for me without breaking anything.

----------
components: Library (Lib)
messages: 313211
nosy: Petter Strandmark
priority: normal
severity: normal
status: open
title: unittest: Automatically run coroutines in a loop
type: enhancement

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

From report at bugs.python.org  Sun Mar  4 08:05:12 2018
From: report at bugs.python.org (yao zhihua)
Date: Sun, 04 Mar 2018 13:05:12 +0000
Subject: [issue32993] issue30657 Incomplete fix
Message-ID: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>


New submission from yao zhihua <hackyzh001 at gmail.com>:

Due to the incomplete fix for CVE-2011-1521, urllib and urllib2 exist for this vulnerability and I tested on the version of Python 3.4.8 (default, Mar 4 2018, 20:37:04).I am sorry that I do not know how to fix it.

----------
components: Library (Lib)
files: poc.py
messages: 313212
nosy: yao zhihua
priority: normal
severity: normal
status: open
title: issue30657 Incomplete fix
type: security
versions: Python 3.4
Added file: https://bugs.python.org/file47469/poc.py

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

From report at bugs.python.org  Sun Mar  4 08:22:12 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 13:22:12 +0000
Subject: [issue28955] Not matched behavior of numeric comparison with the
 documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1520169732.79.0.467229070634.issue28955@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.7, Python 3.8 -Python 3.5

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

From report at bugs.python.org  Sun Mar  4 08:45:03 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 13:45:03 +0000
Subject: [issue32839] Add after_info as a function to tkinter
In-Reply-To: <1518529095.33.0.467229070634.issue32839@psf.upfronthosting.co.za>
Message-ID: <1520171103.61.0.467229070634.issue32839@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
dependencies: +tkinter after_cancel does not behave correctly when called with id=None

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

From report at bugs.python.org  Sun Mar  4 09:56:57 2018
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 04 Mar 2018 14:56:57 +0000
Subject: [issue32933] mock_open does not support iteration around text files.
In-Reply-To: <1519462718.87.0.467229070634.issue32933@psf.upfronthosting.co.za>
Message-ID: <1520175417.15.0.467229070634.issue32933@psf.upfronthosting.co.za>


Change by Anthony Flury <anthony.flury at btinternet.com>:


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

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

From report at bugs.python.org  Sun Mar  4 10:26:53 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 15:26:53 +0000
Subject: [issue32839] Add after_info as a function to tkinter
In-Reply-To: <1518529095.33.0.467229070634.issue32839@psf.upfronthosting.co.za>
Message-ID: <1520177213.57.0.467229070634.issue32839@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

A few questions about returning the Python function name (specifically, how to derive it).  This doesn't address the open issue with what to do about a Tcl command not tied to a Python function.

1.  Serhiy wrote "and the API for restoring the original Python callable is private."  What is that API?

2.  In the _register method, the Tcl command name is the callback ID + the function name:
        f = CallWrapper(callback, None, self._root).__call__
        cbname = repr(id(f))
        try:
            callback = callback.__func__
        except AttributeError:
            pass
        try:
            cbname = cbname + callback.__name__
        except AttributeError:
            pass 
So, with the values returned from tk.call('after', 'info', id) as (script, type), the Python function should be the same as script.lstrip('0123456789').  I'm not sure if that would be the best way to get the name back.

3.  In tkinter, there is a list created/added to during _register:
        self._tclCommands.append(cbname)
where cbname is the Tcl command name (as defined by the code in q2 above).  Would it be possible to change _tclCommands to a dict mapping Tcl command name to Python function name?  _tclCommands already has some logic around it, including .remove functions, so I think a dictionary would be more efficient for the exisitng purposes.  Since it's semi-private, is there a fear with backward compatibility if it changes from a list to a dict?  Is it better to add a new dict variable?

Thanks!

----------

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

From report at bugs.python.org  Sun Mar  4 10:27:31 2018
From: report at bugs.python.org (Eric Osborne)
Date: Sun, 04 Mar 2018 15:27:31 +0000
Subject: [issue32820] Add __format__ method to ipaddress
In-Reply-To: <1519446951.22.0.467229070634.issue32820@psf.upfronthosting.co.za>
Message-ID: <CA+97oKPtUETRsXeVxreHuGLunymfn-QLzYW2dFFjY8WQc8G2Mg@mail.gmail.com>


Eric Osborne <eric at notcom.com> added the comment:

I have pushed out new diffs.

* moved __format__ to _BaseAddress, where it should have been in the first
place
* redid format parser as regexp, as it was getting awfully complicated
* added support for 'X'
* added support for 's' by falling through to regular format()
* added IPv6 to the test suite

This was a decent-sized change, but all the tests pass so it looks OK to me.
As per request, I defer importing re and compiling the necessary regexp
until it's absolutely necessary. This is significantly slower than
importing re and compiling the regexp when ipaddress is imported.

localized compile and import
In [4]: %timeit f'{a:#_b}'
7.05 ?s ? 34.2 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

toplevel compile and import
In [2]: %timeit f'{a:#_b}'
5.34 ?s ? 17 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

Is this worth trying to get clever about? It doesn't matter in my use case,
and I could make a reasonable argument either way. I'm tempted to leave it
localized, as I can't imagine a case where formatting eleventy billion IP
addresses as padded binary is all that time-sensitive.  On the other hand,
I'm also not sure how Pythonic it is to stick an import statement 20 lines
deep in a dunder method, so I'm open to suggestions.

eric

----------

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

From report at bugs.python.org  Sun Mar  4 10:43:02 2018
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 04 Mar 2018 15:43:02 +0000
Subject: [issue32933] mock_open does not support iteration around text files.
In-Reply-To: <1519462718.87.0.467229070634.issue32933@psf.upfronthosting.co.za>
Message-ID: <1520178182.54.0.467229070634.issue32933@psf.upfronthosting.co.za>


Change by Anthony Flury <anthony.flury at btinternet.com>:


----------
pull_requests: +5741

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

From report at bugs.python.org  Sun Mar  4 10:50:24 2018
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 04 Mar 2018 15:50:24 +0000
Subject: [issue32933] mock_open does not support iteration around text files.
In-Reply-To: <1519462718.87.0.467229070634.issue32933@psf.upfronthosting.co.za>
Message-ID: <1520178624.87.0.467229070634.issue32933@psf.upfronthosting.co.za>


Change by Anthony Flury <anthony.flury at btinternet.com>:


----------
pull_requests: +5742

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

From report at bugs.python.org  Sun Mar  4 11:20:45 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 04 Mar 2018 16:20:45 +0000
Subject: [issue32933] mock_open does not support iteration around text files.
In-Reply-To: <1519462718.87.0.467229070634.issue32933@psf.upfronthosting.co.za>
Message-ID: <1520180445.3.0.467229070634.issue32933@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

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

From report at bugs.python.org  Sun Mar  4 11:41:53 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Mar 2018 16:41:53 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520181713.71.0.467229070634.issue32991@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The main questions I have before proceeding with creating tests relate to what interfaces Python wishes to support. Here's the decision tree I have in my head.

- Retain the change of adding a __file__ attribute to namespace packages for Python 3.7?
  yes:
  - Should inspect.getfile still raise a TypeError on a namespace package?
    no:
    - The NEWS file should reflect this change also.
    - doctest.DocTestFinder.find should account for this change.
    yes:
    - Capture with a test and and restore that expectation.
  no:
  - The change should be reverted.
- Regardless, the test suite should capture and assert that doctest.DocTestFinder.find should succeed on a namespace package.

----------

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

From report at bugs.python.org  Sun Mar  4 11:43:34 2018
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 04 Mar 2018 16:43:34 +0000
Subject: [issue32933] mock_open does not support iteration around text files.
In-Reply-To: <1519462718.87.0.467229070634.issue32933@psf.upfronthosting.co.za>
Message-ID: <1520181814.92.0.467229070634.issue32933@psf.upfronthosting.co.za>


Change by Anthony Flury <anthony.flury at btinternet.com>:


----------
pull_requests: +5743

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

From report at bugs.python.org  Sun Mar  4 12:05:10 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Mar 2018 17:05:10 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520183110.77.0.467229070634.issue32991@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I tried creating a test, but I'm struggling. I added [this patch](https://gist.github.com/e795a9a34594d202711aedf22c484af9), and tried to run it, but it's not being run.

```
$ ./python.exe Tools/scripts/run_tests.py 'test_doctest'
/Users/jaraco/Dropbox/code/public/cpython/python.exe -u -W default -bb -E -m test -r -w -j 0 -u all,-largefile,-audio,-gui test_doctest
Using random seed 3885464
Run tests in parallel using 6 child processes
0:00:00 load avg: 2.02 [1/1] test_doctest passed
1 test OK.

Total duration: 828 ms
Tests result: SUCCESS
```

I'm pretty sure doctest doesn't have any unit tests, but only functional tests exercising actual doctests.

I don't understand Python test framework enough to know how to create a discoverable unit test. I could use some help with how one could wire up the test_doctest module to run a unit test.

----------

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

From report at bugs.python.org  Sun Mar  4 14:10:41 2018
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 04 Mar 2018 19:10:41 +0000
Subject: [issue32993] issue30657 Incomplete fix
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520190641.03.0.467229070634.issue32993@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

@Yao, sorry, I don't understand it.
What is POC trying to demonstrate? How is it related to https://bugs.python.org/issue30657 

And CVE is this: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1521

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sun Mar  4 14:37:26 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 19:37:26 +0000
Subject: [issue28626] Tutorial: rearrange discussion of output formatting to
 encourage f-strings
In-Reply-To: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za>
Message-ID: <1520192246.07.0.467229070634.issue28626@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

@akuchling

Would you be able to make a PR for this patch?  Thanks.

----------
nosy: +csabella
versions: +Python 3.8 -Python 3.6

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

From report at bugs.python.org  Sun Mar  4 15:47:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Mar 2018 20:47:27 +0000
Subject: [issue32994] Building the html documentation is broken
Message-ID: <1520196447.07.0.467229070634.issue32994@psf.upfronthosting.co.za>


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

$ make html BLURB="python3 -m blurb"
mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees -D latex_elements.papersize=  . build/html 
Running Sphinx v1.5.6
loading pickled environment... not yet created

Theme error:
no theme named 'python_docs_theme' found (missing theme.conf?)
Makefile:43: recipe for target 'build' failed
make: *** [build] Error 1

----------
components: Build
messages: 313219
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Building the html documentation is broken
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Mar  4 15:49:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Mar 2018 20:49:10 +0000
Subject: [issue32994] Building the html documentation is broken
In-Reply-To: <1520196447.07.0.467229070634.issue32994@psf.upfronthosting.co.za>
Message-ID: <1520196550.75.0.467229070634.issue32994@psf.upfronthosting.co.za>


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

You need to install that component.  The easiest way is:

cd Doc
make venv
make html

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar  4 16:03:53 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Mar 2018 21:03:53 +0000
Subject: [issue32994] Building the html documentation is broken
In-Reply-To: <1520196447.07.0.467229070634.issue32994@psf.upfronthosting.co.za>
Message-ID: <1520197433.61.0.467229070634.issue32994@psf.upfronthosting.co.za>


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

Thank you! All works now.

I tried `make clean` before, but not `make venv`.

----------

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

From report at bugs.python.org  Sun Mar  4 16:50:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Mar 2018 21:50:45 +0000
Subject: [issue32854] Add ** Map Unpacking Support for namedtuple
In-Reply-To: <1518718232.91.0.467229070634.issue32854@psf.upfronthosting.co.za>
Message-ID: <1520200245.7.0.467229070634.issue32854@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar  4 17:06:32 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 22:06:32 +0000
Subject: [issue30974] Update os.samefile docstring to match documentation
In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za>
Message-ID: <1520201192.89.0.467229070634.issue30974@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.8 -Python 3.6

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

From report at bugs.python.org  Sun Mar  4 17:26:01 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 22:26:01 +0000
Subject: [issue14266] pyunit script as shorthand for python -m unittest
In-Reply-To: <1331586037.12.0.876793471383.issue14266@psf.upfronthosting.co.za>
Message-ID: <1520202361.25.0.467229070634.issue14266@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Is there still interest in this?  Should it be converted to a PR for 3.8?

----------
nosy: +csabella

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

From report at bugs.python.org  Sun Mar  4 17:34:43 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Mar 2018 22:34:43 +0000
Subject: [issue14266] pyunit script as shorthand for python -m unittest
In-Reply-To: <1331586037.12.0.876793471383.issue14266@psf.upfronthosting.co.za>
Message-ID: <1520202883.36.0.467229070634.issue14266@psf.upfronthosting.co.za>


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

-0.5.  I have mixed feelings about this.  While I can see the utility of it, I think more recently we have been moving away from the concept of installed scripts for standard library features primarily because they are difficult to manage when there are multiple versions of Python installed and with virtual environments.  Speaking of which, how would this work in practice within venvs? And how would it work with the Windows launcher, py?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sun Mar  4 17:46:42 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 22:46:42 +0000
Subject: [issue30147] Change in re.escape output is not documented in whatsnew
In-Reply-To: <1492972796.84.0.355071171235.issue30147@psf.upfronthosting.co.za>
Message-ID: <1520203602.83.0.467229070634.issue30147@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5744
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Mar  4 17:58:31 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Mar 2018 22:58:31 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520204311.48.0.467229070634.issue32991@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Okay. I've wired up some unittests in test_doctest, and with [this patch](https://gist.github.com/jaraco/ea992719ac931fa761a6e9ef7a354542), it now captures the failed expectation of this ticket.

----------

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

From report at bugs.python.org  Sun Mar  4 18:06:33 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Mar 2018 23:06:33 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520204793.84.0.467229070634.issue32991@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

And [this patch](https://gist.github.com/7184fa32670f2c63333377ddeb710676) corrects the failure such that the test passes. It does so by restoring the expectation that inspect.getfile will once again raise a TypeError for these namespace packages (the yes/yes path in the decision tree). That's my recommendation going forward.

Feel free to review the work and apply the patches. As time permits, I may revisit the Developers Guide and learn the new process for submitting pull requests.

----------

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

From report at bugs.python.org  Sun Mar  4 18:06:59 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Mar 2018 23:06:59 +0000
Subject: [issue30147] Change in re.escape output is not documented in whatsnew
In-Reply-To: <1492972796.84.0.355071171235.issue30147@psf.upfronthosting.co.za>
Message-ID: <1520204819.74.0.467229070634.issue30147@psf.upfronthosting.co.za>


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


New changeset 18fd89246333bfa1b76c1623df689214f3ce2bf3 by Ned Deily (Cheryl Sabella) in branch 'master':
bpo-30147: Add re.escape changes to 3.7 What's New (GH-5978)
https://github.com/python/cpython/commit/18fd89246333bfa1b76c1623df689214f3ce2bf3


----------
nosy: +ned.deily

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

From report at bugs.python.org  Sun Mar  4 18:07:10 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 04 Mar 2018 23:07:10 +0000
Subject: [issue30147] Change in re.escape output is not documented in whatsnew
In-Reply-To: <1492972796.84.0.355071171235.issue30147@psf.upfronthosting.co.za>
Message-ID: <1520204830.38.0.467229070634.issue30147@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5745

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

From report at bugs.python.org  Sun Mar  4 18:22:35 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Mar 2018 23:22:35 +0000
Subject: [issue30147] Change in re.escape output is not documented in whatsnew
In-Reply-To: <1492972796.84.0.355071171235.issue30147@psf.upfronthosting.co.za>
Message-ID: <1520205755.06.0.467229070634.issue30147@psf.upfronthosting.co.za>


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


New changeset f92478d57a6b4014dcc0882d43b534fae1e7b929 by Ned Deily (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-30147: Add re.escape changes to 3.7 What's New (GH-5978) (GH-5979)
https://github.com/python/cpython/commit/f92478d57a6b4014dcc0882d43b534fae1e7b929


----------

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

From report at bugs.python.org  Sun Mar  4 18:24:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Mar 2018 23:24:40 +0000
Subject: [issue30147] Change in re.escape output is not documented in 3.7
 whatsnew
In-Reply-To: <1492972796.84.0.355071171235.issue30147@psf.upfronthosting.co.za>
Message-ID: <1520205880.25.0.467229070634.issue30147@psf.upfronthosting.co.za>


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

Thanks, @csabella, for the PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Change in re.escape output is not documented in whatsnew -> Change in re.escape output is not documented in 3.7 whatsnew
versions: +Python 3.8

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

From report at bugs.python.org  Sun Mar  4 18:43:38 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 04 Mar 2018 23:43:38 +0000
Subject: [issue25197] Allow documentation switcher to change url to /3/ and
 /dev/
In-Reply-To: <1442780092.62.0.798906880968.issue25197@psf.upfronthosting.co.za>
Message-ID: <1520207018.83.0.467229070634.issue25197@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

With the current dropdown for the documentation switcher (it has dev, prerelease, and stable options) and the addition of the language switcher, I believe this issue may be out of date.  Can it be closed?  Thanks!

----------
nosy: +csabella

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

From report at bugs.python.org  Sun Mar  4 18:43:55 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 04 Mar 2018 23:43:55 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1520207035.5.0.467229070634.issue32056@psf.upfronthosting.co.za>


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

> For any program which receive external file, to check the input file is necessary to do, isn't it?

Yes and no.  wave.py is doing checking and can raise various exceptions.  So a well-designed program has to be prepared to handle exceptions when calling wave.py.  The suggested fix would provide a more specific error message and exception, rather than a division by zero one, but the net effect to the caller of wave.py is the same.

> And program error lead to security bug, that's not right?

No. Just because a program can terminate due to an uncaught exception is not by itself considered a security error.  See https://www.python.org/news/security/ for a discussion. In particular, "The general rule is any attack worth reporting via the security address must allow an attacker to affect the confidentiality, integrity and availability of the Python application or its system for which the attacker does not already have the capability."  As things stand now, if an application is vulnerable to a denial-of-service attack due to a faulty wav file, it is a failure in that application to be handling possible exceptions from wave.py, not a security issue in Python itself.

----------

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

From report at bugs.python.org  Sun Mar  4 19:31:31 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 00:31:31 +0000
Subject: [issue32130] xml.sax parser validation sometimes fails when obtaining
 DTDs from https sites
In-Reply-To: <1511607953.88.0.213398074469.issue32130@psf.upfronthosting.co.za>
Message-ID: <1520209891.32.0.467229070634.issue32130@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Sun Mar  4 19:34:04 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 05 Mar 2018 00:34:04 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start and its bad
 editor call
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1520210044.35.0.467229070634.issue32989@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

> In the meanwhile, to get some idea of how well find_good_parse_start finds good parse starts, I restarted IDLE in a console with the print still added, loaded editor.py, and hit RETURN followed by UNDO, in various places. The first non-zero bod, 812, comes with the cursor at the end of 'def _sphinx_version():'  812 is probably the beginning of the line.  After "if __name__ == '__main__':" near the end, 1416.  After the final "run(_editor_window)", 1654.  The highest value I got in about 10 tries past the middle, 1931.  To me, this is pathetically bad.

Print `startat` too.  `num_context_lines` isn't CodeContext (although I thought it was too); that's just unfortunate naming.  `num_context_lines` is just a list = [50, 500, 5000]. First it looks at the code going back 50 lines from the current line and it only sends the text to `find_good_parse_start()` from this line onward.  `bod` is calculated from that point, not from the beginning of the file.  Because the start point is always 50 lines back, `bod` seems to always be in a similar range once you get to line 50 or higher in the code.

It seems that the purpose of the parsing is to apply the translate, etc to as few lines as possible.  So, it tries to make sure it includes the openers (':' ending lines) and closers (return, pass, etc) and the beginning of the brackets and continuation lines.  The big thing is that it wants to make sure it's not in a string or comment.  So, I think the program almost overcompensates for the idea of a 'large string'.  It is very complex and very hard to figure out exactly what it is trying to accomplish, even with the comments.  Maybe modern computing power (compared to 2000) has made it such that translating a whole source file is quick enough to not need fancy parsing.  :-)

----------

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

From report at bugs.python.org  Sun Mar  4 19:36:31 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 00:36:31 +0000
Subject: [issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64
 folders
In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za>
Message-ID: <1520210191.38.0.467229070634.issue15631@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Sun Mar  4 19:37:50 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 00:37:50 +0000
Subject: [issue31658] xml.sax.parse won't accept path objects
In-Reply-To: <1506891071.57.0.213398074469.issue31658@psf.upfronthosting.co.za>
Message-ID: <1520210270.5.0.467229070634.issue31658@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Sun Mar  4 19:50:26 2018
From: report at bugs.python.org (yao zhihua)
Date: Mon, 05 Mar 2018 00:50:26 +0000
Subject: [issue32993] issue30657 Incomplete fix
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520211026.57.0.467229070634.issue32993@psf.upfronthosting.co.za>


yao zhihua <hackyzh001 at gmail.com> added the comment:

Okay my falut.I made the wrong issue.The issue is issue11662.Urlopen function can use the file protocol, when an attacker input file:///etc/passwd, it can leak the contents of the passwd file.

----------

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

From report at bugs.python.org  Sun Mar  4 19:51:28 2018
From: report at bugs.python.org (yao zhihua)
Date: Mon, 05 Mar 2018 00:51:28 +0000
Subject: [issue32993] issue11662 Incomplete fix
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520211088.48.0.467229070634.issue32993@psf.upfronthosting.co.za>


Change by yao zhihua <hackyzh001 at gmail.com>:


----------
title: issue30657 Incomplete fix -> issue11662 Incomplete fix

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

From report at bugs.python.org  Sun Mar  4 19:46:11 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 00:46:11 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1520210771.53.0.467229070634.issue17239@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Sun Mar  4 19:46:04 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 00:46:04 +0000
Subject: [issue17318] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1362012637.97.0.538376803739.issue17318@psf.upfronthosting.co.za>
Message-ID: <1520210764.34.0.467229070634.issue17318@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Sun Mar  4 20:20:25 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Mar 2018 01:20:25 +0000
Subject: [issue32921] .pth files cannot contain folders with utf-8 names
In-Reply-To: <1519390998.11.0.467229070634.issue32921@psf.upfronthosting.co.za>
Message-ID: <1520212825.72.0.467229070634.issue32921@psf.upfronthosting.co.za>


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


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Sun Mar  4 20:49:37 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Mar 2018 01:49:37 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520214577.75.0.467229070634.issue32991@psf.upfronthosting.co.za>


Change by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sun Mar  4 22:35:21 2018
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 05 Mar 2018 03:35:21 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1520220921.23.0.467229070634.issue32973@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Re: Petr: we can't expect extension module authors to retroactively fix released modules. We can't even expect everyone to fix this for future releases; moving away from globals (which may not be specific to the Python extension module) may be a lot of effort. Just look at how much work it's taking to move CPython itself to stop using globals in so many places. And while it may be necessary for sub-interpreters (which is only the case for global state that's Python objects), many people just don't care about sub-interpreters.

Re: Stefan: the init function pointer isn't known until much later in the current process, and calculated from the module name. There is not currently a way to import a module with a different init function pointer. I don't think this warrants that much of a rewrite.

----------

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

From report at bugs.python.org  Sun Mar  4 23:04:35 2018
From: report at bugs.python.org (ajk225)
Date: Mon, 05 Mar 2018 04:04:35 +0000
Subject: [issue32871] Interrupt .communicate() on SIGTERM/INT
In-Reply-To: <1518990067.61.0.467229070634.issue32871@psf.upfronthosting.co.za>
Message-ID: <1520222675.37.0.467229070634.issue32871@psf.upfronthosting.co.za>


ajk225 <ajk225 at gmail.com> added the comment:

Is this still open?  If so, can I take this on as my first issue?

----------
nosy: +ajk225

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

From report at bugs.python.org  Mon Mar  5 00:26:58 2018
From: report at bugs.python.org (yao zhihua)
Date: Mon, 05 Mar 2018 05:26:58 +0000
Subject: [issue32993] issue11662 Incomplete fix
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520227618.16.0.467229070634.issue32993@psf.upfronthosting.co.za>


yao zhihua <hackyzh001 at gmail.com> added the comment:

I also found a function without filtering file protocol.

poc:

import webbrowser
webbrowser.open('file:///etc/passwd')

----------

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

From report at bugs.python.org  Mon Mar  5 00:32:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 05:32:49 +0000
Subject: [issue32871] Interrupt .communicate() on SIGTERM/INT
In-Reply-To: <1518990067.61.0.467229070634.issue32871@psf.upfronthosting.co.za>
Message-ID: <1520227969.0.0.467229070634.issue32871@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

@ajk225 It may be useful to look at #25942 before working on this.

----------
nosy: +izbyshev

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

From report at bugs.python.org  Mon Mar  5 01:05:13 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Mar 2018 06:05:13 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520229913.4.0.467229070634.issue32984@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +5747
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Mar  5 01:09:08 2018
From: report at bugs.python.org (yao zhihua)
Date: Mon, 05 Mar 2018 06:09:08 +0000
Subject: [issue32993] issue11662 Incomplete fix
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520230148.02.0.467229070634.issue32993@psf.upfronthosting.co.za>


yao zhihua <hackyzh001 at gmail.com> added the comment:

I tried again, webbrowser module can only open file:///etc/passwd.

----------

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

From report at bugs.python.org  Mon Mar  5 01:43:40 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Mar 2018 06:43:40 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520232220.9.0.467229070634.issue32984@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With the PR, IDLE behaves the same as Python on Windows.
   .../3x> python -m idlelib -r f:/python/a/tem2.py
(see original post for content of tem2.py)
prints __file__ instead of raising NameError, while
  >>> __file__ continues to raise NameError

Cheryl, I really expect the PR to work on linux, but can you manually test it anyway?  If you think the blurb needs rst markup and feel like adding some, go ahead.

----------
nosy: +csabella
stage: patch review -> needs patch

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

From report at bugs.python.org  Mon Mar  5 03:29:24 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Mar 2018 08:29:24 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1520238564.18.0.467229070634.issue32968@psf.upfronthosting.co.za>


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

Elias: please do go ahead and update your PR.

----------

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

From report at bugs.python.org  Mon Mar  5 03:55:45 2018
From: report at bugs.python.org (Anthony Flury)
Date: Mon, 05 Mar 2018 08:55:45 +0000
Subject: [issue28955] Not matched behavior of numeric comparison with the
 documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1520240145.09.0.467229070634.issue28955@psf.upfronthosting.co.za>


Change by Anthony Flury <anthony.flury at btinternet.com>:


----------
keywords: +patch
pull_requests: +5748
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Mar  5 04:29:41 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 05 Mar 2018 09:29:41 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520242181.95.0.467229070634.issue26707@psf.upfronthosting.co.za>


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

@bigfootjon: Cocoa keyed archives are not plist files.

----------

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

From report at bugs.python.org  Mon Mar  5 05:11:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 10:11:32 +0000
Subject: [issue32995] Add a glossary entry for context variables
Message-ID: <1520244692.22.0.467229070634.issue32995@psf.upfronthosting.co.za>


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

I think the term context variable is worth adding into the glossary.

----------
assignee: docs at python
components: Documentation
messages: 313241
nosy: docs at python, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Add a glossary entry for context variables
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  5 06:09:53 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 05 Mar 2018 11:09:53 +0000
Subject: [issue32305] Namespace packages have inconsistent __file__ and
 __spec__.origin
In-Reply-To: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za>
Message-ID: <1520248193.46.0.467229070634.issue32305@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Should this get an entry in the What's New?

----------
nosy: +nedbat

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

From report at bugs.python.org  Mon Mar  5 06:14:02 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 11:14:02 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520248442.26.0.467229070634.issue32917@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 06:56:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 11:56:46 +0000
Subject: [issue32996] Improve What's New in 3.7
Message-ID: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>


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

The following PR fixes and improves formatting in the "What's New in Python 3.7" document, adds links to issues and authors names.

This is just one step. Somebody need to review NEWS entries and adds corresponding What's New entries if they are worth this, and later edit the wording of the final document.

----------
assignee: docs at python
components: Documentation
messages: 313243
nosy: docs at python, ned.deily, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve What's New in 3.7
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  5 06:58:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 11:58:52 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520251132.06.0.467229070634.issue32996@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  5 07:02:15 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 12:02:15 +0000
Subject: [issue31528] Let ConfigParser parse systemd units
In-Reply-To: <1505896809.19.0.933904793139.issue31528@psf.upfronthosting.co.za>
Message-ID: <1520251335.34.0.467229070634.issue31528@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 07:02:23 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 12:02:23 +0000
Subject: [issue1410680] Add 'surgical editing' to ConfigParser
Message-ID: <1520251343.94.0.467229070634.issue1410680@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 07:03:06 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 12:03:06 +0000
Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib
 path as a single argument.
In-Reply-To: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za>
Message-ID: <1520251386.95.0.467229070634.issue29623@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 07:03:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 12:03:50 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520251430.26.0.467229070634.issue32917@psf.upfronthosting.co.za>


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

Adding two new parameters to control so tiny detail of the output looks excessive to me. What if just change the default behavior and never output a final blank line?

----------
nosy: +lukasz.langa, serhiy.storchaka

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

From report at bugs.python.org  Mon Mar  5 07:04:24 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 12:04:24 +0000
Subject: [issue30760] configparse module in python3 can not write '%' to
 config file
In-Reply-To: <1498470490.58.0.585332868378.issue30760@psf.upfronthosting.co.za>
Message-ID: <1520251464.67.0.467229070634.issue30760@psf.upfronthosting.co.za>


Matej Cepl <mcepl at cepl.eu> added the comment:

Lukasz, this bug could be closed, couldn't it?

----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 07:06:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 12:06:01 +0000
Subject: [issue28955] Not matched behavior of numeric comparison with the
 documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1520251561.23.0.467229070634.issue28955@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  5 07:08:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 12:08:13 +0000
Subject: [issue31528] Let ConfigParser parse systemd units
In-Reply-To: <1505896809.19.0.933904793139.issue31528@psf.upfronthosting.co.za>
Message-ID: <1520251693.38.0.467229070634.issue31528@psf.upfronthosting.co.za>


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


----------
nosy: +lukasz.langa
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Mon Mar  5 07:14:20 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 12:14:20 +0000
Subject: [issue1322] Deprecate platform.dist() and
 platform.linux_distribution() functions
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1520252060.19.0.467229070634.issue1322@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 07:25:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 12:25:19 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520252719.33.0.467229070634.issue26707@psf.upfronthosting.co.za>


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

But they use the plist format for serialization (as plists theirself use the XML format).

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSKeyedArchiver.swift

Direct support of keyed archives would be better to implement in third-party package. But we can provide the support for low-level operations.

For distinguishing UIDs from integers and for being able to create plist files containing UIDs we need a special purposed class plist.UID. It will be a simpler wrapper around int with few methods: __index__(), __repr__(), __reduce__().

----------

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

From report at bugs.python.org  Mon Mar  5 08:15:19 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 13:15:19 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520255719.05.0.467229070634.issue28788@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 08:26:30 2018
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 05 Mar 2018 13:26:30 +0000
Subject: [issue23159] argparse: Provide equivalent of
 optparse.OptionParser.{option_groups, option_list, get_option}
In-Reply-To: <1420355263.97.0.969710352141.issue23159@psf.upfronthosting.co.za>
Message-ID: <1520256390.12.0.467229070634.issue23159@psf.upfronthosting.co.za>


Matej Cepl <mcepl at cepl.eu> added the comment:

So, this bug report could be closed, right?

----------
nosy: +mcepl

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

From report at bugs.python.org  Mon Mar  5 08:59:54 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 05 Mar 2018 13:59:54 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520258394.97.0.467229070634.issue32984@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

The change works on Linux with the patch (and gave a NameError without the patch).  I left a note on the PR for a possible SyntaxError.

I didn't have authority to push the blurb markup change to your branch, so I copied it into a comment.  If you click edit on it, you should be able to cut and paste it as is into the blurb file.

----------

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

From report at bugs.python.org  Mon Mar  5 09:15:56 2018
From: report at bugs.python.org (bbayles)
Date: Mon, 05 Mar 2018 14:15:56 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520259356.84.0.467229070634.issue28788@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

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

From report at bugs.python.org  Mon Mar  5 09:16:43 2018
From: report at bugs.python.org (bbayles)
Date: Mon, 05 Mar 2018 14:16:43 +0000
Subject: [issue31528] Let ConfigParser parse systemd units
In-Reply-To: <1505896809.19.0.933904793139.issue31528@psf.upfronthosting.co.za>
Message-ID: <1520259403.31.0.467229070634.issue31528@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

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

From report at bugs.python.org  Mon Mar  5 10:12:47 2018
From: report at bugs.python.org (James Davis)
Date: Mon, 05 Mar 2018 15:12:47 +0000
Subject: [issue32997] Catastrophic backtracking in fpformat
Message-ID: <1520262767.1.0.467229070634.issue32997@psf.upfronthosting.co.za>


New submission from James Davis <davisjam at vt.edu>:

The decoder regex used to parse numbers in the fpformat module is vulnerable to catastrophic backtracking.

'^([-+]?)0*(\d*)((?:\.\d*)?)(([eE][-+]?\d+)?)$'

The substructure '0*(\d*)' is quadratic.
An attack string like '+000....0++' blows up.

There is a risk of DOS (REDOS) if a web app uses this module to format untrusted strings.

----------
components: Library (Lib)
messages: 313249
nosy: davisjam
priority: normal
severity: normal
status: open
title: Catastrophic backtracking in fpformat
type: security
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  5 10:31:08 2018
From: report at bugs.python.org (John Brearley)
Date: Mon, 05 Mar 2018 15:31:08 +0000
Subject: [issue31880] subprocess process interaction with IDLEX GUI causes
 pygnuplot silent failures
In-Reply-To: <1509038618.41.0.213398074469.issue31880@psf.upfronthosting.co.za>
Message-ID: <1520263868.25.0.467229070634.issue31880@psf.upfronthosting.co.za>


John Brearley <brearley at bell.net> added the comment:

I retested with Python 3.6.4 upgrades and the issue no longer occurs. You may want to close this issue.

----------

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

From report at bugs.python.org  Mon Mar  5 10:37:24 2018
From: report at bugs.python.org (James Davis)
Date: Mon, 05 Mar 2018 15:37:24 +0000
Subject: [issue32997] Catastrophic backtracking in fpformat
In-Reply-To: <1520262767.1.0.467229070634.issue32997@psf.upfronthosting.co.za>
Message-ID: <1520264244.72.0.467229070634.issue32997@psf.upfronthosting.co.za>


Change by James Davis <davisjam at vt.edu>:


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

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

From report at bugs.python.org  Mon Mar  5 10:40:37 2018
From: report at bugs.python.org (mike bayer)
Date: Mon, 05 Mar 2018 15:40:37 +0000
Subject: [issue32998] regular expression regression in python 3.7
Message-ID: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

demo:

import re

inner = 'VARCHAR(30) COLLATE "en_US"'

result = re.sub(
    r'((?: COLLATE.*)?)$',
    r'FOO\1',
    inner
)

print(inner)
print(result)


in all Python versions prior to 3.7:

    VARCHAR(30) COLLATE "en_US"
    VARCHAR(30)FOO COLLATE "en_US"

in Python 3.7.0b2:

    VARCHAR(30) COLLATE "en_US"
    VARCHAR(30)FOO COLLATE "en_US"FOO

platform: Fedora 27 
python build:
Python 3.7.0b2 (default, Mar  5 2018, 09:37:32) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux

----------
components: Library (Lib)
messages: 313251
nosy: zzzeek
priority: normal
severity: normal
status: open
title: regular expression regression in python 3.7
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Mar  5 10:42:05 2018
From: report at bugs.python.org (mike bayer)
Date: Mon, 05 Mar 2018 15:42:05 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520264525.24.0.467229070634.issue32998@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

correction, that's fedora 26, not 27

----------

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

From report at bugs.python.org  Mon Mar  5 10:43:02 2018
From: report at bugs.python.org (Francisco Facioni)
Date: Mon, 05 Mar 2018 15:43:02 +0000
Subject: [issue22102] Zipfile generates Zipfile error in zip with 0 total
 number of disk in Zip64 end of central directory locator
In-Reply-To: <1406670130.27.0.606950005482.issue22102@psf.upfronthosting.co.za>
Message-ID: <1520264582.74.0.467229070634.issue22102@psf.upfronthosting.co.za>


Change by Francisco Facioni <fran6co at gmail.com>:


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

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

From report at bugs.python.org  Mon Mar  5 10:55:52 2018
From: report at bugs.python.org (Jon Janzen)
Date: Mon, 05 Mar 2018 15:55:52 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520265352.39.0.467229070634.issue26707@psf.upfronthosting.co.za>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

@serhiy.storchaka: I've implemented a UID wrapper class

I've also updated the parser and writer classes to support the UID wrapper. The implementations for reading/writing XML UID tags match the implementations given by Apple's plutil distributed with macOS:

UID(x) becomes {'CF$UID': int(x)}

----------

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

From report at bugs.python.org  Mon Mar  5 11:02:48 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Mar 2018 16:02:48 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520265768.71.0.467229070634.issue32984@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 22c82be5df70c3d51e3f89b54fe1d4fb84728c1e by Terry Jan Reedy in branch 'master':
bpo-32984: IDLE - set __file__ for startup files (GH-5981)
https://github.com/python/cpython/commit/22c82be5df70c3d51e3f89b54fe1d4fb84728c1e


----------

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

From report at bugs.python.org  Mon Mar  5 11:02:58 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 16:02:58 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520265778.84.0.467229070634.issue32984@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5753
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Mar  5 11:03:55 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 16:03:55 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520265835.58.0.467229070634.issue32984@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5754

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

From report at bugs.python.org  Mon Mar  5 11:09:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 16:09:35 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520266175.33.0.467229070634.issue32998@psf.upfronthosting.co.za>


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

This is intentional change.

Prior to 3.7 re.sub() didn't replace empty matches adjacent to a previous non-empty match. In 3.7 it does. Together with other changes this made all four functions that search multiple matches of the pattern (re.findall(), re.finditer(), re.split() and re.sub()) consistent.

In your example the pattern matches not only from " COLLATE" to the end of input string, but an empty string at the end of input string. If you do not want matching an empty string, just remove the '?' qualifier.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  5 11:10:54 2018
From: report at bugs.python.org (mike bayer)
Date: Mon, 05 Mar 2018 16:10:54 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520266254.66.0.467229070634.issue32998@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

can you point me to the documentation?

----------

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

From report at bugs.python.org  Mon Mar  5 11:17:18 2018
From: report at bugs.python.org (mike bayer)
Date: Mon, 05 Mar 2018 16:17:18 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520266638.54.0.467229070634.issue32998@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

also, removing the "?" is not an option for me.   I need the brackets to be placed prior to the "COLLATE" subsection, but unconditionally even if the "COLLATE" section is not present.     Looking at the change the behavior seems wrong to me.   The regexp states, "match the end of the string, plus an optional "COLLATE" clause, into a capturing expression.  replace everything here, e.g. the capturing part as well as the dollar sign part, with a single instance of FOO plus the captured part".   It is entirely unintuitive to me how a second replacement would be occurring here.   I cannot prove it but I think this change is wrong.

I will try to rewrite the expression.

----------

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

From report at bugs.python.org  Mon Mar  5 11:17:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 16:17:39 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520266659.6.0.467229070634.issue32998@psf.upfronthosting.co.za>


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

Just see the re.sub() documentation for 3.7. There is also a note in the What's New document, in the "Changes in the Python API" section.

----------

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

From report at bugs.python.org  Mon Mar  5 11:19:41 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 16:19:41 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
Message-ID: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

Demo:

>>> from abc import ABC
>>> issubclass(1, ABC)
Segmentation fault (core dumped)

The stack trace is attached.

Before reimplementation of abc in C, the result was confusing too:

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)]
 on win32
>>> from abc import ABC
>>> issubclass(1, ABC)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "abc.py", line 230, in __subclasscheck__
  File "_weakrefset.py", line 84, in add
TypeError: cannot create weak reference to 'int' object

----------
components: Extension Modules
files: stack-trace.txt
messages: 313259
nosy: izbyshev, levkivskyi
priority: normal
severity: normal
status: open
title: issubclass(obj, abc.ABC) causes a segfault
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file47470/stack-trace.txt

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

From report at bugs.python.org  Mon Mar  5 11:23:36 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 05 Mar 2018 16:23:36 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520267016.98.0.467229070634.issue32969@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

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

From report at bugs.python.org  Mon Mar  5 11:26:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 16:26:30 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520267190.11.0.467229070634.issue32998@psf.upfronthosting.co.za>


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

In your case you can just pass 1 as the fourth parameter of re.sub().

----------

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

From report at bugs.python.org  Mon Mar  5 11:28:19 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 16:28:19 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520267299.4.0.467229070634.issue32999@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

In debug mode, the following assertion fails:

python: ./Modules/_abc.c:642: _abc__abc_subclasscheck_impl: Assertion `((((((PyObject*)(mro))->ob_type))->tp_flags & ((1UL << 26))) != 0)' failed.

----------

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

From report at bugs.python.org  Mon Mar  5 11:29:06 2018
From: report at bugs.python.org (mike bayer)
Date: Mon, 05 Mar 2018 16:29:06 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520267346.8.0.467229070634.issue32998@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

for now the quickest solution is to add "count=1" so that it only replaces once.

----------

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

From report at bugs.python.org  Mon Mar  5 11:30:03 2018
From: report at bugs.python.org (John Brearley)
Date: Mon, 05 Mar 2018 16:30:03 +0000
Subject: [issue33000] IDLEX GUI consumes all RAM for scrollback buffer,
 uses 161Bytes / character stored
Message-ID: <1520267403.32.0.467229070634.issue33000@psf.upfronthosting.co.za>


New submission from John Brearley <brearley at bell.net>:

While running a tensorflow script in the IDLEX GUI that runs for 8 million steps and produce 2 lines stdout per step, my PC used all 16GB RAM and crashed the python process, not to mention messed up other apps, like Firefox & Norton AntiVirus. While the RAM was recovered, Firefox started responding, but Norton Antivirus didn?t, so the PC had to be rebooted. 
 
The issue is easily reproduced with the short print loop that dumps 20K lines of stdout, at 171 characters / line on the IDLEX GUI window. When the script is run in the IDLEX GUI, the Windows Task Manager shows the python process start at 19MB RAM consumption, then grows to 569MB RAM consumption. If I run the script a second time in the same IDLEX GUI window, it grows to 1.1GB RAM consumption. 
 
So 20K lines off output at 171 characters / line (?i: nnnnn? prefix + 2 * 80 byte string + newline) = 3.4M total characters stored in the scrollback buffer. The delta memory consumed was 569MB ? 19MB = 550MB. The RAM consumed / character is 550MB / 3.4M = 161 bytes / character. This seems excessively inefficient.
 
I now understand how the tensorflow script would stop after 550K iterations and the 550K lines of stdout in the IDLEX GUI would consume all 16GB RAM on my PC.
 
BTW, when I run the same test script in the WinPython command prompt window, it only consumes 4MB RAM while it runs. However the scrollback buffer is limited to 10K lines, wrapped at the 80 character mark, so much less data saved.
 
I haven?t found any options in IDLEX GUI to limit the scrollback buffer size.
 
My request is to review the scrollback memory storage algorithms. If nothing can be done to improve them, then please add a circular buffer to limit the memory consumption.
 
# Print loop to test memory consumption in Python IDLEX GUI.
s1 = "0123456789"
s2 = s1+s1+s1+s1+s1+s1+s1+s1
for i in range(20000):
   print("i:", i, s2, s2)

I am using Python 3.6.4 on Windows 7 PC, Intel i7-4770S, 3.1GHz, 16GB RAM.

----------
assignee: terry.reedy
components: IDLE
messages: 313263
nosy: jbrearley, terry.reedy
priority: normal
severity: normal
status: open
title: IDLEX GUI consumes all RAM for scrollback buffer, uses 161Bytes / character stored
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Mon Mar  5 11:32:48 2018
From: report at bugs.python.org (mike bayer)
Date: Mon, 05 Mar 2018 16:32:48 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520267568.52.0.467229070634.issue32998@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

for those watching this would be the findall() case which is consistent between pythons:

import re

for reg in [
    'VARCHAR(30) COLLATE "en_US"',
    'VARCHAR(30)'
]:

    print(re.findall(r'(?: COLLATE.*)?$', reg))


output (all pythons):

[' COLLATE "en_US"', '']
['']

so yes there are two matches for one and only one for the other.

----------

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

From report at bugs.python.org  Mon Mar  5 11:41:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 16:41:42 +0000
Subject: [issue32997] Catastrophic backtracking in fpformat
In-Reply-To: <1520262767.1.0.467229070634.issue32997@psf.upfronthosting.co.za>
Message-ID: <1520268102.91.0.467229070634.issue32997@psf.upfronthosting.co.za>


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

Wouldn't be easier to remove '0*' from the pattern? 0s could be stripped later by .lstrip('0').

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

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

From report at bugs.python.org  Mon Mar  5 11:48:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Mar 2018 16:48:55 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520268535.64.0.467229070634.issue32999@psf.upfronthosting.co.za>


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

Is there any sense in accepting non-types as the first argument of issubclass()? I would add a check just in issubclass().

----------
nosy: +inada.naoki, serhiy.storchaka
versions: +Python 3.7

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

From report at bugs.python.org  Mon Mar  5 11:49:20 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 16:49:20 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520268560.72.0.467229070634.issue32984@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fd340bf9e308130736c76257ff9a697edbeb082d by Miss Islington (bot) in branch '3.7':
bpo-32984: IDLE - set __file__ for startup files (GH-5981)
https://github.com/python/cpython/commit/fd340bf9e308130736c76257ff9a697edbeb082d


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Mar  5 11:51:24 2018
From: report at bugs.python.org (James Davis)
Date: Mon, 05 Mar 2018 16:51:24 +0000
Subject: [issue32997] Catastrophic backtracking in fpformat
In-Reply-To: <1520262767.1.0.467229070634.issue32997@psf.upfronthosting.co.za>
Message-ID: <1520268684.16.0.467229070634.issue32997@psf.upfronthosting.co.za>


James Davis <davisjam at vt.edu> added the comment:

Equivalent, probably cleaner. Comment on the PR if you want a change.

----------

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

From report at bugs.python.org  Mon Mar  5 12:01:47 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 17:01:47 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520269307.47.0.467229070634.issue32999@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Is there any sense in accepting non-types as the first argument of issubclass()?

No, though it is not (clearly) documented. The docs mention TypeError, but only for the second argument if my reading is correct.

In practice, issubclass() raises a TypeError if the first argument is not a class object:

>>> issubclass(1, int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class

Though, as I mentioned above, behavior for ABCs was always weird.

----------
versions:  -Python 3.7

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

From report at bugs.python.org  Mon Mar  5 12:09:06 2018
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Mon, 05 Mar 2018 17:09:06 +0000
Subject: [issue32829] Lib/ be more pythonic
In-Reply-To: <1518437200.03.0.467229070634.issue32829@psf.upfronthosting.co.za>
Message-ID: <1520269746.27.0.467229070634.issue32829@psf.upfronthosting.co.za>


????? ???????? <dilyan.palauzov at aegee.org> added the comment:

The variables got_it in distutils/command/sdist and quote in email/_header_value_parser can be skipped making the code shorter and faster.

----------

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

From report at bugs.python.org  Mon Mar  5 12:18:35 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Mon, 05 Mar 2018 17:18:35 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1520270315.86.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Done.

----------

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

From report at bugs.python.org  Mon Mar  5 12:50:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Mar 2018 17:50:24 +0000
Subject: [issue33000] IDLEX GUI consumes all RAM for scrollback buffer,
 uses 161Bytes / character stored
In-Reply-To: <1520267403.32.0.467229070634.issue33000@psf.upfronthosting.co.za>
Message-ID: <1520272224.36.0.467229070634.issue33000@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLEX is an independently developed and distributed set of IDLE eXtensions.  We have nothing to do with it.

IDLE, as the name suggests and the doc spells out, is an Integrated  Development and Learning Environment.  It is not a production run environment.  For interactive development, one can close the shell window and reclaim its memory while keeping an editor window open.

16 million lines of screen output way outside of IDLE's intended use.  Why are you (mis)using it this way?

As you already discovered, an effectively infinite output stream can be sent to a console.  Command Prompt has a similar behavior.  If you want more saved, output to disk.

Or write your own gui for your simulations.  IDLE (and hence IDLEX) uses the tkinter wrapper of the tcl/tk GUI framework.  tcl/tk is also separately developed and distributed.  We just use it.  Its text widget does not come with any automatic size management.  But you could write your own insert wrapper that would delete a line for each line added after you deem the widget 'full'.

When I ran your sample with 64 bit 3.7.0b2 on Win10, the memory reported by Task Manager increased from 30 to 195 Mb or 165 MB net, much less than you report.  I once printed about 500,000 60 char lines.  I had either 12 or 24 GB memory at the time.

I am inclined to close this issue as 'third party' (IDLEX and tcl/tk) but I will let you respond first.

----------

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

From report at bugs.python.org  Mon Mar  5 12:53:23 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 17:53:23 +0000
Subject: [issue32921] .pth files cannot contain folders with utf-8 names
In-Reply-To: <1519390998.11.0.467229070634.issue32921@psf.upfronthosting.co.za>
Message-ID: <1520272403.19.0.467229070634.issue32921@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Yes, it'll have significant side effects. The default file encoding on Windows is your configured code page (1252, in your case), and there's no good way around that default. The easiest immediate fix is to re-encode that file yourself.

Perhaps what we could do instead is allow the first line of a .pth file to be a coding comment? Then site.py can reopen the file with the specified encoding.

(FWIW, when I added the ._pth file, I explicitly made it UTF-8. But it had no history at that time so it was safe to do so.)

----------

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

From report at bugs.python.org  Mon Mar  5 12:56:54 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Mar 2018 17:56:54 +0000
Subject: [issue32305] Namespace packages have inconsistent __file__ and
 __spec__.origin
In-Reply-To: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za>
Message-ID: <1520272614.71.0.467229070634.issue32305@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I guess it depends on whether you think this is a new feature or a bug fix.  Or, OTOH, since we had to revert for 3.6, maybe it makes sense either way since some code will be affected.

----------

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

From report at bugs.python.org  Mon Mar  5 13:04:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 18:04:42 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
Message-ID: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

On February 27th, 2018, the Python Security Response team was notified of a buffer overflow issue in the os.symlink() method on Windows. The issue affects all versions of Python between 3.2 and 3.6.4, including the 3.7 beta releases. It will be patched for the next releases of 3.4, 3.5, 3.6 and 3.7.

Scripts may be vulnerable if they use os.symlink() on Windows and an attacker is able to influence the location where links are created. As os.symlink requires administrative privileges on most versions of Windows, exploits using this vulnerability are likely to achieve escalation of privilege.

Besides applying the fix to CPython, scripts can also ensure that the length of each path argument is less than 260, and if the source is a relative path, that its combination with the destination is also shorter than 260 characters. That is:

    assert (len(src) < 260 and
            len(dest) < 260 and
            len(os.path.join(os.path.dirname(dest), src)) < 260)
    os.symlink(src, dest)

Scripts that explicitly pass the target_is_directory argument as True are not vulnerable. Also, scripts on Python 3.5 that use bytes for paths are not vulnerable, because of a combination of stack layout and added parameter validation.

I will be requesting a CVE for this once the patches are applied to maintenance branches, and then notifying the security-announce list. The patch has been reviewed by the PSRT and reporter, and while it prevents the buffer overflow, it does not raise any new errors or enable the use of long paths when creating symlinks.

Many thanks to Alexey Izbyshev for the report, and helping us work through developing the patch.

----------
assignee: steve.dower
components: Windows
keywords: security_issue
messages: 313275
nosy: izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
priority: critical
severity: normal
status: open
title: Buffer overflow vulnerability in os.symlink on Windows
type: security
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/issue33001>
_______________________________________

From report at bugs.python.org  Mon Mar  5 13:10:03 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 18:10:03 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520273403.25.0.467229070634.issue33001@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Mon Mar  5 13:15:55 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Mar 2018 18:15:55 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520273755.93.0.467229070634.issue32991@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Good catch Jason.  Your fix is exactly right.  I approved your PR, which is against master, so it should definitely be backported to 3.7.  No need to backport to 3.6; we reverted the change for that release.

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

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

From report at bugs.python.org  Mon Mar  5 13:16:17 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 18:16:17 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520273777.13.0.467229070634.issue33001@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +5757

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

From report at bugs.python.org  Mon Mar  5 13:17:10 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 18:17:10 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520273830.29.0.467229070634.issue33001@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +5758

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

From report at bugs.python.org  Mon Mar  5 13:24:32 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 18:24:32 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520274272.3.0.467229070634.issue33001@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +5759

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

From report at bugs.python.org  Mon Mar  5 13:33:39 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 05 Mar 2018 18:33:39 +0000
Subject: [issue32305] Namespace packages have inconsistent __file__ and
 __spec__.origin
In-Reply-To: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za>
Message-ID: <1520274819.59.0.467229070634.issue32305@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

As is usual for me, I am here because some coverage.py code broke due to this change.  A diff between b1 and b2 found me the code change (thanks for the comment, btw!), but a What's New doesn't seem out of place.

----------

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

From report at bugs.python.org  Mon Mar  5 13:48:15 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 18:48:15 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520275695.42.0.467229070634.issue32984@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5760

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

From report at bugs.python.org  Mon Mar  5 14:04:08 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Mar 2018 19:04:08 +0000
Subject: [issue32305] Namespace packages have inconsistent __file__ and
 __spec__.origin
In-Reply-To: <1520274819.59.0.467229070634.issue32305@psf.upfronthosting.co.za>
Message-ID: <37BE479B-86CB-4600-8394-A95D7CA12A0A@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 5, 2018, at 10:33, Ned Batchelder <report at bugs.python.org> wrote:

> As is usual for me, I am here because some coverage.py code broke due to this change.  A diff between b1 and b2 found me the code change (thanks for the comment, btw!), but a What's New doesn't seem out of place.

Sounds good; I?ll work up a PR

----------

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

From report at bugs.python.org  Mon Mar  5 14:06:10 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 19:06:10 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520276770.39.0.467229070634.issue33001@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

While judging by the source code it seems that bytes in 3.5 should be fine, I've got a crash with the latest binary from python.org:

Python 3.5.4 (v3.5.4:3f56838, Aug  8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)]
 on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.symlink(b'x\\' * 129, b'y\\' * 129)
(Windows pop-up here)

----------

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

From report at bugs.python.org  Mon Mar  5 14:23:11 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 19:23:11 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520277791.36.0.467229070634.issue32984@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6935a511670797a3aaebdf96aad3dcff66baa76e by Miss Islington (bot) in branch '3.6':
bpo-32984: IDLE - set __file__ for startup files (GH-5981)
https://github.com/python/cpython/commit/6935a511670797a3aaebdf96aad3dcff66baa76e


----------

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

From report at bugs.python.org  Mon Mar  5 14:23:42 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Mar 2018 19:23:42 +0000
Subject: [issue32305] Namespace packages have inconsistent __file__ and
 __spec__.origin
In-Reply-To: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za>
Message-ID: <1520277822.27.0.467229070634.issue32305@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
pull_requests: +5761

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

From report at bugs.python.org  Mon Mar  5 14:24:41 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 19:24:41 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520277881.39.0.467229070634.issue33001@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> As os.symlink requires administrative privileges on most versions of Windows

The current implementation requires SeCreateSymbolicLinkPrivilege on ALL versions of Windows because users must pass an additional flag to CreateSymbolicLink to enable non-privileged symlinks on recent Windows 10, which os.symlink() doesn't do (see #31512).

----------

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

From report at bugs.python.org  Mon Mar  5 14:43:59 2018
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 05 Mar 2018 19:43:59 +0000
Subject: [issue32998] regular expression regression in python 3.7
In-Reply-To: <1520264437.92.0.467229070634.issue32998@psf.upfronthosting.co.za>
Message-ID: <1520279039.93.0.467229070634.issue32998@psf.upfronthosting.co.za>


Change by Doug Hellmann <doug at doughellmann.com>:


----------
nosy: +doughellmann

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

From report at bugs.python.org  Mon Mar  5 14:46:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Mar 2018 19:46:08 +0000
Subject: [issue32984] IDLE: set and unset __file__ for startup files
In-Reply-To: <1520010819.42.0.467229070634.issue32984@psf.upfronthosting.co.za>
Message-ID: <1520279168.59.0.467229070634.issue32984@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

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

From report at bugs.python.org  Mon Mar  5 14:46:11 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 05 Mar 2018 19:46:11 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520279171.79.0.467229070634.issue33001@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

>> As os.symlink requires administrative privileges on most versions 
>> of Windows
>
> The current implementation requires SeCreateSymbolicLinkPrivilege on 
> ALL versions of Windows because users must pass an additional flag to 
> CreateSymbolicLink to enable non-privileged symlinks on recent Windows
> 10, which os.symlink() doesn't do (see #31512).

The change in Windows 10 to allow unprivileged creation of links will be supported implicitly in 3.7, but this change is more for convenience than necessity. SeCreateSymbolicLinkPrivilege can be granted to standard users and groups. On my own systems, I grant this privilege to the "Authenticated Users" (S-1-5-11) well-known group. This even allows administrators to create symbolic links without having to elevate.

----------
nosy: +eryksun

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

From report at bugs.python.org  Mon Mar  5 14:46:22 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Mar 2018 19:46:22 +0000
Subject: [issue25427] Remove the pyvenv script in Python 3.8
In-Reply-To: <1445033746.77.0.533143282748.issue25427@psf.upfronthosting.co.za>
Message-ID: <1520279182.04.0.467229070634.issue25427@psf.upfronthosting.co.za>


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


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Mar  5 14:48:21 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Mar 2018 19:48:21 +0000
Subject: [issue32993] urllib and webbrowser.open() can open w/ file: protocol
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520279301.55.0.467229070634.issue32993@psf.upfronthosting.co.za>


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


----------
keywords: +security_issue
title: issue11662 Incomplete fix -> urllib and webbrowser.open() can open w/ file: protocol

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

From report at bugs.python.org  Mon Mar  5 15:43:42 2018
From: report at bugs.python.org (Jay Yin)
Date: Mon, 05 Mar 2018 20:43:42 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1520282622.62.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

I'm unsure how to regenerate the files that interact with the code for sys.path as travisCI states
"
Generated files not up to date
 M Python/importlib_external.h
"
since my code changes some of how the importing is handled

----------

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

From report at bugs.python.org  Mon Mar  5 15:46:38 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 05 Mar 2018 20:46:38 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520282798.07.0.467229070634.issue32999@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I've also checked that ABC.register() doesn't allow non-classes (and PEP 3119 mentions that).

Looking at PyObject_IsSubclass in Objects/abstract.c, the only case in which its check_class() could be avoided is if there is a custom __subclasscheck__:

>>> class M(type):
...   def __subclasscheck__(cls, c):
...     return c == 1 or super().__subclasscheck__(c)
...
>>> class A(metaclass=M):
...   pass
...
>>> issubclass(1, A)
True

If there is no need to support such weird __subclasscheck__, check_class() could be called earlier.

Note, however, that check_class() treats anything having __bases__ as a class, so moving the check alone is not enough to avoid the crash in all cases.

----------

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

From report at bugs.python.org  Mon Mar  5 16:07:14 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 05 Mar 2018 21:07:14 +0000
Subject: [issue33002] Making a class formattable as hex/oct integer requires
 both __int__ and __index__ for no good reason
Message-ID: <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

In Python 2, making a user-defined class support formatting using the integer-specific type codes required that __int__ be defined and nothing else (that is, '%x' % Foo() only required Foo to provide a __int__ method). In Python 3, this was changed to perform the conversion via __index__ for the %o, %x and %X format types (to match how oct and hex behave), not __int__, but the pre-check for validity in unicodeobject.c's mainformatlong function is still based on PyNumber_Check, not PyIndex_Check, and PyNumber_Check is concerned solely with __int__ and __float__, not __index__.

This means that a class with __index__ but not __int__ can't be used with the %o/%x/%X format codes (even though hex(mytype) and oct(mytype) work just fine).

It seems to me that either:

1. PyNumber_Check should be a superset of PyIndex_Check (broader change, probably out of scope)

or

2. mainformatlong should restrict the scope of the PyNumber_Check test to only being used for the non-'o'/'x'/'X' tests (where it's needed to avoid coercing strings and the like to integer).

Change #2 should be safe, with no major side-effects; since PyLong and subclasses always passed the existing PyNumber_Check test anyway, and PyNumber_Index already performs PyIndex_Check, the only path that needs PyNumber_Check is the one that ends in calling PyNumber_Long.

----------
components: Interpreter Core
messages: 313285
nosy: josh.r
priority: normal
severity: normal
status: open
title: Making a class formattable as hex/oct integer requires both __int__ and __index__ for no good reason
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  5 16:13:32 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 05 Mar 2018 21:13:32 +0000
Subject: [issue33002] Making a class formattable as hex/oct integer requires
 both __int__ and __index__ for no good reason
In-Reply-To: <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>
Message-ID: <1520284412.06.0.467229070634.issue33002@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Note: Obviously, defining __index__ without defining __int__ is a little strange (it's *equivalent* to int, but can't be *coerced* to int?), so yet another fix would be addressing #20092 so it wouldn't be possible for a type to define __index__ without (implicitly) defining __int__.

----------

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

From report at bugs.python.org  Mon Mar  5 16:16:06 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 05 Mar 2018 21:16:06 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1520284566.32.0.467229070634.issue20092@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Pingback from #33002, which is caused by the fact that parts of the CPython code base that use PyNumber_Index for type conversion still pre-check for valid types with PyNumber_Check, meaning that a type with __index__ and not __int__ gets erroneously rejected by the pre-check.

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Mar  5 16:29:44 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 05 Mar 2018 21:29:44 +0000
Subject: [issue33002] Making a class formattable as hex/oct integer with
 printf-style formatting requires both __int__ and __index__ for no good
 reason
In-Reply-To: <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>
Message-ID: <1520285384.69.0.467229070634.issue33002@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

To be clear, this is a problem with old-style (printf-style) formatting, and applies to both bytes formatting and str formatting. So a class like:

    class Foo:
        def __index__(self):
            return 1

will fail with a TypeError should you do any of:

    '%o' % Foo()
    '%x' % Foo()
    '%X' % Foo()
    b'%o' % Foo()
    b'%x' % Foo()
    b'%X' % Foo()

even though hex(Foo()) and oct(Foo()) work without issue.

----------
title: Making a class formattable as hex/oct integer requires both __int__ and __index__ for no good reason -> Making a class formattable as hex/oct integer with printf-style formatting requires both __int__ and __index__ for no good reason

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

From report at bugs.python.org  Mon Mar  5 16:50:16 2018
From: report at bugs.python.org (Dawei Wang)
Date: Mon, 05 Mar 2018 21:50:16 +0000
Subject: [issue29417] Sort entries in foo.dist-info/RECORD
In-Reply-To: <1485998286.97.0.0656038336058.issue29417@psf.upfronthosting.co.za>
Message-ID: <1520286616.7.0.467229070634.issue29417@psf.upfronthosting.co.za>


Dawei Wang <daweiwang.gatekeeper at gmail.com> added the comment:

This is important since for aws lambda the package can change every time.

----------
nosy: +Dawei Wang

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

From report at bugs.python.org  Mon Mar  5 16:52:45 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Mar 2018 21:52:45 +0000
Subject: [issue29417] Sort entries in foo.dist-info/RECORD
In-Reply-To: <1485998286.97.0.0656038336058.issue29417@psf.upfronthosting.co.za>
Message-ID: <1520286765.15.0.467229070634.issue29417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello!  distutils does not write dist-info directories itself; wheel, setuptools and other build tools do that.  Look at https://github.com/pypa to find the bug trackers (I forget if wheel is there or on bitbucket)

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

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

From report at bugs.python.org  Mon Mar  5 17:26:17 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 22:26:17 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520288777.84.0.467229070634.issue33001@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6921e73e33edc3c61bc2d78ed558eaa22a89a564 by Steve Dower in branch 'master':
bpo-33001: Prevent buffer overrun in os.symlink (GH-5989)
https://github.com/python/cpython/commit/6921e73e33edc3c61bc2d78ed558eaa22a89a564


----------

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

From report at bugs.python.org  Mon Mar  5 17:26:30 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 22:26:30 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520288790.49.0.467229070634.issue33001@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset baa45079466eda1f5636a6d13f3a60c2c00fdcd3 by Steve Dower in branch '3.6':
[3.6] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (GH-5990)
https://github.com/python/cpython/commit/baa45079466eda1f5636a6d13f3a60c2c00fdcd3


----------

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

From report at bugs.python.org  Mon Mar  5 17:27:19 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 22:27:19 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520288839.42.0.467229070634.issue33001@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5762

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

From report at bugs.python.org  Mon Mar  5 17:30:23 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Mar 2018 22:30:23 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520289023.71.0.467229070634.issue33001@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Patches are merged, except for the ones that belong to @Larry.

Thanks again Alexey for the final round of feedback!

----------
nosy: +larry

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

From report at bugs.python.org  Mon Mar  5 17:36:31 2018
From: report at bugs.python.org (W. Trevor King)
Date: Mon, 05 Mar 2018 22:36:31 +0000
Subject: [issue33003] urllib: Document parse_http_list
Message-ID: <1520289391.9.0.467229070634.issue33003@psf.upfronthosting.co.za>


New submission from W. Trevor King <wking at tremily.us>:

Python has had a parse_http_list helper since urllib2 landed in 6d7e47b8ea (EXPERIMENTAL, 2000-01-20).  With Python3 it was moved into urllib.request, and the implementation hasn't changed since (at least as of 4c19b9573, 2018-03-05).  External projects depend on the currently undocumented function [1,2], so it would be nice to have some user-facing documentation for it.  If that sounds appealing, I'm happy to work up a pull request.

[1]: https://github.com/requests/requests/blob/v2.18.4/requests/compat.py#L42
[2]: https://github.com/requests/requests/blob/v2.18.4/requests/compat.py#L58

----------
assignee: docs at python
components: Documentation
messages: 313294
nosy: docs at python, labrat
priority: normal
severity: normal
status: open
title: urllib: Document parse_http_list
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/issue33003>
_______________________________________

From report at bugs.python.org  Mon Mar  5 17:40:09 2018
From: report at bugs.python.org (Jason Madden)
Date: Mon, 05 Mar 2018 22:40:09 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
Message-ID: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>


New submission from Jason Madden <jason at nextthought.com>:

At the request of Victor Stinner on twitter, I ran the gevent test suite with Python 3.7.0b2 with the new '-X dev' argument and discovered an interpreter crash. With a bit of work, it boiled down to a very simple command:

$ env -i .runtimes/snakepit/python3.7.0b2 -X dev -c 'import os; os.fork()'
*** Error in `.runtimes/snakepit/python3.7.0b2': munmap_chunk(): invalid pointer: 0x0000000001c43a80 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f5a971607e5]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x1a8)[0x7f5a9716d698]
.runtimes/snakepit/python3.7.0b2(_PyRuntimeState_Fini+0x30)[0x515d90]
.runtimes/snakepit/python3.7.0b2[0x51445f]
.runtimes/snakepit/python3.7.0b2[0x42ce40]
.runtimes/snakepit/python3.7.0b2(_Py_UnixMain+0x7b)[0x42eaab]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f5a97109830]
.runtimes/snakepit/python3.7.0b2(_start+0x29)[0x42a0d9]
======= Memory map: ========
00400000-00689000 r-xp 00000000 08:01 177409                             //.runtimes/versions/python3.7.0b2/bin/python3.7
00888000-00889000 r--p 00288000 08:01 177409                             //.runtimes/versions/python3.7.0b2/bin/python3.7
00889000-008f3000 rw-p 00289000 08:01 177409                             //.runtimes/versions/python3.7.0b2/bin/python3.7
008f3000-00914000 rw-p 00000000 00:00 0
01b84000-01c64000 rw-p 00000000 00:00 0                                  [heap]
7f5a96052000-7f5a96068000 r-xp 00000000 08:01 265946                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7f5a96068000-7f5a96267000 ---p 00016000 08:01 265946                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7f5a96267000-7f5a96268000 rw-p 00015000 08:01 265946                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7f5a96268000-7f5a96273000 r-xp 00000000 08:01 268943                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f5a96273000-7f5a96472000 ---p 0000b000 08:01 268943                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f5a96472000-7f5a96473000 r--p 0000a000 08:01 268943                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f5a96473000-7f5a96474000 rw-p 0000b000 08:01 268943                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f5a96474000-7f5a9647a000 rw-p 00000000 00:00 0
7f5a9647a000-7f5a96485000 r-xp 00000000 08:01 268947                     /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f5a96485000-7f5a96684000 ---p 0000b000 08:01 268947                     /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f5a96684000-7f5a96685000 r--p 0000a000 08:01 268947                     /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f5a96685000-7f5a96686000 rw-p 0000b000 08:01 268947                     /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f5a96686000-7f5a9669c000 r-xp 00000000 08:01 268927                     /lib/x86_64-linux-gnu/libnsl-2.23.so
7f5a9669c000-7f5a9689b000 ---p 00016000 08:01 268927                     /lib/x86_64-linux-gnu/libnsl-2.23.so
7f5a9689b000-7f5a9689c000 r--p 00015000 08:01 268927                     /lib/x86_64-linux-gnu/libnsl-2.23.so
7f5a9689c000-7f5a9689d000 rw-p 00016000 08:01 268927                     /lib/x86_64-linux-gnu/libnsl-2.23.so
7f5a9689d000-7f5a9689f000 rw-p 00000000 00:00 0
7f5a9689f000-7f5a968a7000 r-xp 00000000 08:01 268938                     /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f5a968a7000-7f5a96aa6000 ---p 00008000 08:01 268938                     /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f5a96aa6000-7f5a96aa7000 r--p 00007000 08:01 268938                     /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f5a96aa7000-7f5a96aa8000 rw-p 00008000 08:01 268938                     /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f5a96acc000-7f5a96b4c000 rw-p 00000000 00:00 0
7f5a96b4c000-7f5a96b4e000 r-xp 00000000 08:01 184551                     //.runtimes/versions/python3.7.0b2/lib/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so
7f5a96b4e000-7f5a96d4e000 ---p 00002000 08:01 184551                     //.runtimes/versions/python3.7.0b2/lib/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so
7f5a96d4e000-7f5a96d4f000 r--p 00002000 08:01 184551                     //.runtimes/versions/python3.7.0b2/lib/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so
7f5a96d4f000-7f5a96d51000 rw-p 00003000 08:01 184551                     //.runtimes/versions/python3.7.0b2/lib/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so
7f5a96d51000-7f5a96e11000 rw-p 00000000 00:00 0
7f5a96e11000-7f5a970e9000 r--p 00000000 08:01 133586                     /usr/lib/locale/locale-archive
7f5a970e9000-7f5a972a9000 r-xp 00000000 08:01 268930                     /lib/x86_64-linux-gnu/libc-2.23.so
7f5a972a9000-7f5a974a9000 ---p 001c0000 08:01 268930                     /lib/x86_64-linux-gnu/libc-2.23.so
7f5a974a9000-7f5a974ad000 r--p 001c0000 08:01 268930                     /lib/x86_64-linux-gnu/libc-2.23.so
7f5a974ad000-7f5a974af000 rw-p 001c4000 08:01 268930                     /lib/x86_64-linux-gnu/libc-2.23.so
7f5a974af000-7f5a974b3000 rw-p 00000000 00:00 0
7f5a974b3000-7f5a975bb000 r-xp 00000000 08:01 268926                     /lib/x86_64-linux-gnu/libm-2.23.so
7f5a975bb000-7f5a977ba000 ---p 00108000 08:01 268926                     /lib/x86_64-linux-gnu/libm-2.23.so
7f5a977ba000-7f5a977bb000 r--p 00107000 08:01 268926                     /lib/x86_64-linux-gnu/libm-2.23.so
7f5a977bb000-7f5a977bc000 rw-p 00108000 08:01 268926                     /lib/x86_64-linux-gnu/libm-2.23.so
7f5a977bc000-7f5a977be000 r-xp 00000000 08:01 268937                     /lib/x86_64-linux-gnu/libutil-2.23.so
7f5a977be000-7f5a979bd000 ---p 00002000 08:01 268937                     /lib/x86_64-linux-gnu/libutil-2.23.so
7f5a979bd000-7f5a979be000 r--p 00001000 08:01 268937                     /lib/x86_64-linux-gnu/libutil-2.23.so
7f5a979be000-7f5a979bf000 rw-p 00002000 08:01 268937                     /lib/x86_64-linux-gnu/libutil-2.23.so
7f5a979bf000-7f5a979c2000 r-xp 00000000 08:01 268932                     /lib/x86_64-linux-gnu/libdl-2.23.so
7f5a979c2000-7f5a97bc1000 ---p 00003000 08:01 268932                     /lib/x86_64-linux-gnu/libdl-2.23.so
7f5a97bc1000-7f5a97bc2000 r--p 00002000 08:01 268932                     /lib/x86_64-linux-gnu/libdl-2.23.so
7f5a97bc2000-7f5a97bc3000 rw-p 00003000 08:01 268932                     /lib/x86_64-linux-gnu/libdl-2.23.so
7f5a97bc3000-7f5a97bdb000 r-xp 00000000 08:01 268929                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7f5a97bdb000-7f5a97dda000 ---p 00018000 08:01 268929                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7f5a97dda000-7f5a97ddb000 r--p 00017000 08:01 268929                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7f5a97ddb000-7f5a97ddc000 rw-p 00018000 08:01 268929                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7f5a97ddc000-7f5a97de0000 rw-p 00000000 00:00 0
7f5a97de0000-7f5a97e06000 r-xp 00000000 08:01 268928                     /lib/x86_64-linux-gnu/ld-2.23.so
7f5a97e10000-7f5a97fb5000 rw-p 00000000 00:00 0
7f5a97fb5000-7f5a97fdc000 r--p 00000000 08:01 135047                     /usr/lib/locale/C.UTF-8/LC_CTYPE
7f5a97fdc000-7f5a97fe1000 rw-p 00000000 00:00 0
7f5a97ffd000-7f5a97ffe000 rw-p 00000000 00:00 0
7f5a97ffe000-7f5a98005000 r--s 00000000 08:01 529048                     /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7f5a98005000-7f5a98006000 r--p 00025000 08:01 268928                     /lib/x86_64-linux-gnu/ld-2.23.so
7f5a98006000-7f5a98007000 rw-p 00026000 08:01 268928                     /lib/x86_64-linux-gnu/ld-2.23.so
7f5a98007000-7f5a98008000 rw-p 00000000 00:00 0
7fff79aeb000-7fff79b0c000 rw-p 00000000 00:00 0                          [stack]
7fff79b1d000-7fff79b20000 r--p 00000000 00:00 0                          [vvar]
7fff79b20000-7fff79b22000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

The crash is reproducible on Ubuntu 16.04 with a pyenv-built 3.7.0b2 and on macOS 10.13 with the python.org build.

Individually setting PYTHONMALLOC=debug also triggers the crash:

$ PYTHONMALLOC=debug /usr/local/bin/python3.7 -c 'import os; os.fork()'
Python(16996,0x7fffb1879340) malloc: *** error for object 0x7f90e6d01ff0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

----------
components: Interpreter Core
messages: 313296
nosy: jmadden
priority: normal
severity: normal
status: open
title: 3.7.0b2 Interpreter crash in dev mode (or with PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
versions: Python 3.7

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

From report at bugs.python.org  Mon Mar  5 17:39:41 2018
From: report at bugs.python.org (Marco Rougeth)
Date: Mon, 05 Mar 2018 22:39:41 +0000
Subject: [issue33004] Shutil module functions could accept Path-like objects
Message-ID: <1520289581.12.0.467229070634.issue33004@psf.upfronthosting.co.za>


New submission from Marco Rougeth <marco at rougeth.com>:

This is issue is to suggest an enhancement to the shutil module, I believe it's quiet similar to the issue32642.

I was using shutil.copytree to copy some files around and I tried to pass Path-like objects as input but got the exception "TypeError: argument should be string, bytes or integer, not PosixPath".

e.g.
build_path = BASE_DIR / 'build'
static_path = BASE_DIR / 'static'
shutil.copytree(static_path, build_path)


As said in issue32642, it "wasn't obvious because Path objects appear as strings in normal debug output". I had a look at the shutil source code and it seems that it wouldn't be to hard to implement. I'd love to do it, if it makes sense.

----------
components: Library (Lib)
messages: 313295
nosy: rougeth
priority: normal
severity: normal
status: open
title: Shutil module functions could accept Path-like objects
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/issue33004>
_______________________________________

From report at bugs.python.org  Mon Mar  5 18:01:20 2018
From: report at bugs.python.org (Jason Madden)
Date: Mon, 05 Mar 2018 23:01:20 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520290880.88.0.467229070634.issue33005@psf.upfronthosting.co.za>


Jason Madden <jason at nextthought.com> added the comment:

I built a local version of master (6821e73) and was able to get some line numbers (they're off by one for some reason, it appears):

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff78972e3e __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff78ab1150 pthread_kill + 333
2   libsystem_c.dylib             	0x00007fff788cf312 abort + 127
3   libsystem_malloc.dylib        	0x00007fff789cc866 free + 521
4   python.exe                    	0x0000000100fba715 _PyRuntimeState_Fini + 37 (pystate.c:90)
5   python.exe                    	0x0000000100fb9d73 Py_FinalizeEx + 547 (pylifecycle.c:1231)
6   python.exe                    	0x0000000100fddd80 pymain_main + 5808 (main.c:2664)
7   python.exe                    	0x0000000100fdec82 _Py_UnixMain + 178 (main.c:2697)
8   libdyld.dylib                 	0x00007fff78823115 start + 1

----------

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

From report at bugs.python.org  Mon Mar  5 18:13:02 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 23:13:02 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520291582.84.0.467229070634.issue33001@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 96fdbacb7797a564249fd59ccf86ec153c4bb095 by Miss Islington (bot) in branch '3.7':
bpo-33001: Prevent buffer overrun in os.symlink (GH-5989)
https://github.com/python/cpython/commit/96fdbacb7797a564249fd59ccf86ec153c4bb095


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Mar  5 18:29:11 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Mar 2018 23:29:11 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520292551.05.0.467229070634.issue32991@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset b9650a04a81355c8a7dcd0464c28febfb4bfc0a9 by Jason R. Coombs in branch 'master':
bpo-32991: Restore expectation that inspect.getfile raises TypeError on namespace package (GH-5980)
https://github.com/python/cpython/commit/b9650a04a81355c8a7dcd0464c28febfb4bfc0a9


----------

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

From report at bugs.python.org  Mon Mar  5 18:29:19 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 05 Mar 2018 23:29:19 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520292559.07.0.467229070634.issue32991@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5763

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

From report at bugs.python.org  Mon Mar  5 18:41:36 2018
From: report at bugs.python.org (Vidar Fauske)
Date: Mon, 05 Mar 2018 23:41:36 +0000
Subject: [issue31226] shutil.rmtree fails when target has an internal
 directory junction (Windows)
In-Reply-To: <1502978298.87.0.60982184572.issue31226@psf.upfronthosting.co.za>
Message-ID: <1520293296.02.0.467229070634.issue31226@psf.upfronthosting.co.za>


Change by Vidar Fauske <vidartf at gmail.com>:


----------
keywords: +patch
pull_requests: +5764
stage: test needed -> patch review

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

From report at bugs.python.org  Mon Mar  5 19:07:00 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Mar 2018 00:07:00 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520294820.83.0.467229070634.issue28788@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  5 19:35:29 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 06 Mar 2018 00:35:29 +0000
Subject: [issue33004] Shutil module functions could accept Path-like objects
In-Reply-To: <1520289581.12.0.467229070634.issue33004@psf.upfronthosting.co.za>
Message-ID: <1520296529.83.0.467229070634.issue33004@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

I think this falls under the umbrella of #30235, which posits that Path-like objects should be supported by shutil (and includes notes on doc validation).

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Mar  5 19:42:52 2018
From: report at bugs.python.org (Pavel Shpilev)
Date: Tue, 06 Mar 2018 00:42:52 +0000
Subject: [issue32919] csv.reader() to support QUOTE_ALL
In-Reply-To: <1519361723.9.0.467229070634.issue32919@psf.upfronthosting.co.za>
Message-ID: <1520296972.86.0.467229070634.issue32919@psf.upfronthosting.co.za>


Pavel Shpilev <p.shpilev at gmail.com> added the comment:

I know that CSV specification says empty field and empty string are the same, however, I still believe there is practical use for unconventional processing of such fields.

In our specific case we parse CSVs produced by Amazon Athena (based on Presto) in which NULL and empty string values represented as above. Following CSV specs dogmatically, there's no way to distinguish between the two, but pragmatically you can tell them apart by simply looking at values.

Brief search shows we aren't the only ones facing the issue. After giving it some more thought, I'd agree that csv.QUOTE_ALL doesn't make much sense here, but may be an extra argument to csv.reader() will do the trick? Something like csv.reader(detect_none_values=False/True), with False being default, and emphasis in the documentation that True goes against CSV specification.

----------

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

From report at bugs.python.org  Mon Mar  5 20:36:31 2018
From: report at bugs.python.org (Pierre Thibault)
Date: Tue, 06 Mar 2018 01:36:31 +0000
Subject: [issue33006] docstring of filter function is incorrect
Message-ID: <1520300191.48.0.467229070634.issue33006@psf.upfronthosting.co.za>


New submission from Pierre Thibault <pierre.thibault1.dev at gmail.com>:

> help(filter)

Help on built-in function filter in module __builtin__:

filter(...)
    filter(function or None, sequence) -> list, tuple, or string

    Return those items of sequence for which function(item) is true.  If
    function is None, return the items that are true.  If sequence is a tuple
    or string, return the same type, else return a list.
(END)

The second argument can be an iterable. Suggestion: Replace the docstring with the definition found at https://docs.python.org/2/library/functions.html#filter.

----------
assignee: docs at python
components: Documentation
messages: 313302
nosy: Pierre Thibault, docs at python
priority: normal
severity: normal
status: open
title: docstring of filter function is incorrect
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  5 20:43:41 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 06 Mar 2018 01:43:41 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520300621.65.0.467229070634.issue32969@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
type: enhancement -> 
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Mar  5 20:53:11 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 06 Mar 2018 01:53:11 +0000
Subject: [issue25197] Allow documentation switcher to change url to /3/ and
 /dev/
In-Reply-To: <1442780092.62.0.798906880968.issue25197@psf.upfronthosting.co.za>
Message-ID: <1520301191.28.0.467229070634.issue25197@psf.upfronthosting.co.za>


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

Yeah I believe this issue is out of date. Thanks.

----------
nosy: +Mariatta
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  5 22:26:10 2018
From: report at bugs.python.org (Marco Rougeth)
Date: Tue, 06 Mar 2018 03:26:10 +0000
Subject: [issue33004] Shutil module functions could accept Path-like objects
In-Reply-To: <1520289581.12.0.467229070634.issue33004@psf.upfronthosting.co.za>
Message-ID: <1520306770.42.0.467229070634.issue33004@psf.upfronthosting.co.za>


Marco Rougeth <marco at rougeth.com> added the comment:

You're right @josh.r! Thank you!

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  5 22:30:22 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 06 Mar 2018 03:30:22 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520307022.25.0.467229070634.issue33005@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +eric.snow, vstinner, xiang.zhang

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

From report at bugs.python.org  Mon Mar  5 23:55:28 2018
From: report at bugs.python.org (Eric McDonald)
Date: Tue, 06 Mar 2018 04:55:28 +0000
Subject: [issue23159] argparse: Provide equivalent of
 optparse.OptionParser.{option_groups, option_list, get_option}
In-Reply-To: <1420355263.97.0.969710352141.issue23159@psf.upfronthosting.co.za>
Message-ID: <1520312128.43.0.467229070634.issue23159@psf.upfronthosting.co.za>


Eric McDonald <the.eric.mcdonald at gmail.com> added the comment:

Yes, this issue could be closed. I think the concept is still valid and perhaps worthy of future consideration as it is a means of unifying two different configuration processing mechanisms in the standard library without having developers reinvent that wheel every time.

I'll close it, though, if having a "stale" issue floating around is bothersome.

----------
resolution:  -> later
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  6 00:36:52 2018
From: report at bugs.python.org (Antony Lee)
Date: Tue, 06 Mar 2018 05:36:52 +0000
Subject: [issue33007] Objects referencing private-mangled names do not
 roundtrip properly under pickling.
Message-ID: <1520314612.17.0.467229070634.issue33007@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

Consider the following example:

    import pickle

    class T:
        def __init__(self):
            self.attr = self.__foo

        def __foo(self):
            pass

    print(pickle.loads(pickle.dumps(T())))

This fails on 3.6 with `AttributeError: 'T' object has no attribute '__foo'` (i.e. there's a lookup on the unmangled name).  As a comparison, replacing `__foo` with `_foo` results in working code.

----------
components: Library (Lib)
messages: 313306
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Objects referencing private-mangled names do not roundtrip properly under pickling.
versions: Python 3.7

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

From report at bugs.python.org  Tue Mar  6 00:59:05 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 06 Mar 2018 05:59:05 +0000
Subject: [issue32997] Catastrophic backtracking in fpformat
In-Reply-To: <1520262767.1.0.467229070634.issue32997@psf.upfronthosting.co.za>
Message-ID: <1520315945.05.0.467229070634.issue32997@psf.upfronthosting.co.za>


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


New changeset 55d5bfba9482d39080f7b9ec3e6257ecd23f264f by Benjamin Peterson (Jamie Davis) in branch '2.7':
[2.7] closes bpo-32997: Fix REDOS in fpformat (GH-5984)
https://github.com/python/cpython/commit/55d5bfba9482d39080f7b9ec3e6257ecd23f264f


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  6 01:51:56 2018
From: report at bugs.python.org (W. Trevor King)
Date: Tue, 06 Mar 2018 06:51:56 +0000
Subject: [issue33008] urllib.request.parse_http_list incorrectly strips
 backslashes
Message-ID: <1520319116.64.0.467229070634.issue33008@psf.upfronthosting.co.za>


New submission from W. Trevor King <wking at tremily.us>:

Python currently strips backslashes from inside quoted strings:

  $ echo 'a="b\"c",d=e' | python3 -c 'from sys import stdin; from urllib.request import parse_http_list; print(parse_http_list(stdin.read()))'
  ['a="b"c"', 'd=e']

It should be printing:

  ['a="b\"c"', 'd=e']

The bug is this continue [1], which should be removed.  This was not a problem with the original implementation [2].  It was introduced in [3] as a fix for #735248 with explicit tests asserting the broken behavior [3].  Stripping backslashes from the insides of quoted strings is not appropriate, because it breaks explicit unquoting with email.utils.unquote [4]:

  import email.utils
  import urllib.request
  list = r'"b\\"c"'
  entry = urllib.request.parse_http_list(list)[0]
  entry  # '"b\\"c"', should be '"b\\\\"c"'
  email.utils.unquote(entry)  # 'b"c', should be 'b\\"c'

I'm happy to file patches against the various branches if that would help, but as a one-line removal (plus adjusting the tests), it might be easier if a maintainer files the patches.

[1]: https://github.com/python/cpython/blob/v3.7.0b2/Lib/urllib/request.py#L1420
[2]: https://github.com/python/cpython/commit/6d7e47b8ea1b8cf82927dacc364689b8eeb8708b#diff-33f7983ed1a69d290366fe426880581cR777
[3]: https://github.com/python/cpython/commit/e1b13d20199f79ffd3407bbb14cc09b1b8fd70d2#diff-230a8abfedeaa9ae447490df08172b15R52
[4]: https://docs.python.org/3.5/library/email.util.html#email.utils.unquote

----------
components: Library (Lib)
messages: 313308
nosy: labrat
priority: normal
severity: normal
status: open
title: urllib.request.parse_http_list incorrectly strips backslashes
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/issue33008>
_______________________________________

From report at bugs.python.org  Tue Mar  6 01:55:39 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 06:55:39 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520319339.01.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
versions: +Python 3.7

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

From report at bugs.python.org  Tue Mar  6 02:33:47 2018
From: report at bugs.python.org (Antony Lee)
Date: Tue, 06 Mar 2018 07:33:47 +0000
Subject: [issue33009] inspect.signature crashes on unbound partialmethods
Message-ID: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

The following example crashes Python 3.6:

    from functools import partialmethod
    import inspect

    class T:
        g = partialmethod((lambda self, x: x), 1)

    print(T().g())  # Correctly returns 1.
    print(T.g(T()))  # Correctly returns 1.
    print(inspect.signature(T.g))  # Crashes.

with

      File "/usr/lib/python3.6/inspect.py", line 3036, in signature
        return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
      File "/usr/lib/python3.6/inspect.py", line 2786, in from_callable
        follow_wrapper_chains=follow_wrapped)
      File "/usr/lib/python3.6/inspect.py", line 2254, in _signature_from_callable
        assert first_wrapped_param is not sig_params[0]
    IndexError: tuple index out of range

----------
components: Library (Lib)
messages: 313309
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: inspect.signature crashes on unbound partialmethods
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar  6 03:05:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Mar 2018 08:05:04 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520323504.04.0.467229070634.issue33009@psf.upfronthosting.co.za>


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

This is not a crash, but an assertion failure.

The assertion was added in issue30149.

----------
nosy: +serhiy.storchaka, yselivanov
stage:  -> needs patch
title: inspect.signature crashes on unbound partialmethods -> Assertion failure in inspect.signature on unbound partialmethods
type:  -> behavior
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Mar  6 03:32:13 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Mar 2018 08:32:13 +0000
Subject: [issue33002] Making a class formattable as hex/oct integer with
 printf-style formatting requires both __int__ and __index__ for no good
 reason
In-Reply-To: <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>
Message-ID: <1520325133.96.0.467229070634.issue33002@psf.upfronthosting.co.za>


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

Agreed that this seems wrong.

----------
nosy: +eric.smith, mark.dickinson

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

From report at bugs.python.org  Tue Mar  6 04:34:53 2018
From: report at bugs.python.org (Will Thompson)
Date: Tue, 06 Mar 2018 09:34:53 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1520328893.06.0.467229070634.issue29708@psf.upfronthosting.co.za>


Will Thompson <thompson at endlessm.com> added the comment:

For what it's worth, in Endless OS we still saw slight variations between builds in the .pyc files, even with all the source files' mtimes set to the epoch (ie. equivalent to setting & supporting SOURCE_DATE_EPOCH, I believe). Looking at the contents of the file suggested it was just reordering of class fields; indeed, we only saw this on Python versions where hash randomization is enabled by default, and disabling hash randomization made the output reproducible.

----------
nosy: +Will Thompson

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

From report at bugs.python.org  Tue Mar  6 04:46:12 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Tue, 06 Mar 2018 09:46:12 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1520329572.69.0.467229070634.issue29708@psf.upfronthosting.co.za>


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

Yeah, I also see it with 3.6.4.
I wanted to try 3.7 to see if it's fixed by chance.

Otherwise I may have to start digging deep into compilation logic.

Looking here:
https://tests.reproducible-builds.org/lede/lede_ar71xx.html

More specifically here:
https://tests.reproducible-builds.org/lede/dbd/packages/mips_24kc/packages/python3-asyncio_3.6.4-5_mips_24kc.ipk.html
it looks like 2 byte-codes are inverted

build1: 00007f80:???0100??003e??0200??0000??72b6??0000??0072??b500????.?.?.?>.?.?.?.?r.?.?.?.?r.?.?
build2: 00007f80:???0100??003e??0200??0000??72b5??0000??0072??b600????.?.?.?>.?.?.?.?r.?.?.?.?r.?.?

72b6 and 72b5 like to swap positions sometimes.

----------

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

From report at bugs.python.org  Tue Mar  6 04:47:34 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 09:47:34 +0000
Subject: [issue33010] os.path.isdir() returns True for broken directory
 symlinks or junctions
Message-ID: <1520329654.61.0.467229070634.issue33010@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

os.path.isdir() violates its own documentation by returning True for broken directory symlinks or junctions, for which os.path.exists() returns False:

>>> os.mkdir('b')
>>> import _winapi
>>> _winapi.CreateJunction('b', 'a')
>>> os.rmdir('b')
>>> os.path.exists('a')
False
>>> os.path.isdir('a')
True

The underlying problem is that os.path.isdir() uses GetFileAttributes, which is documented not to follow symlinks.

Eryk, is there a cheaper way to check FILE_ATTRIBUTE_DIRECTORY on a path while following reparse points apart from CreateFile/GetFileInformationByHandleEx/CloseFile?

Also, does it make sense to use GetFileAttributes as a fast path and use something like above as a fallback only if FILE_ATTRIBUTE_REPARSE_POINT is set, or does GetFileAttributes do something equivalently expensive under the hood?

----------
components: Extension Modules, Windows
messages: 313314
nosy: eryksun, izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.isdir() returns True for broken directory symlinks or junctions
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Mar  6 05:19:00 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 06 Mar 2018 10:19:00 +0000
Subject: [issue32911] Doc strings no longer stored in body of AST
In-Reply-To: <1519302007.93.0.467229070634.issue32911@psf.upfronthosting.co.za>
Message-ID: <1520331540.94.0.467229070634.issue32911@psf.upfronthosting.co.za>


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

There are no enough +1 for merging GH-5927 yet on the ML discussion.
https://mail.python.org/pipermail/python-dev/2018-February/152311.html

@Mark.Shannon, would you comment your opinion to the ML thread?

For now, I don't want to break tools supporting Python 3.7 a1~b2 already.
Although I will select (2) if there is time machine...

----------

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

From report at bugs.python.org  Tue Mar  6 06:12:50 2018
From: report at bugs.python.org (Cong Monkey)
Date: Tue, 06 Mar 2018 11:12:50 +0000
Subject: [issue33011] Embedded 3.6.4 distribution does not add script parent
 as sys.path[0]
Message-ID: <1520334770.43.0.467229070634.issue33011@psf.upfronthosting.co.za>


New submission from Cong Monkey <congzhangzh at gmail.com>:

Embedded 3.6.0 distribution does not insert script parent in sys.path[0], but the normal python do it.

this make some failed, like when I try to do pip install future, it will failed as import src.future failed, which works for normal python.

The root source maybe when python36._pth exist, python rewrite the flag and mark as isolate mode automate, which will not update sys.path when pymain_init_sys_path.

I use a trick which is really bad as a work around(and even when site .main the sys.argv is not ready!), and hope upstream will fix the root source.

===============begin in my usercustomize.py:================
import sys

import pathlib



class DummyImportHook(object):

    def __init__(self, *args):

        self.is_script_path_to_sys_path_be_done = False

        pass


    def find_module(self, fullname, path=None):

        # print(f'{DummyImportHook.__name__} trigger {sys.argv if hasattr(sys, "argv") else ""} ')

        if not self.is_script_path_to_sys_path_be_done and hasattr(sys, 'argv'):

            if sys.argv[0] is not None:

                # print(f'{DummyImportHook.__name__}:argv is {sys.argv}')

                path_obj = pathlib.Path(sys.argv[0])

                # #if path_obj.exists():

                # print(f'{DummyImportHook.__name__}:I am try to add {str(path_obj.parent)} to sys.path')

                sys.path.insert(0, str(path_obj.parent))

                print(f'{DummyImportHook.__name__}:current sys.path is {sys.path}')

                pass

            self.is_script_path_to_sys_path_be_done = True

            pass

        return None

        pass



print(f'{DummyImportHook.__name__}:auto script path to sys.path hook load!')



#sys.meta_path = [DummyImportHook()]

sys.meta_path.insert(0,DummyImportHook())


===============end in my usercustomize.py:================
===============begin in my python36._pth========================
python36
.
# Uncomment to run site.main() automatically
import site
===============end in my python36._pth========================

BTW, where is Embedded distribution package script in python git repo?

----------
messages: 313316
nosy: Cong Monkey
priority: normal
severity: normal
status: open
title: Embedded 3.6.4 distribution does not add script parent as sys.path[0]
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar  6 06:13:40 2018
From: report at bugs.python.org (Cong Monkey)
Date: Tue, 06 Mar 2018 11:13:40 +0000
Subject: [issue33011] Embedded 3.6.4 distribution does not add script parent
 as sys.path[0]
In-Reply-To: <1520334770.43.0.467229070634.issue33011@psf.upfronthosting.co.za>
Message-ID: <1520334820.79.0.467229070634.issue33011@psf.upfronthosting.co.za>


Change by Cong Monkey <congzhangzh at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type:  -> behavior

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

From report at bugs.python.org  Tue Mar  6 06:18:13 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Tue, 06 Mar 2018 11:18:13 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
Message-ID: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>


New submission from Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com>:

gcc 8 has added a new warning heuristic to detect invalid function casts and a stock python build seems to hit that warning quite often.  The most common is the cast of a METH_NOARGS function (that uses just one argument) to a PyCFunction.  The fix is pretty simple but needs to be applied widely.  I'm slowly knocking them off in my spare time; WIP here, which has a few other types of warnings mixed in that I'll sift out during submission and also create separate bug reports for:

https://github.com/siddhesh/cpython/tree/func-cast

I'll clean up and post PR(s) once I am done but I figured I should file this report first since it is a pretty big change in terms of number of files touched and wanted to be sure that I'm making changes the way the community prefers.

----------
components: Build
messages: 313317
nosy: siddhesh
priority: normal
severity: normal
status: open
title: Invalid function cast warnings with gcc 8 for METH_NOARGS
type: compile error

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

From report at bugs.python.org  Tue Mar  6 06:18:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Mar 2018 11:18:42 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520335122.38.0.467229070634.issue33005@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Mar  6 06:25:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Mar 2018 11:25:18 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520335518.76.0.467229070634.issue33005@psf.upfronthosting.co.za>


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

This bug is likely a regression on my work on Py_Main(): see bpo-32030. I proposed a fix: see attached PR 6001.

----------

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

From report at bugs.python.org  Tue Mar  6 06:31:47 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 06 Mar 2018 11:31:47 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520335907.48.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  6 06:32:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Mar 2018 11:32:34 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1520335954.14.0.467229070634.issue33012@psf.upfronthosting.co.za>


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

Argument Clinic generates the following declaration for the second parameter of METH_NOARGS functions:

    PyObject *Py_UNUSED(ignored)

It would be nice to follow the same style.

If the first parameter is of type PyObject* too, the explicit cast to PyCFunction can be removed.

Skip the curses module. It will be converted to Argument Clinic.

----------
nosy: +serhiy.storchaka
versions: +Python 3.8

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

From report at bugs.python.org  Tue Mar  6 06:38:00 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 06 Mar 2018 11:38:00 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1520336280.39.0.467229070634.issue33012@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

We are getting hit by that quite often on Fedora, with the transition to gcc 8 and it creates unnecessary noise at our build logs. Thanks for working on that.

When you sent your PR I can test it within our build system and verify if it works.

----------
nosy: +cstratak

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

From report at bugs.python.org  Tue Mar  6 06:57:13 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 06 Mar 2018 11:57:13 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520337433.25.0.467229070634.issue32999@psf.upfronthosting.co.za>


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

Actually, the behaviour when __suclasscheck__ returns True for non-class objects may be used by some code. Even typing module did this, I tried to remove as much as possible of this, but I think there may be few such situations left.

Therefore, the patch by Inada-san (that makes C behaviour follow Python behaviour) looks reasonable to me.

----------

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

From report at bugs.python.org  Tue Mar  6 07:12:45 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 12:12:45 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520338365.95.0.467229070634.issue32999@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

OK, making a new implementation behave as the old one is fine with me too.

BTW, do TypeErrors related to weak references deserve any treatment? Isn't it a kind of coincidence that the error raised due to usage of WeakSet in issubclass(obj, ABC) is what we expect? (Sorry, I'm not familiar with WeakSets).

----------

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

From report at bugs.python.org  Tue Mar  6 07:35:41 2018
From: report at bugs.python.org (Matt Eaton)
Date: Tue, 06 Mar 2018 12:35:41 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1520339741.74.0.467229070634.issue32958@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Using Ubuntu 16.04 with the 3.6.0 tag I was also able to reproduce the same error reported:

import socket

h = "0123456789012345678901234567890123456789012345678901234567890123.example.com"
socket.gethostbyname(h)

Traceback (most recent call last):
  File "/home/agnosticdev/Documents/code/python/python-dev/cpython-3_6_0/Lib/encodings/idna.py", line 165, in encode
    raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "host_test.py", line 8, in <module>
    socket.gethostbyname(h)
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or too long)


It looks like the hostname being 64 characters long is the issue in that it cannot be encoded.  Thus falling into the UnicodeError being raised in idna.py:
            # ASCII name: fast path
            labels = result.split(b'.')
            for label in labels[:-1]:
                if not (0 < len(label) < 64):
                    raise UnicodeError("label empty or too long")
            if len(labels[-1]) >= 64:
                raise UnicodeError("label too long")
            return result, len(input)

I did some work on this to try and resolve this, but ultimately it was not worth committing so I wanted to report my findings.

----------
nosy: +agnosticdev

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

From report at bugs.python.org  Tue Mar  6 08:31:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Mar 2018 13:31:40 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520343100.29.0.467229070634.issue33005@psf.upfronthosting.co.za>


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


New changeset 5d92647102fac9e116b98ab8bbc632eeed501c34 by Victor Stinner in branch 'master':
bpo-33005: Fix _PyGILState_Reinit() (#6001)
https://github.com/python/cpython/commit/5d92647102fac9e116b98ab8bbc632eeed501c34


----------

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

From report at bugs.python.org  Tue Mar  6 08:32:10 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 06 Mar 2018 13:32:10 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520343130.46.0.467229070634.issue33005@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5768

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

From report at bugs.python.org  Tue Mar  6 08:52:29 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 06 Mar 2018 13:52:29 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520344349.38.0.467229070634.issue33005@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 31e2b76f7bbcb8278748565252767a8b7790ff27 by Miss Islington (bot) in branch '3.7':
bpo-33005: Fix _PyGILState_Reinit() (GH-6001)
https://github.com/python/cpython/commit/31e2b76f7bbcb8278748565252767a8b7790ff27


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Mar  6 09:30:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Mar 2018 14:30:30 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520346630.18.0.467229070634.issue33005@psf.upfronthosting.co.za>


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

Thanks Jason Madden for your bug report! I should now be fixed.

You might want to try the 3.7 or master branch until the next 3.7 release: PEP 537 ("3.7.0 beta 3: 2018-03-26").

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

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

From report at bugs.python.org  Tue Mar  6 09:47:00 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Mar 2018 14:47:00 +0000
Subject: [issue33008] urllib.request.parse_http_list incorrectly strips
 backslashes
In-Reply-To: <1520319116.64.0.467229070634.issue33008@psf.upfronthosting.co.za>
Message-ID: <1520347620.0.0.467229070634.issue33008@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +barry, orsenthil, r.david.murray

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

From report at bugs.python.org  Tue Mar  6 09:56:58 2018
From: report at bugs.python.org (John Brearley)
Date: Tue, 06 Mar 2018 14:56:58 +0000
Subject: [issue33000] IDLEX GUI consumes all RAM for scrollback buffer,
 uses 161Bytes / character stored
In-Reply-To: <1520267403.32.0.467229070634.issue33000@psf.upfronthosting.co.za>
Message-ID: <1520348218.3.0.467229070634.issue33000@psf.upfronthosting.co.za>


John Brearley <brearley at bell.net> added the comment:

Hi Terry: I am exploring the value of a language specific editor and runtime environment. Its definitely a large step up from Windows Notepad and Gnome Gedit. Perhaps some notes in the IDLEX documentation regarding the development versus production runtime usages would be in order?

Perhaps in your Win10 environment you get the memory back when you close the shell window. In Win7, you dont get the memory back until you close both windows.

----------

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

From report at bugs.python.org  Tue Mar  6 09:59:31 2018
From: report at bugs.python.org (Jason Madden)
Date: Tue, 06 Mar 2018 14:59:31 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520348371.95.0.467229070634.issue33005@psf.upfronthosting.co.za>


Jason Madden <jason at nextthought.com> added the comment:

Thank you! I can confirm that git commit 31e2b76f7bbcb8278748565252767a8b7790ff27 on the 3.7 branch fixes the issue for me.

----------

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

From report at bugs.python.org  Tue Mar  6 10:01:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Mar 2018 15:01:11 +0000
Subject: [issue33005] 3.7.0b2 Interpreter crash in dev mode (or with
 PYTHONMALLOC=debug) with 'python -X dev -c 'import os; os.fork()'
In-Reply-To: <1520289609.59.0.467229070634.issue33005@psf.upfronthosting.co.za>
Message-ID: <1520348471.31.0.467229070634.issue33005@psf.upfronthosting.co.za>


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

> Thank you! I can confirm that git commit 31e2b76f7bbcb8278748565252767a8b7790ff27 on the 3.7 branch fixes the issue for me.

Cool. You can now continue your gevent tests using -X dev ;-)

----------

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

From report at bugs.python.org  Tue Mar  6 10:08:53 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 06 Mar 2018 15:08:53 +0000
Subject: [issue33013] Underscore in str.format with x option
Message-ID: <1520348933.04.0.467229070634.issue33013@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

>From the doc (https://docs.python.org/3/library/string.html#format-specification-mini-language):

> The '_' option signals the use of an underscore for a thousands separator for floating point presentation types and for integer presentation type 'd'. For integer presentation types 'b', 'o', 'x', and 'X', underscores will be inserted every 4 digits. For other presentation types, specifying this option is an error.

>>> '{0:_}'.format(123456789)
'123_456_789'
>>> '{0:x}'.format(123456789)
'75bcd15'
>>> '{0:x_}'.format(123456789)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier

What am I doing wrong?  I read the doc as saying that using `type` of `x` would result in the `_` separator to be inserted every 4 characters, so I was expecting the output to be '75b_cd15'.

Thanks!

----------
messages: 313330
nosy: csabella
priority: normal
severity: normal
status: open
title: Underscore in str.format with x option
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Mar  6 10:13:59 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 06 Mar 2018 15:13:59 +0000
Subject: [issue20150] API change in string formatting with :s option should be
 documented in What's New.
In-Reply-To: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za>
Message-ID: <1520349239.06.0.467229070634.issue20150@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I believe this has been added to the 3.4 What's New already:

object.__format__() no longer accepts non-empty format strings, it now raises a TypeError instead. Using a non-empty string has been deprecated since Python 3.2. This change has been made to prevent a situation where previously working (but incorrect) code would start failing if an object gained a __format__ method, which means that your code may now raise a TypeError if you are using an 's' format code with objects that do not have a __format__ method that handles it. See bpo-7994 for background

Closing as resolved.

----------
nosy: +csabella
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  6 10:16:13 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Mar 2018 15:16:13 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520349373.8.0.467229070634.issue32991@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 5a0c3987abd6a71b4fadeb525477eb5f560e8514 by Jason R. Coombs (Miss Islington (bot)) in branch '3.7':
bpo-32991: Restore expectation that inspect.getfile raises TypeError on namespace package (GH-5980) (GH-5997)
https://github.com/python/cpython/commit/5a0c3987abd6a71b4fadeb525477eb5f560e8514


----------

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

From report at bugs.python.org  Tue Mar  6 10:28:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Mar 2018 15:28:25 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520350105.46.0.467229070634.issue32999@psf.upfronthosting.co.za>


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

Could you please show examples with __suclasscheck__ returning True for non-class objects?

----------

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

From report at bugs.python.org  Tue Mar  6 10:50:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Mar 2018 15:50:08 +0000
Subject: [issue33013] Underscore in str.format with x option
In-Reply-To: <1520348933.04.0.467229070634.issue33013@psf.upfronthosting.co.za>
Message-ID: <1520351408.83.0.467229070634.issue33013@psf.upfronthosting.co.za>


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

>>> format(123456789, '_x')
'75b_cd15'

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  6 10:50:40 2018
From: report at bugs.python.org (David Beazley)
Date: Tue, 06 Mar 2018 15:50:40 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
Message-ID: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

This is a minor nit, but the doc string for str.isidentifier() states:

    Use keyword.iskeyword() to test for reserved identifiers such as "def" and "class".

At first glance, I thought that it meant you'd do this (doesn't work):

    'def'.iskeyword()

As opposed to this:

    import keyword
    keyword.iskeyword('def')

Perhaps a clarification that "keyword" refers to the keyword module could be added.   Or better yet, just make 'iskeyword()` a string method ;-).

----------
assignee: docs at python
components: Documentation
messages: 313335
nosy: dabeaz, docs at python
priority: normal
severity: normal
status: open
title: Clarify doc string for str.isidentifier()
versions: Python 3.7

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

From report at bugs.python.org  Tue Mar  6 10:51:49 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 06 Mar 2018 15:51:49 +0000
Subject: [issue33013] Underscore in str.format with x option
In-Reply-To: <1520348933.04.0.467229070634.issue33013@psf.upfronthosting.co.za>
Message-ID: <1520351509.96.0.467229070634.issue33013@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

The format specifier (here, 'x') always goes last.

>>> '{0:_x}'.format(123456789)
'75b_cd15'

See https://docs.python.org/3/library/string.html#formatstrings for the details.

Serhiy is correct that it's often easier to use format() instead of ''.format() for testing things like this.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Mar  6 10:53:24 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Mar 2018 15:53:24 +0000
Subject: [issue32991] AttributeError in doctest.DocTestFinder.find
In-Reply-To: <1520138832.88.0.467229070634.issue32991@psf.upfronthosting.co.za>
Message-ID: <1520351604.74.0.467229070634.issue32991@psf.upfronthosting.co.za>


Change by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Tue Mar  6 10:53:30 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Mar 2018 15:53:30 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1520282622.62.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W47=xt2O9L1v1rYdrd-hfyEqpbJoA=1zaDrfoNePjOp_Q@mail.gmail.com>


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

'make regen-all' should do it (but so will just running 'make -s -j' like
any old build of CPython).

On Mon, Mar 5, 2018, 12:43 Jay Yin, <report at bugs.python.org> wrote:

>
> Jay Yin <jayyin11043 at gmail.com> added the comment:
>
> I'm unsure how to regenerate the files that interact with the code for
> sys.path as travisCI states
> "
> Generated files not up to date
>  M Python/importlib_external.h
> "
> since my code changes some of how the importing is handled
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32642>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Mar  6 11:06:23 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Tue, 06 Mar 2018 16:06:23 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520352383.98.0.467229070634.issue33014@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hey David,

I'm working on this issue. Will submit a PR in a while :)

----------
nosy: +CuriousLearner

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

From report at bugs.python.org  Tue Mar  6 11:06:39 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 06 Mar 2018 16:06:39 +0000
Subject: [issue33013] Underscore in str.format with x option
In-Reply-To: <1520348933.04.0.467229070634.issue33013@psf.upfronthosting.co.za>
Message-ID: <1520352399.03.0.467229070634.issue33013@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Thanks guys.

I really thought I tried '{0:_x}'.format(123456789), but I guess I hadn't.  Good to know that using format(123456879, '_x) is better.

----------

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

From report at bugs.python.org  Tue Mar  6 11:56:26 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 16:56:26 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520355386.97.0.467229070634.issue33009@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +5769
stage: needs patch -> patch review

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

From report at bugs.python.org  Tue Mar  6 11:56:56 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 16:56:56 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520355416.33.0.467229070634.issue33009@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Yeah, that assertion needs to be tweaked a little bit.  Created a PR.

----------

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

From report at bugs.python.org  Tue Mar  6 12:25:59 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Mar 2018 17:25:59 +0000
Subject: [issue33011] Embedded 3.6.4 distribution does not add script parent
 as sys.path[0]
In-Reply-To: <1520334770.43.0.467229070634.issue33011@psf.upfronthosting.co.za>
Message-ID: <1520357159.67.0.467229070634.issue33011@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

This is the intentional design of the embedded distribution. You need to update the ._pth file to include the directories that have files that are part of your app - it's not meant for running random scripts, that's the job of the normal distribution.

The build script files are in Tools/msi with the other installer files, primarily make_zip.py, though that also gets used for the Nuget packages.

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

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

From report at bugs.python.org  Tue Mar  6 12:32:50 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Mar 2018 17:32:50 +0000
Subject: [issue31349] Embedded initialization ignores Py_SetProgramName()
In-Reply-To: <1504615500.56.0.927947330769.issue31349@psf.upfronthosting.co.za>
Message-ID: <1520357570.79.0.467229070634.issue31349@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I just hit this myself (and embarrassingly, I recently touched this code everyone and forgot to fix this).

Hopefully I get a chance to get to it, but patches are certainly welcome and I'll happily aim to get them into 3.6 onwards.

----------
versions: +Python 3.6, Python 3.8

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

From report at bugs.python.org  Tue Mar  6 12:33:28 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Mar 2018 17:33:28 +0000
Subject: [issue31349] Embedded initialization ignores Py_SetProgramName()
In-Reply-To: <1504615500.56.0.927947330769.issue31349@psf.upfronthosting.co.za>
Message-ID: <1520357608.64.0.467229070634.issue31349@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

(That said, I didn't try again 3.7, so it may already be fixed there. But since we're still fixing problems with 3.6, we should do that one too.)

----------

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

From report at bugs.python.org  Tue Mar  6 12:38:47 2018
From: report at bugs.python.org (Petter S)
Date: Tue, 06 Mar 2018 17:38:47 +0000
Subject: [issue32992] unittest: Automatically run coroutines in a loop
In-Reply-To: <1520167156.98.0.467229070634.issue32992@psf.upfronthosting.co.za>
Message-ID: <1520357927.34.0.467229070634.issue32992@psf.upfronthosting.co.za>


Change by Petter S <petter.strandmark at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  6 12:58:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 17:58:25 +0000
Subject: [issue32992] unittest: Automatically run coroutines in a loop
In-Reply-To: <1520167156.98.0.467229070634.issue32992@psf.upfronthosting.co.za>
Message-ID: <1520359105.79.0.467229070634.issue32992@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think the right approach would be to add an new base TestCase class: AsyncioTestCase.

And you should use the `asyncio.run` function to run the coroutine.

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

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

From report at bugs.python.org  Tue Mar  6 12:59:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 17:59:48 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520359188.71.0.467229070634.issue33009@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 8a387219bdfb6ee34928d6168ac42ca559f11c9a by Yury Selivanov in branch 'master':
bpo-33009: Fix inspect.signature() for single-parameter partialmethods. (GH-6004)
https://github.com/python/cpython/commit/8a387219bdfb6ee34928d6168ac42ca559f11c9a


----------

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

From report at bugs.python.org  Tue Mar  6 12:59:56 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 06 Mar 2018 17:59:56 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520359196.01.0.467229070634.issue33009@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5771

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

From report at bugs.python.org  Tue Mar  6 13:00:54 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 06 Mar 2018 18:00:54 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520359254.62.0.467229070634.issue33009@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5772

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

From report at bugs.python.org  Tue Mar  6 13:03:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 18:03:41 +0000
Subject: [issue32992] unittest: Automatically run coroutines in a loop
In-Reply-To: <1520167156.98.0.467229070634.issue32992@psf.upfronthosting.co.za>
Message-ID: <1520359421.7.0.467229070634.issue32992@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This is a duplicate of issue 32972. Let's move the discussion there.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> unittest.TestCase coroutine support

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

From report at bugs.python.org  Tue Mar  6 13:05:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 18:05:57 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520359557.78.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think the right approach would be to add an new base TestCase class: AsyncioTestCase.  There other frameworks that have different event loop implementations, so we can't assume that an `async def` test should always be executed by asyncio.

And you should use the `asyncio.run` function to run the coroutine.

----------

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

From report at bugs.python.org  Tue Mar  6 13:09:36 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Mar 2018 18:09:36 +0000
Subject: [issue33000] IDLEX GUI consumes all RAM for scrollback buffer,
 uses 161Bytes / character stored
In-Reply-To: <1520267403.32.0.467229070634.issue33000@psf.upfronthosting.co.za>
Message-ID: <1520359776.76.0.467229070634.issue33000@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I did not close either window before looking at the Task Manager number.

Once your program is debugged, I cannot think of any advantage of running it through IDLE instead of directly with the Python interpreter.

Since you repeat 'IDLEX' I still do not know whether you are running IDLEX or IDLE itself.

----------

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

From report at bugs.python.org  Tue Mar  6 13:11:39 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Mar 2018 18:11:39 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520359899.93.0.467229070634.issue32972@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Instead of a separate base class, what about an overridable `coroutine_runner` attribute that defaults to `asyncio.run`?

----------
nosy: +zach.ware

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

From report at bugs.python.org  Tue Mar  6 13:12:52 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 18:12:52 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520359972.78.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Instead of a separate base class, what about an overridable `coroutine_runner` attribute that defaults to `asyncio.run`?

How is that better?

----------

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

From report at bugs.python.org  Tue Mar  6 13:18:41 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Mar 2018 18:18:41 +0000
Subject: [issue32388] Remove cross-version binary compatibility
In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za>
Message-ID: <1520360321.36.0.467229070634.issue32388@psf.upfronthosting.co.za>


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

Yes, let's retarget to 3.8.

----------
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Tue Mar  6 13:20:07 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Mar 2018 18:20:07 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520360407.83.0.467229070634.issue32972@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

How is a separate base class better? :)

Having a default coroutine runner on the standard TestCase means all you have to do to add async tests is tack an `async` onto the front of your method definition, and everything just works as it always has.  Making it a separate base class means you have to know about that base class, what it's called, and remember to derive your test class from it.  If you accidentally add `async` to the front of a test method in a TestCase-derived test class, you get mostly-silent success with an easily-ignored warning about a coroutine not being awaited.

----------

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

From report at bugs.python.org  Tue Mar  6 13:21:10 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 06 Mar 2018 18:21:10 +0000
Subject: [issue4173] PDF documentation: long verbatim lines are cut off at
 right hand side
In-Reply-To: <1224684717.3.0.110027961744.issue4173@psf.upfronthosting.co.za>
Message-ID: <1520360470.76.0.467229070634.issue4173@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I just tested the PDF on the current version of the docs and this is no longer an issue.  The original example given wraps correctly on the PDF output.

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

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

From report at bugs.python.org  Tue Mar  6 13:23:51 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 06 Mar 2018 18:23:51 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520360631.78.0.467229070634.issue33009@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 112f799666bac1bdbb320840d5fda3132255eb5e by Miss Islington (bot) in branch '3.7':
bpo-33009: Fix inspect.signature() for single-parameter partialmethods. (GH-6004)
https://github.com/python/cpython/commit/112f799666bac1bdbb320840d5fda3132255eb5e


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Mar  6 13:47:35 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 06 Mar 2018 18:47:35 +0000
Subject: [issue33010] os.path.isdir() returns True for broken directory
 symlinks or junctions
In-Reply-To: <1520329654.61.0.467229070634.issue33010@psf.upfronthosting.co.za>
Message-ID: <1520362055.69.0.467229070634.issue33010@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Yes, it makes sense to call GetFileAttributes as the fast path, and then fall back on a slow path (i.e. create, query, close) for a directory reparse point. With GetFileInformationByHandleEx, the equivalent query is FileBasicInfo, which is available starting with Vista, so this could be backported to 3.5 if necessary. 

However, to be more consistent with POSIX, we need to first query FileAttributeTagInfo on the reparse point to get the reparse tag. If it's IO_REPARSE_TAG_MOUNT_POINT (junction) and the target is a volume name (i.e. "Volume{GUID}"), then we should return true. This can also be checked via GetVolumePathName, after normalizing the path, like how os.path.ismount() works on Windows (ntpath.py). A mount point is always a directory, even if the volume isn't currently available. OTOH, sometimes junctions are used as links instead, which is being addressed more generally by Vidar Fauske in issue 31226. There's potentially overlap here with Vidar's proposed _Py_is_reparse_link function.

More info on GetFileAttributes, if you're curious:

GetFileAttributes and GetFileAttributesEx are relatively cheap I/O calls. They're implemented by translating to a native NT path and calling NtQueryAttributesFile and NtQueryFullAttributesFile, respectively. These two system calls are optimized for network access. They use an open packet that that's query-only without reparsing. The I/O Manager's parse routine can thus use a local (fake) File object, the file system's corresponding fast I/O routine, and skip the normal cruft of working with an I/O request (i.e. IRP_MJ_CREATE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_CLEANUP, and IRP_MJ_CLOSE). In the sample fastfat driver, these routines are respectively FatFastQueryBasicInfo [1] and FatFastQueryNetworkOpenInfo [2].

[1]: https://github.com/Microsoft/Windows-driver-samples/blob/aa6e0b36eb932099fa4eb950a6f5e289a23b6d6e/filesys/fastfat/fatdata.c#L933

[2]: https://github.com/Microsoft/Windows-driver-samples/blob/aa6e0b36eb932099fa4eb950a6f5e289a23b6d6e/filesys/fastfat/fatdata.c#L1272

----------

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

From report at bugs.python.org  Tue Mar  6 13:48:10 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 06 Mar 2018 18:48:10 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520362090.42.0.467229070634.issue33009@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 387a055261267f5fafd2c12eafef49759c94704f by Miss Islington (bot) in branch '3.6':
bpo-33009: Fix inspect.signature() for single-parameter partialmethods. (GH-6004)
https://github.com/python/cpython/commit/387a055261267f5fafd2c12eafef49759c94704f


----------

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

From report at bugs.python.org  Tue Mar  6 13:49:27 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 18:49:27 +0000
Subject: [issue33009] Assertion failure in inspect.signature on unbound
 partialmethods
In-Reply-To: <1520321627.34.0.467229070634.issue33009@psf.upfronthosting.co.za>
Message-ID: <1520362167.68.0.467229070634.issue33009@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/issue33009>
_______________________________________

From report at bugs.python.org  Tue Mar  6 13:56:13 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Tue, 06 Mar 2018 18:56:13 +0000
Subject: [issue33015] Fix function cast warning in thread_pthread.h
Message-ID: <1520362573.83.0.467229070634.issue33015@psf.upfronthosting.co.za>


New submission from Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com>:

The PyThread_start_new_thread function takes a void (*)(void *) as the function argument, which does not match with the pthread_create callback which has type void *(*)(void *).  I've got a fix for this that adds a wrapper function of the right type that subsequently calls the function passed to PyThread_start_new_thread.

PR coming up.

----------
components: Build
messages: 313357
nosy: siddhesh
priority: normal
severity: normal
status: open
title: Fix function cast warning in thread_pthread.h
type: compile error

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

From report at bugs.python.org  Tue Mar  6 13:57:40 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Tue, 06 Mar 2018 18:57:40 +0000
Subject: [issue33015] Fix function cast warning in thread_pthread.h
In-Reply-To: <1520362573.83.0.467229070634.issue33015@psf.upfronthosting.co.za>
Message-ID: <1520362660.87.0.467229070634.issue33015@psf.upfronthosting.co.za>


Change by Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  6 14:14:50 2018
From: report at bugs.python.org (Petter S)
Date: Tue, 06 Mar 2018 19:14:50 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520363690.79.0.467229070634.issue32972@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

It's good to see others with the same idea as me. I just wrote https://github.com/python/cpython/pull/6005/commits/4d7e1837f235687c875e985e97701609fc1ac458 .

In my opinion, there is no need for another test class. I completely agree with Zachary Ware that the current TestCase class is more or less broken (or at least easily misused) with respect to coroutines.

Fixing TestCase would not break existing code. The customization of event loop would not be hard to add.

----------
nosy: +Petter S

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

From report at bugs.python.org  Tue Mar  6 14:26:14 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 19:26:14 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520364374.87.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> How is a separate base class better? :)

It's very explicit that way.

Also, I personally subclassed TestCase in many of my projects specifically to add async support.  To do that you have to use a metaclass to scan class' namespace for 'async def' functions.

Currently, unittest.TestCase doesn't have a metaclass.  If you add one to it, it might break all packages that were subclassing TestCase with a metaclass.


> If you accidentally add `async` to the front of a test method in a TestCase-derived test class, you get mostly-silent success with an easily-ignored warning about a coroutine not being awaited.

Well, what if you use trio or curio?  You add an 'async' keyword and get a cryptic error that some framework internals just broke.

So I'm strong -1 on the coroutine_runner attribute idea.

----------

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

From report at bugs.python.org  Tue Mar  6 14:26:19 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 06 Mar 2018 19:26:19 +0000
Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib
 path as a single argument.
In-Reply-To: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za>
Message-ID: <1520364379.48.0.467229070634.issue29623@psf.upfronthosting.co.za>


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


----------
pull_requests:  -594

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

From report at bugs.python.org  Tue Mar  6 14:26:27 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 06 Mar 2018 19:26:27 +0000
Subject: [issue29623] configparser.ConfigParser.read() does not accept Pathlib
 path as a single argument.
In-Reply-To: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za>
Message-ID: <1520364387.42.0.467229070634.issue29623@psf.upfronthosting.co.za>


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


----------
pull_requests:  -966

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

From report at bugs.python.org  Tue Mar  6 14:34:20 2018
From: report at bugs.python.org (Petter S)
Date: Tue, 06 Mar 2018 19:34:20 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520364860.42.0.467229070634.issue32972@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

> Also, I personally subclassed TestCase in many of my projects specifically to add async support.  To do that you have to use a metaclass to scan class' namespace for 'async def' functions.

Doesn't that break when, for example, test methods are decorated with unittest.mock.patch?

----------

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

From report at bugs.python.org  Tue Mar  6 14:38:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Mar 2018 19:38:08 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520365088.66.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Doesn't that break when, for example, test methods are decorated with unittest.mock.patch?

No, it shouldn't break them if you wrap async methods carefully.

Here's a metaclass that I wrote recently doing just that: https://github.com/Azure/azure-functions-python-worker/blob/9ed3f8acd45a264927ce11af64f5b495f0404032/azure/worker/testutils.py#L44-L63

----------

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

From report at bugs.python.org  Tue Mar  6 14:57:08 2018
From: report at bugs.python.org (Marco Rougeth)
Date: Tue, 06 Mar 2018 19:57:08 +0000
Subject: [issue30235] Validate shutil supports path-like objects,
 update docs accordingly
In-Reply-To: <1493745159.76.0.694023923588.issue30235@psf.upfronthosting.co.za>
Message-ID: <1520366228.82.0.467229070634.issue30235@psf.upfronthosting.co.za>


Change by Marco Rougeth <marco at rougeth.com>:


----------
keywords: +patch
pull_requests: +5774
stage: test needed -> patch review

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

From report at bugs.python.org  Tue Mar  6 15:17:44 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 20:17:44 +0000
Subject: [issue33010] os.path.isdir() returns True for broken directory
 symlinks or junctions
In-Reply-To: <1520329654.61.0.467229070634.issue33010@psf.upfronthosting.co.za>
Message-ID: <1520367464.08.0.467229070634.issue33010@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you for the detailed response, Eryk!

> A mount point is always a directory, even if the volume isn't currently available.

Do I understand correctly that you propose to additionally change os.path.exists() to return True for mount points with unavailable volumes? ?urrently, os.path.exists() (i.e, the underlying os.stat()) attempts to traverse them, and this would be consistent with os.path.isdir() if the latter were changed to traverse directory reparse points too (both would return False for such mount points). Is your idea to change the behavior to match POSIX in a similar case when, for example, the remote NFS server is down but stat() still works on the local mount point? If so, is this a new idea compared to the first paragraph of [1] where you say that non-link reparse points should always be traversed?

[1] https://github.com/python/cpython/pull/5998#discussion_r172402233

----------

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

From report at bugs.python.org  Tue Mar  6 15:22:55 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 20:22:55 +0000
Subject: [issue33010] os.path.isdir() returns True for broken directory
 symlinks or junctions
In-Reply-To: <1520329654.61.0.467229070634.issue33010@psf.upfronthosting.co.za>
Message-ID: <1520367775.67.0.467229070634.issue33010@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Hmm, actually, my NFS example is probably bad. I've run an experiment, and stat() simply hangs in the case if the NFS server is down.

----------

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

From report at bugs.python.org  Tue Mar  6 15:53:57 2018
From: report at bugs.python.org (John Brearley)
Date: Tue, 06 Mar 2018 20:53:57 +0000
Subject: [issue33000] IDLEX GUI consumes all RAM for scrollback buffer,
 uses 161Bytes / character stored
In-Reply-To: <1520267403.32.0.467229070634.issue33000@psf.upfronthosting.co.za>
Message-ID: <1520369637.67.0.467229070634.issue33000@psf.upfronthosting.co.za>


John Brearley <brearley at bell.net> added the comment:

Hi Terry: The icon on my Win 7 desktop points to: "C:\WinPython\IDLEX (Python GUI).exe".

This was part of the 430MB installer file WinPython-64bit-3.6.4.0Qt5b4.exe from https://sourceforge.net/projects/winpython.

I attached a screen shot of IDLEX window & help about.

----------
Added file: https://bugs.python.org/file47471/Python_IDLEX.png

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

From report at bugs.python.org  Tue Mar  6 17:07:18 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 06 Mar 2018 22:07:18 +0000
Subject: [issue33010] os.path.isdir() returns True for broken directory
 symlinks or junctions
In-Reply-To: <1520329654.61.0.467229070634.issue33010@psf.upfronthosting.co.za>
Message-ID: <1520374038.06.0.467229070634.issue33010@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Thanks for the quick feedback and pushing back on this. We just have a broken mount point, unlike in Unix where it's a regular directory. so you're right to just query the basic info for all directory reparse points, without special-casing mount points.

However, I do think a valid mount point is a directory. I don't see why os.path.ismount() returns true for a non-existent mount point, drive letter, or share. Is this just to avoid network access delays with unavailable mapped drives and shares? Also, because of the hard-coded UNC check in ismount(), we aren't supporting mount points in directories on shares. I think this needs work.

----------

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

From report at bugs.python.org  Tue Mar  6 17:31:37 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 22:31:37 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
Message-ID: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The first call of GetFinalPathNameByHandleW requests the required buffer size for the NT path (VOLUME_NAME_NT), while the second call receives the DOS path (VOLUME_NAME_DOS) in the allocated buffer. Usually, NT paths are longer than DOS ones, for example:

 NT path: \Device\HarddiskVolume2\foo
DOS path: \\?\C:\foo

Or, for UNC paths:

 NT path: \Device\Mup\server\share\foo
DOS path: \\?\UNC\server\share\foo

However, it is not always the case. A volume can be mounted to an arbitrary path, and if a drive letter is not assigned to such a volume, 
GetFinalPathNameByHandle will use the mount point path instead of C: above. This way, a DOS path can be longer than an NT path. Since the result of the second call is not checked properly, this condition won't be detected, resulting in an out-of-bounds access and use of uninitialized memory later.

Moreover, the path returned by GetFinalPathNameByHandle may change between the first and the second call, for example, because an intermediate directory was renamed. If the path becomes longer than buf_size, the same issue will occur.

----------
components: Extension Modules, Windows
messages: 313366
nosy: izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: nt._getfinalpathname may use uninitialized memory
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Mar  6 17:42:54 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 06 Mar 2018 22:42:54 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520376174.48.0.467229070634.issue33016@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


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

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

From report at bugs.python.org  Tue Mar  6 18:20:46 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 06 Mar 2018 23:20:46 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520378446.62.0.467229070634.issue33016@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

The inconsistent use of VOLUME_NAME_NT and VOLUME_NAME_DOS was addressed incidentally in issue 29734, but that issue is primarily about the handle leaked when GetFinalPathNameByHandleW fails. That said, you've cleanly addressed the handle leak in your PR also. I prefer the common cleanup approach that you've used here, rather than spreading the cleanup tasks around in blocks, where it can easily be overlooked.

The PR for issue 29734 also fixes some handle leaks related to win32_xstat_impl. Those leaks still need to be addressed for 3.7, and backported to 3.6.

----------
nosy: +eryksun

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

From report at bugs.python.org  Tue Mar  6 19:06:16 2018
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 07 Mar 2018 00:06:16 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520381176.06.0.467229070634.issue22674@psf.upfronthosting.co.za>


Change by Chris Rebert <pybugs at chrisrebert.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Tue Mar  6 19:23:41 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 07 Mar 2018 00:23:41 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
 (CVE-2018-1000117)
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520382221.72.0.467229070634.issue33001@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

FYI, the CVE number for this issue is CVE-2018-1000117.

----------
title: Buffer overflow vulnerability in os.symlink on Windows -> Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

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

From report at bugs.python.org  Tue Mar  6 19:57:06 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Mar 2018 00:57:06 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520384226.32.0.467229070634.issue32999@psf.upfronthosting.co.za>


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

> BTW, do TypeErrors related to weak references deserve any treatment? Isn't it a kind of coincidence that the error raised due to usage of WeakSet in issubclass(obj, ABC) is what we expect? (Sorry, I'm not familiar with WeakSets).

Sorry, I can't get what is your point.
I don't want to change ABC behavior for now.  I want to make C implementation consistent with Python implementation, except some (unrealistic) corner cases.

----------

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

From report at bugs.python.org  Tue Mar  6 20:04:34 2018
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 07 Mar 2018 01:04:34 +0000
Subject: [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1520384674.44.0.467229070634.issue8840@psf.upfronthosting.co.za>


Change by A.M. Kuchling <amk at amk.ca>:


----------
keywords: +patch
pull_requests: +5776

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

From report at bugs.python.org  Tue Mar  6 22:17:23 2018
From: report at bugs.python.org (LCatro)
Date: Wed, 07 Mar 2018 03:17:23 +0000
Subject: [issue33017] Special set-cookie setting will bypass Cookielib
Message-ID: <1520392643.04.0.467229070634.issue33017@psf.upfronthosting.co.za>


New submission from LCatro <m4i1f0rt3st at sina.cn>:

PoC (PHP Version):

 header('Set-Cookie: test=123; max-age=a');  //  PoC 1
 header('Set-Cookie: test=123; domain=;');  //  PoC 2
 header('Set-Cookie: test=123; version=a;');  //  PoC 3

PoC 1 will trigger int() convert string to number from max-age (lib/cookielib.py:1429).I give this value a string ,it will make except 

        try:
            v = int(v)                 #  lib/cookielib.py:1429
        except ValueError:
            _debug("   missing or invalid (non-numeric) value for "
                  "max-age attribute")
            bad_cookie = True
            break                      #  lib/cookielib.py:1434

PoC 2 is a domain None value (lib/cookielib.py:1412).Cookielib will discard current cookie record.
    if k == "domain":                  #  lib/cookielib.py:1411
        if v is None:                  #  lib/cookielib.py:1412
            _debug("   missing value for domain attribute")
            bad_cookie = True
            break                      #  lib/cookielib.py:1415

PoC 3 will trigger a int() convert except(lib/cookielib.py:1472).Cookielib will discard current cookie record too.
        version = standard.get("version", None)  #  lib/cookielib.py:1469
        if version is not None:
            try:
                version = int(version)  #  lib/cookielib.py:1472
            except ValueError:
                return None  # invalid version, ignore cookie

There are PoCs involve urllib and requests library .

Full Code Analysis (Chinese Version): https://github.com/lcatro/Python_CookieLib_0day

----------
components: Library (Lib)
files: poc.php
messages: 313370
nosy: LCatro
priority: normal
severity: normal
status: open
title: Special set-cookie setting will bypass Cookielib
versions: Python 2.7
Added file: https://bugs.python.org/file47472/poc.php

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

From report at bugs.python.org  Wed Mar  7 00:05:39 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 07 Mar 2018 05:05:39 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520399139.67.0.467229070634.issue32969@psf.upfronthosting.co.za>


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


New changeset bc3f2289b9007396bfb7f986bee477b6176c1822 by Xiang Zhang in branch 'master':
bpo-32969: Expose some missing constants in zlib and fix the doc (GH-5988)
https://github.com/python/cpython/commit/bc3f2289b9007396bfb7f986bee477b6176c1822


----------

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

From report at bugs.python.org  Wed Mar  7 00:05:47 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 07 Mar 2018 05:05:47 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520399147.44.0.467229070634.issue32969@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5777

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

From report at bugs.python.org  Wed Mar  7 00:06:45 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 07 Mar 2018 05:06:45 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520399205.19.0.467229070634.issue32969@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5778

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

From report at bugs.python.org  Wed Mar  7 00:26:22 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 07 Mar 2018 05:26:22 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520400382.09.0.467229070634.issue32969@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c4d77a661138debbbe584b8b08410afc8719a9b1 by Miss Islington (bot) in branch '3.7':
bpo-32969: Expose some missing constants in zlib and fix the doc (GH-5988)
https://github.com/python/cpython/commit/c4d77a661138debbbe584b8b08410afc8719a9b1


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Mar  7 00:46:13 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 07 Mar 2018 05:46:13 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520401573.03.0.467229070634.issue32969@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7592c0a686a80b9fbe2e6d519a486aca58b3260b by Miss Islington (bot) in branch '3.6':
bpo-32969: Expose some missing constants in zlib and fix the doc (GH-5988)
https://github.com/python/cpython/commit/7592c0a686a80b9fbe2e6d519a486aca58b3260b


----------

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

From report at bugs.python.org  Wed Mar  7 00:55:49 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 07 Mar 2018 05:55:49 +0000
Subject: [issue32969] Add more constants to zlib module
In-Reply-To: <1519808340.69.0.467229070634.issue32969@psf.upfronthosting.co.za>
Message-ID: <1520402149.67.0.467229070634.issue32969@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/issue32969>
_______________________________________

From report at bugs.python.org  Wed Mar  7 02:27:06 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Mar 2018 07:27:06 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520407626.88.0.467229070634.issue32999@psf.upfronthosting.co.za>


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


New changeset fc7df0e664198cb05cafd972f190a18ca422989c by INADA Naoki in branch 'master':
bpo-32999: Fix ABC.__subclasscheck__ crash (GH-6002)
https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c


----------

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

From report at bugs.python.org  Wed Mar  7 02:28:11 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 07 Mar 2018 07:28:11 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520407691.89.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5779

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

From report at bugs.python.org  Wed Mar  7 02:43:09 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 07 Mar 2018 07:43:09 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520408589.63.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
pull_requests: +5780

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

From report at bugs.python.org  Wed Mar  7 02:47:42 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 07 Mar 2018 07:47:42 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520408862.26.0.467229070634.issue32999@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d824b4e4afbe9cf02310e39b14402fb2aa271f8f by Miss Islington (bot) in branch '3.7':
bpo-32999: Fix ABC.__subclasscheck__ crash (GH-6002)
https://github.com/python/cpython/commit/d824b4e4afbe9cf02310e39b14402fb2aa271f8f


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Mar  7 02:51:41 2018
From: report at bugs.python.org (devurandom)
Date: Wed, 07 Mar 2018 07:51:41 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1520409101.82.0.467229070634.issue30008@psf.upfronthosting.co.za>


Change by devurandom <devurandom at gmx.net>:


----------
nosy: +devurandom

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

From report at bugs.python.org  Wed Mar  7 02:52:32 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Mar 2018 07:52:32 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520409152.28.0.467229070634.issue32999@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/issue32999>
_______________________________________

From report at bugs.python.org  Wed Mar  7 02:53:10 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 07 Mar 2018 07:53:10 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520409190.27.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

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

From report at bugs.python.org  Wed Mar  7 02:59:07 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 07 Mar 2018 07:59:07 +0000
Subject: [issue33018] Improve issubclass() error checking and message
Message-ID: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>


New submission from Joshua Bronson <jabronson at gmail.com>:

Creating this issue by request of INADA Naoki to discuss my proposed patch in https://github.com/python/cpython/pull/5944.

Copy/pasting from that PR:

If you try something like issubclass('not a class', str), you get a helpful error message that immediately clues you in on what you did wrong:

>>> issubclass('not a class', str)
TypeError: issubclass() arg 1 must be a class
("AHA! I meant isinstance there. Thanks, friendly error message!")

But if you try this with some ABC, the error message is much less friendly!

>>> from some_library import SomeAbc
>>> issubclass('not a class', SomeAbc)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/abc.py", line 230, in __subclasscheck__
    cls._abc_negative_cache.add(subclass)
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_weakrefset.py", line 84, in add
    self.data.add(ref(item, self._remove))
TypeError: cannot create weak reference to 'str' object

("WTF just went wrong?" Several more minutes of head-scratching ensues. Maybe a less experienced Python programmer who hits this hasn't seen weakrefs before and gets overwhelmed, maybe needlessly proceeding down a deep rabbit hole before realizing no knowledge of weakrefs was required to understand what they did wrong.)

Or how about this example:

>>> from collections import Reversible
>>> issubclass([1, 2, 3], Reversible)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/abc.py", line 207, in __subclasscheck__
    ok = cls.__subclasshook__(subclass)
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_collections_abc.py", line 305, in __subclasshook__
    return _check_methods(C, "__reversed__", "__iter__")
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_collections_abc.py", line 73, in _check_methods
    mro = C.__mro__
AttributeError: 'list' object has no attribute '__mro__'
Here you don't even get the same type of error (AttributeError rather than TypeError), which seems unintentionally inconsistent.

This trivial patch fixes this, and will hopefully save untold numbers of future Python programmers some time and headache.

Let me know if any further changes are required, and thanks in advance for reviewing.

----------
messages: 313376
nosy: inada.naoki, izbyshev, jab, serhiy.storchaka
priority: normal
pull_requests: 5781
severity: normal
status: open
title: Improve issubclass() error checking and message
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  7 03:00:51 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Mar 2018 08:00:51 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520409651.78.0.467229070634.issue33014@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Wed Mar  7 03:06:13 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 07 Mar 2018 08:06:13 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520409973.97.0.467229070634.issue32999@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

@inada.naoki: I don't question your change. My point is the same as in #33018 (I've discovered that PR only after I commented). The error message is misleading, and it's just a coincidence that a TypeError and not some other error is raised when abc attempts to add a non-type object to a WeakSet.

@serhiy.storchaka: Note that an example that you requested is unlikely to be related to ABC and probably is more like my artificial __subclasscheck__ example. So, making changes just for ABC as suggested in #33018 might make sense.

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

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

From report at bugs.python.org  Wed Mar  7 03:07:11 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 07 Mar 2018 08:07:11 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520410031.84.0.467229070634.issue32999@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Sorry for status update, this was due to a concurrent modification.

----------
nosy: +jab
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Mar  7 03:59:15 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Mar 2018 08:59:15 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520413155.74.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

Why `issubclass()` doesn't check it?  Maybe, non-type class is supported by Python.  But I'm not sure.  I'm not meta programming expert.

But we use "duck typing".  In this case, if the object (a) supports weakref and (2) has __mro__ and it is tuple, we treat the object as a class.

And when raising TypeError, information about which assumption was broken may be useful.

So I'm -1 on adding such strong check or removing internal information without meta programming expert advice.

----------

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

From report at bugs.python.org  Wed Mar  7 04:09:52 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 07 Mar 2018 09:09:52 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520413792.42.0.467229070634.issue33018@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

ABC.register() has an explicit check, and it is mentioned in PEP 3119. The point here is not to change issubclass(), but to change ABC.__subclasscheck__(). It may conceivably have stricter requirements than issubclass() has. But certainly an advice from actual ABC users would be nice.

----------

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

From report at bugs.python.org  Wed Mar  7 04:27:41 2018
From: report at bugs.python.org (Anthony Flury)
Date: Wed, 07 Mar 2018 09:27:41 +0000
Subject: [issue33006] docstring of filter function is incorrect
In-Reply-To: <1520300191.48.0.467229070634.issue33006@psf.upfronthosting.co.za>
Message-ID: <1520414861.1.0.467229070634.issue33006@psf.upfronthosting.co.za>


Change by Anthony Flury <anthony.flury at btinternet.com>:


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

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

From report at bugs.python.org  Wed Mar  7 04:39:36 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 09:39:36 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520415576.45.0.467229070634.issue32986@psf.upfronthosting.co.za>


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

Matt, what do you think about this proposal? Is NCPUS the right thing to look at?

----------
nosy: +Matthew Rocklin
type:  -> behavior
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  7 05:12:19 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 07 Mar 2018 10:12:19 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520417539.78.0.467229070634.issue32986@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

This is a duplicate of bpo-26692 and bpo-23530, and possibly others.

My impression is that len(os.sched_getaffinity(os.getpid())) is the Right Guess. Currently sched_getaffinity isn't implemented on Windows, but bpo-23530 has some example code for how it could/should be implemented.

@M J Harvey: does this return the right thing for your batch jobs?

----------
nosy: +njs

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

From report at bugs.python.org  Wed Mar  7 05:13:49 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 10:13:49 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520417629.03.0.467229070634.issue32986@psf.upfronthosting.co.za>


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


----------
type: behavior -> enhancement
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Mar  7 06:08:00 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Mar 2018 11:08:00 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1520420880.93.0.467229070634.issue29708@psf.upfronthosting.co.za>


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

3e 02 00 00 00 is frozenset(size=2)
72 b6/b5 00 00 00 is reference to b5 or b6

So it seems set order changed. (or items in the set is appearance order is changed.)
Did you set PYTHONHASHSEED?

Anyway, I think Python 3.7 can't guarantee "reproducible" compile because marshal uses reference count.

----------

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

From report at bugs.python.org  Wed Mar  7 06:53:50 2018
From: report at bugs.python.org (Matthew Rocklin)
Date: Wed, 07 Mar 2018 11:53:50 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520423630.17.0.467229070634.issue32986@psf.upfronthosting.co.za>


Matthew Rocklin <mrocklin at gmail.com> added the comment:

I agree that this is a common issue.  We see it both when people use batch schedulers as well as when people use Docker containers.  I don't have enough experience with batch schedulers to verify that NCPUS is commonly set.  I would encourage people to also look at what Docker uses.  

After a quick (two minute) web search I couldn't find the answer, but I suspect that one exists.  I've raised a question on Stack Overflow here: https://stackoverflow.com/questions/49151296/how-many-cpus-does-my-docker-container-have

----------

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

From report at bugs.python.org  Wed Mar  7 07:24:57 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 12:24:57 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520425497.04.0.467229070634.issue32986@psf.upfronthosting.co.za>


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

I don't think we want to hardcode special cases for each resource-limiting framework out there: some people care about Docker, others about cgroups, CPU affinity settings, etc.  NCPUS has the nice property that each of those frameworks can set it, and users or sysadmins can also override it easily.  It's also trivially queried from Python.

----------

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

From report at bugs.python.org  Wed Mar  7 07:38:23 2018
From: report at bugs.python.org (Matt Harvey)
Date: Wed, 07 Mar 2018 12:38:23 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520426303.18.0.467229070634.issue32986@psf.upfronthosting.co.za>


Matt Harvey <m.j.harvey at acellera.com> added the comment:

Hi,

No, using the affinity's not useful to us as, in the general case, the batch system (PBS Pro in our case) isn't using cgroups or cpusets (it does control ave cpu use by monitoring rusage of the process group). 

Several other batch system I've worked with either set NCPUS directly or have a method for site-specific customisation of the job's environment.

That doesn't preclude using the affinity as an alternative to os.cpu_count()

As @pitrou correctly observes, probably better to have a simple, well-sign-posted way for the sysadmins to influence the pool default than try to overload multiprocessing with complex heuristics.

----------
nosy: +Matt Harvey

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

From report at bugs.python.org  Wed Mar  7 09:35:54 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 07 Mar 2018 14:35:54 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1520433354.35.0.467229070634.issue27683@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5783

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

From report at bugs.python.org  Wed Mar  7 10:17:49 2018
From: report at bugs.python.org (Jay Yin)
Date: Wed, 07 Mar 2018 15:17:49 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1520435869.83.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

I've been stuck on "test_poplib" for over 149661 sec now, that's about 41 hours... I don't think this is working correctly, although I'm unsure  what test_poplib is doing that has been affected by what I've changed here.

----------

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

From report at bugs.python.org  Wed Mar  7 13:29:44 2018
From: report at bugs.python.org (Antoine Pietri)
Date: Wed, 07 Mar 2018 18:29:44 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520447384.51.0.467229070634.issue22674@psf.upfronthosting.co.za>


Change by Antoine Pietri <antoine.pietri1 at gmail.com>:


----------
pull_requests: +5784
stage:  -> patch review

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

From report at bugs.python.org  Wed Mar  7 13:31:53 2018
From: report at bugs.python.org (Antoine Pietri)
Date: Wed, 07 Mar 2018 18:31:53 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520447513.14.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pietri <antoine.pietri1 at gmail.com> added the comment:

I updated Vajrasky's patch to rebase it onto master, use the clinic argument parser and improve the docs. I made a PR on GitHub so the review can be easier than a patch.

I left a Co-Authored-By field so I'm not stealing the ownership of this patch :-P

----------

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

From report at bugs.python.org  Wed Mar  7 13:41:15 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Wed, 07 Mar 2018 18:41:15 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1520448075.8.0.467229070634.issue29708@psf.upfronthosting.co.za>


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

PYTHONHASHSEED does help on 3.6.4
I'll use it during build.

Thanks for help

----------

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

From report at bugs.python.org  Wed Mar  7 13:55:08 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 18:55:08 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520448908.65.0.467229070634.issue32986@psf.upfronthosting.co.za>


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

Note that to avoid any kind of environment variable-driven Denial of Service, we should probably ignore NCPUS when sys.flags.ignore_environment is set.

----------

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

From report at bugs.python.org  Wed Mar  7 14:07:32 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 19:07:32 +0000
Subject: [issue33019] Review usage of environment variables in the stdlib
Message-ID: <1520449652.42.0.467229070634.issue33019@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Python supports a mode where the interpreter ignores environment variables such as PYTHONPATH, etc.

However, there are places in the stdlib where environment-sensitive decisions are made, without regard for the ignore-environment flag.

Examples include:
- ssl.get_default_verify_paths() queries SSL_CERT_FILE and SSL_CERT_DIR
- shutil.which() queries PATH
- the tempfile module queries TMPDIR, TEMP, TMP to select the defaut directory for temporary files

Do you think those need to be sanitized?

----------
components: Library (Lib)
messages: 313393
nosy: alex, christian.heimes, pitrou
priority: normal
severity: normal
status: open
title: Review usage of environment variables in the stdlib
type: security
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  7 14:16:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 07 Mar 2018 19:16:09 +0000
Subject: [issue33000] IDLE Doc: Text consumes unlimited RAM,
 consoles likely not
In-Reply-To: <1520267403.32.0.467229070634.issue33000@psf.upfronthosting.co.za>
Message-ID: <1520450169.62.0.467229070634.issue33000@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I don't know whether memory difference between us is due to IDLEX or Windows version or something else, but I don't really care.  The IDLE doc has a section "IDLE-console differences".  It should gain a paragraph explain the difference between memory-limited tk.Text-based Shell and limited-lines consoles.  For Command Prompt, the buffer defaults to a pathetic 300 lines, which is not enough for the CPython test suite output.  The max is 9999 for those who discover how to enlarge it.  No limit is an advantage for most uses, but not for one who fills up memory.

I will also think about a sentence to add to the introductory section about development versus production runs.

----------
components: +Documentation
stage:  -> needs patch
title: IDLEX GUI consumes all RAM for scrollback buffer, uses 161Bytes / character stored -> IDLE Doc: Text consumes unlimited RAM, consoles likely not
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  7 14:16:45 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 07 Mar 2018 19:16:45 +0000
Subject: [issue33019] Review usage of environment variables in the stdlib
In-Reply-To: <1520449652.42.0.467229070634.issue33019@psf.upfronthosting.co.za>
Message-ID: <1520450205.53.0.467229070634.issue33019@psf.upfronthosting.co.za>


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

External libraries like sqlite may also use env vars. I know for sure OpenSSL uses SSL_CERT_FILE and SSL_CERT_DIR to override default verify locations.

----------

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

From report at bugs.python.org  Wed Mar  7 14:22:21 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 07 Mar 2018 19:22:21 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1520450541.1.0.467229070634.issue32999@psf.upfronthosting.co.za>


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

Serhiy, for example `issubclass(typing.MutableMapping, typing.Mapping)` returns `True` while neither of those two are actual class objects. These relationships are kept mostly so that `typing.*` can be used as a drop-in replacement for `collections.abc.*` (plus backwards compatibility).

----------

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

From report at bugs.python.org  Wed Mar  7 15:03:22 2018
From: report at bugs.python.org (Ben Kirshenbaum)
Date: Wed, 07 Mar 2018 20:03:22 +0000
Subject: [issue33020] Tkinter old style classes
Message-ID: <1520453002.72.0.467229070634.issue33020@psf.upfronthosting.co.za>


New submission from Ben Kirshenbaum <benkir07 at gmail.com>:

Tkinter objects cannot handle the super() function, and probably other functions (I only found a problem with super())

----------
components: Tkinter
messages: 313397
nosy: benkir07
priority: normal
severity: normal
status: open
title: Tkinter old style classes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  7 15:44:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Mar 2018 20:44:23 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
 (CVE-2018-1000117)
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520455463.73.0.467229070634.issue33001@psf.upfronthosting.co.za>


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

FYI I added this vulnerability to:
http://python-security.readthedocs.io/vuln/cve-2018-1000117_buffer_overflow_vulnerability_in_os.symlink_on_windows.html
https://github.com/vstinner/python-security/commit/349588e8265099341801b20aa18f87a42176f7df

----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Mar  7 16:55:41 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Mar 2018 21:55:41 +0000
Subject: [issue33020] Tkinter old style classes
In-Reply-To: <1520453002.72.0.467229070634.issue33020@psf.upfronthosting.co.za>
Message-ID: <1520459741.64.0.467229070634.issue33020@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gpolo, serhiy.storchaka

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

From report at bugs.python.org  Wed Mar  7 17:09:30 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 22:09:30 +0000
Subject: [issue33019] Review usage of environment variables in the stdlib
In-Reply-To: <1520449652.42.0.467229070634.issue33019@psf.upfronthosting.co.za>
Message-ID: <1520460570.91.0.467229070634.issue33019@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Mar  7 17:11:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Mar 2018 22:11:26 +0000
Subject: [issue33020] Tkinter old style classes
In-Reply-To: <1520453002.72.0.467229070634.issue33020@psf.upfronthosting.co.za>
Message-ID: <1520460686.14.0.467229070634.issue33020@psf.upfronthosting.co.za>


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

It is not surprising that some classes in Python 2 are old style classes. This is not a bug. If you need new style classes, the solution is upgrading to Python 3.

----------

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

From report at bugs.python.org  Wed Mar  7 17:26:03 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 07 Mar 2018 22:26:03 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520461563.65.0.467229070634.issue32972@psf.upfronthosting.co.za>


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

I'm with Yuri: subclassing is under better control.
The need for a new subclass is relative rare, for the whole asyncio world AsyncioTestCase should be enough.
Another async framework most likely require a different test tool with another game rules.

----------

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

From report at bugs.python.org  Wed Mar  7 17:26:16 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 07 Mar 2018 22:26:16 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520461576.42.0.467229070634.issue32986@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

That stackoverflow thread points to the GNU coreutils 'nproc', which is an interesting compendium of knowledge about this problem.

It looks like their algorithm is roughly:

1. Determine how many CPUs *could* this program access, by going down a list of possible options and using the first that works: pthread_getaffinity_np -> sched_getaffinity -> GetProcessAffinityMask -> sysconf(_SC_NUMPROCESSORS_ONLN) -> some arcane stuff specific to HP-UX, IRIX, etc.

2. Parse the OMP_NUM_THREADS and OMP_THREAD_LIMIT envvars (this is not quite trivial, there's some handling of whitespace and commas and references to the OMP spec)

3. If OMP_NUM_THREADS is set, return min(OMP_NUM_THREADS, OMP_THREAD_LIMIT). Otherwise, return min(available_processors, OMP_THREAD_LIMIT).

Step (1) handles both the old affinity APIs, and also the cpuset system that docker uses. (From cpuset(7): "Cpusets are integrated with the sched_setaffinity(2) scheduling  affinity  mechanism".) Step (2) relies on the quasi-standard OMP_* envvars to let you choose something explicitly.

The PBS Pro docs say that they set both NPROCS and OMP_NUM_THREADS. See section 6.1.7 of https://pbsworks.com/pdfs/PBSUserGuide14.2.pdf

So this seems like a reasonable heuristic approach to me.

----------

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

From report at bugs.python.org  Wed Mar  7 17:35:03 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 22:35:03 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520462103.41.0.467229070634.issue32986@psf.upfronthosting.co.za>


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

> So this seems like a reasonable heuristic approach to me.

You mean duplicating "nproc"'s logic in Python?  If someone wants to do the grunt work of implementing/testing it...

There's also the question of how that affects non-scientific workloads. People can use thread pools or process pools for other purposes, such as distributing (blocking) I/O.

----------

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

From report at bugs.python.org  Wed Mar  7 17:35:30 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 07 Mar 2018 22:35:30 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520462130.21.0.467229070634.issue32986@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

I can't find any evidence that NPROCS is used by other batch schedulers (I looked at SLURM, Torque, and SGE). @M J Harvey, do you have any other examples of systems that use it?

----------

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

From report at bugs.python.org  Wed Mar  7 17:40:11 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Mar 2018 22:40:11 +0000
Subject: [issue33019] Review usage of environment variables in the stdlib
In-Reply-To: <1520449652.42.0.467229070634.issue33019@psf.upfronthosting.co.za>
Message-ID: <1520462411.13.0.467229070634.issue33019@psf.upfronthosting.co.za>


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

I don't think -E is a security feature. Even if the stdlib was fixed, there's tons of 3rdparty Python code that consumes os.environ.

It seems like if you really cared about not letting the environment influence a Python application, you'd just wrap python in a script that cleans out the environment before execing.

----------

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

From report at bugs.python.org  Wed Mar  7 17:41:28 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Mar 2018 22:41:28 +0000
Subject: [issue33019] Review usage of environment variables in the stdlib
In-Reply-To: <1520449652.42.0.467229070634.issue33019@psf.upfronthosting.co.za>
Message-ID: <1520462488.77.0.467229070634.issue33019@psf.upfronthosting.co.za>


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

I may be mistaken, what's the use of -E if not for security?

----------

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

From report at bugs.python.org  Wed Mar  7 17:45:37 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 07 Mar 2018 22:45:37 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520462737.55.0.467229070634.issue32986@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> You mean duplicating "nproc"'s logic in Python?

Yeah.

> If someone wants to do the grunt work of implementing/testing it...

Well, that's true of any bug fix / improvement :-). The logic isn't terribly complicated though, something roughly like:

def parse_omp_envvar(env_value):
    return int(env_value.strip().split(",")[0])

def estimate_cpus():
    limit = float("inf")
    if "OMP_THREAD_LIMIT" in os.environ:
        limit = parse_omp_envvar(os.environ["OMP_THREAD_LIMIT"])

    if "OMP_NUM_THREADS" in os.environ:
        cpus = parse_omp_envvar(os.environ["OMP_NUM_THREADS"])
    else:
        try:
            cpus = len(os.sched_getaffinity(os.getpid()))
        except AttributeError, OSError:
            cpus = os.cpu_count()

    return min(cpus, limit)

> There's also the question of how that affects non-scientific workloads. People can use thread pools or process pools for other purposes, such as distributing (blocking) I/O.

We already have some heuristics for this: IIRC the thread pool executor defaults to cpu_count() * 5 threads (b/c Python threads are really intended for I/O-bound workloads), and the process pool executor and multiprocessing.Pool defaults to cpu_count() processes (b/c processes are better suited to CPU-bound workloads). Neither of these heuristics is perfect. But inasmuch as it makes sense at all to use the cpu count as part of the heuristic, it surely will work better to use a more accurate estimate of the available cpus.

----------

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

From report at bugs.python.org  Wed Mar  7 18:03:24 2018
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 07 Mar 2018 23:03:24 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
Message-ID: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>


New submission from Nir Soffer <nirsof at gmail.com>:

If the file descriptor is on a non-responsive NFS server, calling
fstat() can block for long time, hanging all threads. Most of the fstat()
calls release the GIL around the call, but some calls seems to be
forgotten.

In python 3, the calls are handled now by _py_fstat(), releasing the GIL
internally, but some calls use _py_fstat_noraise() which does not release
the GIL. Most of the calls to _py_fstat_noraise() release the GIL around
the call, except these 2 calls, affecting users of:

- mmap.mmap()
- os.urandom()
- random.seed()

In python there are more fstat() calls to fix, affecting users of:

- imp.load_dynamic()
- imp.load_source()
- mmap.mmap()
- mmapobject.size()
- os.fdopen()
- os.urandom()
- random.seed()

----------
components: Library (Lib)
messages: 313407
nosy: brett.cannon, eric.snow, ncoghlan, nirs, serhiy.storchaka, twouters, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Some fstat() calls do not release the GIL, possibly hanging all threads
type: performance
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  7 18:07:33 2018
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 07 Mar 2018 23:07:33 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520464053.84.0.467229070634.issue33021@psf.upfronthosting.co.za>


Change by Nir Soffer <nirsof at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  7 18:10:04 2018
From: report at bugs.python.org (Matt Harvey)
Date: Wed, 07 Mar 2018 23:10:04 +0000
Subject: [issue32986] multiprocessing,
 default assumption of Pool size unhelpful
In-Reply-To: <1520013089.33.0.467229070634.issue32986@psf.upfronthosting.co.za>
Message-ID: <1520464204.29.0.467229070634.issue32986@psf.upfronthosting.co.za>


Matt Harvey <m.j.harvey at acellera.com> added the comment:

@njs your sketch in msg313406 looks good.  Probably better to go with OMP_NUM_THREADS than NCPUS. 
M

----------

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

From report at bugs.python.org  Wed Mar  7 18:14:13 2018
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 07 Mar 2018 23:14:13 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520464453.66.0.467229070634.issue33021@psf.upfronthosting.co.za>


Change by Nir Soffer <nirsof at gmail.com>:


----------
pull_requests: +5787

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

From report at bugs.python.org  Wed Mar  7 18:21:46 2018
From: report at bugs.python.org (pmpp)
Date: Wed, 07 Mar 2018 23:21:46 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520464906.35.0.467229070634.issue33021@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

is fstat thread safe ?

----------
nosy: +pmpp

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

From report at bugs.python.org  Wed Mar  7 18:56:42 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Mar 2018 23:56:42 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520467002.06.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

https://bugs.python.org/msg313396

----------

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

From report at bugs.python.org  Wed Mar  7 19:00:14 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Mar 2018 00:00:14 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520467214.61.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

issubclass(class-like, class-like) is allowed.
I don't think raising type error for issubclass(class-like, ABC) is good idea.  It should return False.

----------

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

From report at bugs.python.org  Wed Mar  7 19:11:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Mar 2018 00:11:04 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520467864.67.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

Hmm, normal class doesn't support issubclass(class-like. class).

```
Python 3.8.0a0 (heads/master:fc7df0e664, Mar  8 2018, 09:00:43)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import typing
>>> issubclass(typing.MutableMapping, object)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class
>>> issubclass(typing.MutableMapping, type)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class
>>> issubclass(typing.MutableMapping, typing.Mapping)
True
```

OK, problem is ABC should support it or not.

----------
nosy: +levkivskyi

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

From report at bugs.python.org  Wed Mar  7 19:45:15 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Mar 2018 00:45:15 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520469915.79.0.467229070634.issue32972@psf.upfronthosting.co.za>


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

I agree with what Zach said in msg313352.  I don't see how having a separate class affects the problem of what to use to run an async def test case.  If "an AsyncTestCase should be enough" but "other frameworks will require a different test tool", why wouldn't support in TestCase for running the test under asyncio also be enough?  I'm really not seeing what a separate class buys you.

----------

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

From report at bugs.python.org  Wed Mar  7 20:47:36 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 08 Mar 2018 01:47:36 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520473656.38.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I'm really not seeing what a separate class buys you.

I already mentioned in my previous comments that adding async support to unittest.TestCase would require us to add a metaclass to it, which is potentially a backwards incompatible change.

Moreover, I'm not even sure that `AsyncioTestCase` should be in the unittest module and not in asyncio.  Any non-trivial async package I've worked with usually requires quite a complicated setup to prepare an async test environment.  Usually a test case needs to test against different event loop policies or different event loops.  Which means that we need to support asynchronous versions of setUp, setUpClass, etc.  And I'm not sure we should just detect when they are asynchronous, perhaps we should make a set of new methods: asyncSetUp, asyncSetUpClass, etc.  This is something that needs more discussion.

So far I see that two core asyncio devs are against the proposed idea of changing unittest.TestCase to support async transparently.  IMO it gives almost no benefits but will complicate the implementation of TestCase and TestRunner (which are already quite hairy).

----------

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

From report at bugs.python.org  Wed Mar  7 21:06:53 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 02:06:53 +0000
Subject: [issue33001] Buffer overflow vulnerability in os.symlink on Windows
 (CVE-2018-1000117)
In-Reply-To: <1520273082.67.0.467229070634.issue33001@psf.upfronthosting.co.za>
Message-ID: <1520474813.73.0.467229070634.issue33001@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Victor!

----------

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

From report at bugs.python.org  Wed Mar  7 21:12:49 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Mar 2018 02:12:49 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520475169.33.0.467229070634.issue32972@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Why is a metaclass required?  Playing with a modified version of John's PR5938, it doesn't seem necessary.

----------

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

From report at bugs.python.org  Wed Mar  7 21:24:30 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 08 Mar 2018 02:24:30 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520475870.85.0.467229070634.issue33021@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

fstat is async signal safe, and I suspect it's thread safe in general, though usage does rely on the file descriptor remaining valid. If the fd in question is closed in another thread after the GIL is released, fstat would fail; if a new file is opened and assigned the same fd, it would give erroneous results. But I don't think any of that would lead to fundamentally incorrect behavior (after all, you could do the same thing manually by caching an fd then closing the file).

----------
nosy: +josh.r

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

From report at bugs.python.org  Wed Mar  7 21:54:22 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 08 Mar 2018 02:54:22 +0000
Subject: [issue22822] IPv6Network constructor docs incorrect about valid input
In-Reply-To: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za>
Message-ID: <1520477662.04.0.467229070634.issue22822@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ipaddress documentation errors

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

From report at bugs.python.org  Wed Mar  7 21:56:24 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 08 Mar 2018 02:56:24 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1520477784.62.0.467229070634.issue18802@psf.upfronthosting.co.za>


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

Ahh, I also find some errors here in ipaddress doc and opened https://github.com/python/cpython/pull/6021 to fix them.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, xiang.zhang
versions: +Python 3.7, Python 3.8 -Python 3.5

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

From report at bugs.python.org  Wed Mar  7 22:01:58 2018
From: report at bugs.python.org (pmpp)
Date: Thu, 08 Mar 2018 03:01:58 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520478118.95.0.467229070634.issue33021@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

josh.r. i think you are right, i was worried if a nfs sillyrename is in progress, for eg a lock file ,then server hangs but thread lift the GIL and allow another thread to try to start to fstat the same path.

----------

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

From report at bugs.python.org  Wed Mar  7 22:22:33 2018
From: report at bugs.python.org (Eric Appelt)
Date: Thu, 08 Mar 2018 03:22:33 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520479353.26.0.467229070634.issue26701@psf.upfronthosting.co.za>


Change by Eric Appelt <eric.appelt at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  7 22:25:22 2018
From: report at bugs.python.org (Dylan Dmitri Gray)
Date: Thu, 08 Mar 2018 03:25:22 +0000
Subject: [issue33022] Floating Point Arithmetic Inconsistency (internal
 off-by-one)
Message-ID: <1520479522.47.0.467229070634.issue33022@psf.upfronthosting.co.za>


New submission from Dylan Dmitri Gray <d.dylan.g at gmail.com>:

```
>>> for i in (1,2,3,1.0,2.0,3.0): print(i, i+9007199254740991)
...
1 9007199254740992
2 9007199254740993
3 9007199254740994
1.0 9007199254740992.0
2.0 9007199254740992.0   # <-- !!!
3.0 9007199254740994.0

```

Notably 9007199254740991 = 2**53 -1

Probably an internal off by one?

----------
messages: 313420
nosy: ddg
priority: normal
severity: normal
status: open
title: Floating Point Arithmetic Inconsistency (internal off-by-one)
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar  7 22:47:27 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 08 Mar 2018 03:47:27 +0000
Subject: [issue33022] Floating Point Arithmetic Inconsistency (internal
 off-by-one)
In-Reply-To: <1520479522.47.0.467229070634.issue33022@psf.upfronthosting.co.za>
Message-ID: <1520480847.0.0.467229070634.issue33022@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

What did you expect?  The precision of Python ints is limited only by the amount of memory you have, but Python floats are IEEE-754 double precision numbers, and have only 53 bits of precision.

2**53 + 1 simply can't be represented exactly as a float:  it requires 54 significant bits.  It must be rounded back to 53 significant bits.  Because the exact value of 2**53 + 1 is exactly half-way between the adjacent representable floats 2**53 and 2**53+2, the IEEE "round to nearest/even" rule requires rounding to the closest representable value whose 53rd (the least) significant bit is 0, which is 2**53.

Note that the 53rd bit of 9007199254740994.0 (2**53 + 2) is odd (1):

>>> (9007199254740994.0).hex()
'0x1.0000000000001p+53'
                 ^

That's why the nearest/even rule _must_ pick 2**53 instead.

You'll see the same behavior in every other language (C, C++, Java, ...) supporting IEEE-754 double precision too.

Since this really has nothing to do with Python, and is working as intended, I'll close this.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  8 01:09:21 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 06:09:21 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
Message-ID: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>


New submission from Vitaly Kruglikov <vitaly.krug at gmail.com>:

```
import copy
import ssl

copy.copy(ssl.create_default_context())
```
results in 

`TypeError: can't pickle SSLContext objects`

This prevents me from being able to `copy.deepcopy()` an object that references `ssl.SSLContext`.

The apparent root cause is apparently that `ssl.SSLContext` passes an extra arg to its `__new__` method, but doesn't implement the method `__getnewargs__` that would let `copy` extract the extra arg.

----------
messages: 313422
nosy: vitaly.krug
priority: normal
severity: normal
status: open
title: Unable to copy ssl.SSLContext
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Thu Mar  8 01:09:44 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 06:09:44 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520489384.78.0.467229070634.issue33023@psf.upfronthosting.co.za>


Change by Vitaly Kruglikov <vitaly.krug at gmail.com>:


----------
type:  -> crash

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

From report at bugs.python.org  Thu Mar  8 01:10:00 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 06:10:00 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520489400.66.0.467229070634.issue33023@psf.upfronthosting.co.za>


Change by Vitaly Kruglikov <vitaly.krug at gmail.com>:


----------
assignee:  -> christian.heimes
components: +SSL
nosy: +christian.heimes

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

From report at bugs.python.org  Thu Mar  8 01:24:49 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 06:24:49 +0000
Subject: [issue33024] asyncio.WriteTransport.set_write_buffer_limits orders
 its args unintuitively and inconsistently with its companion function's
 return value
Message-ID: <1520490289.19.0.467229070634.issue33024@psf.upfronthosting.co.za>


New submission from Vitaly Kruglikov <vitaly.krug at gmail.com>:

`asyncio.WriteTransport.set_write_buffer_limits()` uses an unintuitive order of the args (high, low). I would expect `low` to be the first arg, especially since `asyncio.WriteTransport.get_write_buffer_limits()` returns them in the opposite order. This ordering and inconsistency with the companion function's return value is error-prone. See https://docs.python.org/3/library/asyncio-protocol.html#asyncio.WriteTransport.set_write_buffer_limits

----------
components: asyncio
messages: 313423
nosy: asvetlov, vitaly.krug, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  8 01:57:47 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 06:57:47 +0000
Subject: [issue33025] urlencode produces bad output from ssl.CERT_NONE and
 friends that chokes decoders
Message-ID: <1520492267.34.0.467229070634.issue33025@psf.upfronthosting.co.za>


New submission from Vitaly Kruglikov <vitaly.krug at gmail.com>:

```
In [9]: from urllib.parse import urlencode, parse_qs

In [10]: import ast, ssl

In [11]: d = dict(cert_reqs=ssl.CERT_NONE)

In [12]: urlencode(d)
Out[12]: 'cert_reqs=VerifyMode.CERT_NONE'

In [25]: parse_qs('cert_reqs=VerifyMode.CERT_NONE')
Out[25]: {'cert_reqs': ['VerifyMode.CERT_NONE']}
In [29]: ast.literal_eval('VerifyMode.CERT_NONE')
Traceback (most recent call last)
...
ValueError: malformed node or string: <_ast.Attribute object at 0x105c22358>
```

This used to work fine and produce `'cert_reqs=0'` on Python 2.7, allowing it to be decoded properly downstream. However, `'cert_reqs=VerifyMode.CERT_NONE'` can't be decoded generically. So, something it's that used to work in prior python versions that is breaking now.

Additional information. json.dumps() actually dumps that value as a number instead of 'VerifyMode.CERT_NONE'. 

It appears that urlencode doesn't work properly with enums, where I would expect it to emit the numeric value of the enum.

----------
assignee: christian.heimes
components: Library (Lib), SSL
messages: 313424
nosy: christian.heimes, vitaly.krug
priority: normal
severity: normal
status: open
title: urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders
type: crash
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  8 02:27:45 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Mar 2018 07:27:45 +0000
Subject: [issue33019] Review usage of environment variables in the stdlib
In-Reply-To: <1520449652.42.0.467229070634.issue33019@psf.upfronthosting.co.za>
Message-ID: <1520494065.26.0.467229070634.issue33019@psf.upfronthosting.co.za>


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

It's useful if you want to hide the fact that a command is implemented in Python and don't want it to malfunction if the user has PYTHONPATH set for some reason.

----------

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

From report at bugs.python.org  Thu Mar  8 02:46:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 07:46:38 +0000
Subject: [issue33026] Fix jumping out of "with" block
Message-ID: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>


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

The proposed PR fixes jumping from "with" block. Currently the exit function is left on the stack.

This fix is for 3.8 only. 3.7 and older versions are affected by this bug, but since the code was significantly changed in 3.8, I'm not sure it will be so easy to fix it in older versions.

----------
components: Interpreter Core
messages: 313426
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix jumping out of "with" block
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar  8 02:57:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 07:57:57 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520495877.32.0.467229070634.issue33026@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar  8 04:35:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 09:35:38 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520501738.68.0.467229070634.issue33026@psf.upfronthosting.co.za>


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

Well, it is not hard to fix this in older versions.

----------
versions: +Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Mar  8 04:36:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 09:36:20 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520501780.35.0.467229070634.issue17288@psf.upfronthosting.co.za>


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

Thank you Xavier. I had pleasure from reviewing your patch. But please update tests for using the jump_test() decorator.

----------

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

From report at bugs.python.org  Thu Mar  8 04:38:00 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 08 Mar 2018 09:38:00 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520501880.87.0.467229070634.issue32972@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Class decorators are also worth considering in cases where you find yourself reaching for a metaclass.

----------
nosy: +njs

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

From report at bugs.python.org  Thu Mar  8 04:49:30 2018
From: report at bugs.python.org (=?utf-8?b?UGF3ZcWC?=)
Date: Thu, 08 Mar 2018 09:49:30 +0000
Subject: [issue33027] handling filename encoding in Content-Disposition by
 cgi.FieldStorage
Message-ID: <1520502570.19.0.467229070634.issue33027@psf.upfronthosting.co.za>


New submission from Pawe? <pawciobiel at gmail.com>:

It appears that cgi.FieldStorage does not handle 
Content-Disposition with filenames with defined encoding.
(according to RFC5987)

Example:
'''
Content-Disposition: form-data; name="file"; filename*=utf-8''upload_test_file_%C5%82%C3%B3%C4%85%C3%A4.txt
'''

The way to reproduce this is to either try to parse above or
write a tiny webapp using a web framework that uses CGI for handling
file uploads (webpy) and try to upload a file using `requests` - or any library that uses urllib3 for building POST with multipart/form-data.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition

https://tools.ietf.org/html/rfc5987

----------
components: Library (Lib)
messages: 313430
nosy: pawciobiel
priority: normal
severity: normal
status: open
title: handling filename encoding in Content-Disposition by cgi.FieldStorage
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/issue33027>
_______________________________________

From report at bugs.python.org  Thu Mar  8 04:52:17 2018
From: report at bugs.python.org (=?utf-8?b?UGF3ZcWC?=)
Date: Thu, 08 Mar 2018 09:52:17 +0000
Subject: [issue33027] handling filename encoding in Content-Disposition by
 cgi.FieldStorage
In-Reply-To: <1520502570.19.0.467229070634.issue33027@psf.upfronthosting.co.za>
Message-ID: <1520502737.4.0.467229070634.issue33027@psf.upfronthosting.co.za>


Change by Pawe? <pawciobiel at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  8 05:01:02 2018
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 08 Mar 2018 10:01:02 +0000
Subject: [issue33028] tempfile.TemporaryDirectory incorrectly documented
Message-ID: <1520503262.87.0.467229070634.issue33028@psf.upfronthosting.co.za>


New submission from Richard Neumann <r.neumann at homeinfo.de>:

The tempfile.TemporaryDirectory is incorrectly documented at https://docs.python.org/3.6/library/tempfile.html#tempfile.TemporaryDirectory.

It is described as a function, though actually being a class (unlinke tempfile.NamedTemporaryFile).
The respective property "name" and method "cleanup" are only documented in the continuous text but not explicitely highlighted as the properties and method of e.g. TarFile (https://docs.python.org/3/library/tarfile.html#tarfile-objects).

----------
assignee: docs at python
components: Documentation
messages: 313431
nosy: Richard Neumann, docs at python
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory incorrectly documented
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar  8 05:09:57 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 08 Mar 2018 10:09:57 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520503797.65.0.467229070634.issue17288@psf.upfronthosting.co.za>


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

Sorry, for some reason github did not send me the emails of your review and I did not think about checking the PR :-(
Thanks for your review, I will work on it shortly.

----------

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

From report at bugs.python.org  Thu Mar  8 06:25:18 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 11:25:18 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520508318.21.0.467229070634.issue33018@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I do not see any point in allowing non-types in ABCMeta.__subclasscheck__. Currently, ABCs are clearly not designed to support non-types:

1. ABCMeta.register() accepts types only.
2. ABCMeta.__subclasscheck__ implicitly requires its arguments to support weak references (regardless of whether __subclasshook__ is called or not). This requirement alone doesn't make sense, so it seems to be an exposed implementation detail stemming from the fact that non-types were not intended to be supported.
3. Some ABC users already expect that the argument of __subclasshook__ is a type (see the example with collections.abc.Reversible by OP).
4. Attempting to support arbitrary arguments in ABC.__subclasscheck__ (by returning False instead of raising TypeError or worse) will not solve any 'issubclass' inconsistencies. 'issubclass' is fundamentally "fragmented": issubclass(x, y) may return True/False while issubclass(x, z) may raise TypeError, depending on __subclasscheck__ implementation. It may be too late to impose stricter requirements for the first argument of issubclass because 'typing' module relies on the support of non-types there.

----------

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

From report at bugs.python.org  Thu Mar  8 06:28:39 2018
From: report at bugs.python.org (Nir Soffer)
Date: Thu, 08 Mar 2018 11:28:39 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520508519.07.0.467229070634.issue33021@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Python cannot protect raw file descriptor from bad multi-threaded
application. For example the application may close a file descriptor twice
which may lead to closing unrelated file descriptor created by another
thread just after it was closed, before the second close.

This issue affects all function using raw file descriptors, and we cannot
protect them with the GIL.

Even if fstat was not thread safe, we cannot protect it using the GIl
since this blocks the entire application until fstat returns.

----------

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

From report at bugs.python.org  Thu Mar  8 06:51:39 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 08 Mar 2018 11:51:39 +0000
Subject: [issue33024] asyncio.WriteTransport.set_write_buffer_limits orders
 its args unintuitively and inconsistently with its companion function's
 return value
In-Reply-To: <1520490289.19.0.467229070634.issue33024@psf.upfronthosting.co.za>
Message-ID: <1520509899.26.0.467229070634.issue33024@psf.upfronthosting.co.za>


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

We cannot change the method signature without breaking backward compatibility. 
I doubt if we should do something with the issue.

----------

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

From report at bugs.python.org  Thu Mar  8 07:23:03 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Mar 2018 12:23:03 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520511783.54.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

> 1. ABCMeta.register() accepts types only.

Yes.  While ABC.register() and issubclass() have different users (e.g. ABC.register() will be used by  framework author, and issubclass will be used by framework users), it's positive reason to remove non-type support.

> 2. ABCMeta.__subclasscheck__ implicitly requires its arguments to support weak references (regardless of whether __subclasshook__ is called or not). This requirement alone doesn't make sense, so it seems to be an exposed implementation detail stemming from the fact that non-types were not intended to be supported.

Isn't it just a limitation?
Most Python-implemented objects supports weakref. I don't think "requiring weakref support implies it must be type object".


> 3. Some ABC users already expect that the argument of __subclasshook__ is a type (see the example with collections.abc.Reversible by OP).

What "by OP" means?
I can't find `if not issubclass(cls, type): raise TypeError` in Reversible implementation.
They do duck-typing, same to ABC.


> 4. Attempting to support arbitrary arguments in ABC.__subclasscheck__ (by returning False instead of raising TypeError or worse) will not solve any 'issubclass' inconsistencies. 'issubclass' is fundamentally "fragmented": issubclass(x, y) may return True/False while issubclass(x, z) may raise TypeError, depending on __subclasscheck__ implementation.

Yes, as I commented above.

> It may be too late to impose stricter requirements for the first argument of issubclass because 'typing' module relies on the support of non-types there.

Of course.


Personally speaking, I dislike magics including ABC, __subclasscheck__, overwriting __class__ with dummy object.  So I'm OK to limit the ability of it.

But I don't know much about how mages use ABC.  I need mages comment before merging the pull request.

BTW, do you think it should be backported to 3.7, or even 3.6?
Can https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c be reverted?

----------

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

From report at bugs.python.org  Thu Mar  8 07:30:30 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Mar 2018 12:30:30 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520512230.43.0.467229070634.issue33023@psf.upfronthosting.co.za>


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

This is rather a feature than a bug. It is not possible to make a copy of a SSLContext object because OpenSSL doesn't support the operation. A context contains elements that can't be cloned easily, e.g. session resumption tickets.

----------

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

From report at bugs.python.org  Thu Mar  8 07:31:43 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Mar 2018 12:31:43 +0000
Subject: [issue33025] urlencode produces bad output from ssl.CERT_NONE and
 friends that chokes decoders
In-Reply-To: <1520492267.34.0.467229070634.issue33025@psf.upfronthosting.co.za>
Message-ID: <1520512303.09.0.467229070634.issue33025@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/issue33025>
_______________________________________

From report at bugs.python.org  Thu Mar  8 08:13:01 2018
From: report at bugs.python.org (Petter S)
Date: Thu, 08 Mar 2018 13:13:01 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520514781.95.0.467229070634.issue32972@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

> No, it shouldn't break them if you wrap async methods carefully.
> Here's a metaclass that I wrote recently doing just that

That code does not seem to work for me:
https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d
I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited"

@mock.patch needs to work correctly for test methods.

>> I'm really not seeing what a separate class buys you.
> I already mentioned in my previous comments that adding async support to unittest.TestCase would require us to add a metaclass to it, which is potentially a backwards incompatible change.

No, unittest.TestCase can handle this, as demonstrated by two PRs in this bug. This would not change the behavior of existing (working) code.

----------

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

From report at bugs.python.org  Thu Mar  8 08:44:35 2018
From: report at bugs.python.org (Erik Bray)
Date: Thu, 08 Mar 2018 13:44:35 +0000
Subject: [issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW
 64-bit
In-Reply-To: <1494605988.92.0.550577143248.issue30353@psf.upfronthosting.co.za>
Message-ID: <1520516675.67.0.467229070634.issue30353@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

This has a backport PR now for 3.6.  Once that PR is merged I think we can close this as fixed.

----------
stage: patch review -> backport needed
versions: +Python 3.6

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

From report at bugs.python.org  Thu Mar  8 09:30:46 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 14:30:46 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520519446.34.0.467229070634.issue33018@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Isn't it just a limitation?
> Most Python-implemented objects supports weakref. I don't think "requiring weakref support implies it must be type object".

Formally, there is no implication. It is the abc module authors who know the truth. But I can't imagine why anybody would impose such a limitation by design, because while instances of user-defined classes support weakrefs, built-in classes used by everybody like tuple, list and dict don't. That's why I guessed that non-types were not meant to be supported.

> What "by OP" means?
OP = Original poster (@jab).

> I can't find `if not issubclass(cls, type): raise TypeError` in Reversible implementation.
> They do duck-typing, same to ABC.

Sorry for being unclear. There is no explicit check as you say, but __mro__ is directly accessed (see msg313376). But it may probably be considered "duck typing" too.

> But I don't know much about how mages use ABC.  I need mages comment before merging the pull request.
Totally agree.

> BTW, do you think it should be backported to 3.7, or even 3.6?
3.7 certainly has my vote -- this can hardly be considered a new feature.

For 3.6, I'd listen to ABC users/experts. Might raising a TypeError instead of returning False from issubclass(user_defined_obj, ABC) break something important? Personally, I think it would mostly expose bugs and not hinder reasonable usage.  

> Can https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c be reverted?

Seems like it can, but the test should survive in some form :)

----------

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

From report at bugs.python.org  Thu Mar  8 09:42:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 14:42:40 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520520160.91.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

> Can https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c be reverted?

Even if subclass() will check explicitly that its first argument is a type, ABC.__subclasscheck__() can be called directly, and it shouldn't crash when called with non-type.

----------

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

From report at bugs.python.org  Thu Mar  8 09:53:28 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 14:53:28 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520520808.84.0.467229070634.issue33018@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

PR 5944 changes ABC.__subclasscheck__ (not issubclass) to check its first argument, so if it's merged there will be no crash even with the revert.

----------

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

From report at bugs.python.org  Thu Mar  8 10:11:06 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Thu, 08 Mar 2018 15:11:06 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1520521866.7.0.467229070634.issue33012@psf.upfronthosting.co.za>


Change by Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com>:


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

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

From report at bugs.python.org  Thu Mar  8 10:15:02 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Thu, 08 Mar 2018 15:15:02 +0000
Subject: [issue33029] Invalid function cast warnings with gcc 8 for getter and
 setter functions
Message-ID: <1520522102.88.0.467229070634.issue33029@psf.upfronthosting.co.za>


New submission from Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com>:

gcc 8 has added a new warning heuristic to detect invalid function casts and a stock python build seems to hit that warning quite often.  bug 33012 fixes the most trivial case of METH_NOARGS, this bug is to track a similarly trivial but widely applicable fix, which is to cast getter and setter functions.

Patches coming up over the weekend.

----------
components: Build
messages: 313443
nosy: siddhesh
priority: normal
severity: normal
status: open
title: Invalid function cast warnings with gcc 8 for getter and setter functions
type: compile error

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

From report at bugs.python.org  Thu Mar  8 10:20:20 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 15:20:20 +0000
Subject: [issue33028] tempfile.TemporaryDirectory incorrectly documented
In-Reply-To: <1520503262.87.0.467229070634.issue33028@psf.upfronthosting.co.za>
Message-ID: <1520522420.96.0.467229070634.issue33028@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +lars.gustaebel
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Mar  8 10:20:54 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 15:20:54 +0000
Subject: [issue33028] tempfile.TemporaryDirectory incorrectly documented
In-Reply-To: <1520503262.87.0.467229070634.issue33028@psf.upfronthosting.co.za>
Message-ID: <1520522454.75.0.467229070634.issue33028@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


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

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

From report at bugs.python.org  Thu Mar  8 10:28:59 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 15:28:59 +0000
Subject: [issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW
 64-bit
In-Reply-To: <1494605988.92.0.550577143248.issue30353@psf.upfronthosting.co.za>
Message-ID: <1520522939.04.0.467229070634.issue30353@psf.upfronthosting.co.za>


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


New changeset 2f3ba27185a369bcb6b36b13aa3518ffcc970ffa by Ned Deily (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-30353: Fix pass by value for structs on 64-bit Cygwin/MinGW (GH-1559) (GH-5954)
https://github.com/python/cpython/commit/2f3ba27185a369bcb6b36b13aa3518ffcc970ffa


----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Mar  8 10:34:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 15:34:17 +0000
Subject: [issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW
 64-bit
In-Reply-To: <1494605988.92.0.550577143248.issue30353@psf.upfronthosting.co.za>
Message-ID: <1520523257.71.0.467229070634.issue30353@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed
versions: +Python 3.7

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

From report at bugs.python.org  Thu Mar  8 11:03:32 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 16:03:32 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520525012.75.0.467229070634.issue33016@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 3b20d3454e8082e07dba93617793de5dc9237828 by Steve Dower (Alexey Izbyshev) in branch 'master':
bpo-33016: Fix potential use of uninitialized memory in nt._getfinalpathname (#6010)
https://github.com/python/cpython/commit/3b20d3454e8082e07dba93617793de5dc9237828


----------

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

From report at bugs.python.org  Thu Mar  8 11:04:37 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 08 Mar 2018 16:04:37 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520525077.92.0.467229070634.issue33016@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5794

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

From report at bugs.python.org  Thu Mar  8 11:16:12 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 16:16:12 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520525772.76.0.467229070634.issue33016@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +5795

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

From report at bugs.python.org  Thu Mar  8 11:20:52 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 16:20:52 +0000
Subject: [issue28113] Remove Py_CreateSymbolicLinkW
In-Reply-To: <1473747548.28.0.648303309588.issue28113@psf.upfronthosting.co.za>
Message-ID: <1520526052.47.0.467229070634.issue28113@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

We should look at merging this, though we need a few things to be done first (anyone can jump in and do these, doesn't have to be Eryk):

* patch needs to be converted to a GitHub PR
* we should use unique names within %TEMP% to avoid conflicts between tests running in parallel
* PEP 7 has changed since the original patch
* NEWS and maybe a What's New entry?

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

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

From report at bugs.python.org  Thu Mar  8 11:26:01 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 16:26:01 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
Message-ID: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

Most Win32 API calls are made within Py_BEGIN_ALLOW_THREADS blocks, as they do not access Python objects and so we can release the GIL.

However, in general, error handling occurs after the Py_END_ALLOW_THREADS line. Due to the design of the Win32 API, the pattern looks like this:

    Py_BEGIN_ALLOW_THREADS
    ret = ApiCall(...);
    Py_END_ALLOW_THREADS
    if (FAILED(ret)) {
        error_code = GetLastError();
    }

However, Py_END_ALLOW_THREADS also makes Win32 API calls (to acquire the GIL), and if any of these fail then the error code may be overwritten.

Failures in Py_END_ALLOW_THREADS are either fatal (in which case we don't care about the preceding error any more) or signal a retry (in which case we *do* care about the preceding error), but in the latter case we may have lost the error code.

Further, while Win32 APIs are not _supposed_ to set the last error to ERROR_SUCCESS (0) when they succeed, some occasionally do.

We should update Py_END_ALLOW_THREADS to preserve the last error code when necessary. Ideally, if we don't have to do any work to reacquire the GIL, we shouldn't do any work to preserve the error code either.

----------
components: Windows
messages: 313447
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: GetLastError() may be overwritten by Py_END_ALLOW_THREADS
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Mar  8 11:26:46 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 08 Mar 2018 16:26:46 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520526406.22.0.467229070634.issue33016@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8c163bbf370f6f6cedd2c07f7d54c9b36c97d8f2 by Miss Islington (bot) in branch '3.7':
bpo-33016: Fix potential use of uninitialized memory in nt._getfinalpathname (GH-6010)
https://github.com/python/cpython/commit/8c163bbf370f6f6cedd2c07f7d54c9b36c97d8f2


----------
nosy: +miss-islington

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

From report at bugs.python.org  Thu Mar  8 12:24:40 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 17:24:40 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1520529880.97.0.467229070634.issue33030@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

FWIW, GetLastError() docs[1] officially scare us:

Most functions that set the thread's last-error code set it when they fail. However, some functions also set the last-error code when they succeed. If the function is not documented to set the last-error code, the value returned by this function is simply the most recent last-error code to have been set; some functions set the last-error code to 0 on success and others do not.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx

----------
nosy: +izbyshev

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

From report at bugs.python.org  Thu Mar  8 12:29:23 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 17:29:23 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1520530163.14.0.467229070634.issue33030@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> GetLastError() docs officially scare us

I believe this is a case where the docs were updated from intended/correct behavior to actual behavior, which happens from time to time and is never clearly marked.

As I say, they are _supposed_ to leave the error unchanged unless they return a value that indicates an error occurred, but some APIs behave incorrectly. The docs are simply documenting that fact. (It turns out reality is more useful than fantasy ;) though I do wish they were clearer about that)

----------

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

From report at bugs.python.org  Thu Mar  8 12:40:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 08 Mar 2018 17:40:35 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520530835.19.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> That code does not seem to work for me:
> https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d
> I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited"

> @mock.patch needs to work correctly for test methods.
> [..]
> No, unittest.TestCase can handle this, as demonstrated by two PRs in this bug. This would not change the behavior of existing (working) code.

Correct, and while it's possible to fix my little helper to work with mocks, you're completely right that we can, indeed, implement async support in TestCase without a metaclass.  My mistake here, thanks for correcting!

In any case, while I think we can now talk about augmenting TestCase, I'd still want to first discuss few other issues:

1. Do we need support for async versions of setUp, setUpClass, etc?  In my opinion: yes.

2. There're a few options how to implement (1):

a) Add async support to TestCase. Automatically detect when a test is async, or when 'setUp' and friends are async and run them all with 'asyncio.run'.

b) Add async support to TestCase.  Add asyncSetUp, asyncSetUpClass, etc magic methods.  The argument in favour of this approach over (a) is that it's possible to safely use 'super()' calls when you have multiply inherited TestCases.

c) Add a new AsyncioTestCase specifically for working with asyncio (combine with option (b)).

I still don't like (a) because it involves too much implicit logic.  I think that it's simple enough to inherit your testcase from unittest.AsyncioTestCase and read a separate documentation specifically about it and not about generic TestCase.

----------

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

From report at bugs.python.org  Thu Mar  8 12:45:23 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 17:45:23 +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: <1520531123.53.0.467229070634.issue32592@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
nosy: +izbyshev

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

From report at bugs.python.org  Thu Mar  8 12:46:30 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 17:46:30 +0000
Subject: [issue29871] Enable optimized locks on Windows
In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za>
Message-ID: <1520531190.37.0.467229070634.issue29871@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
nosy: +izbyshev

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

From report at bugs.python.org  Thu Mar  8 13:39:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 18:39:09 +0000
Subject: [issue33031] Questionable code in OrderedDict definition
Message-ID: <1520534349.37.0.467229070634.issue33031@psf.upfronthosting.co.za>


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

The array of PyMethodDef for OrderedDict contains explicit definitions of methods like __delitem__, __eq__ and __init__. The purpose is aligning docstrings with Python implementation. But this doesn't work. Slot wrappers replace these descriptors. And docstings are standard docstrings for corresponding slot wrappers.

Thus this code doesn't work. And it looks dangerous, since functions are casted to incompatible function types. Even if they are never used, the compiler (gcc 8) produces warnings (see issue33012). May be this is even undefined behavior. In that case the compiler can generate arbitrary code.

I suggest to remove these definitions.

----------
components: Extension Modules
messages: 313452
nosy: eric.snow, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Questionable code in OrderedDict definition
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar  8 13:42:45 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 18:42:45 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1520534565.61.0.467229070634.issue33030@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Ideally, if we don't have to do any work to reacquire the GIL, we shouldn't do any work to preserve the error code either.

Before take_gil() knows whether it has to do any work, it calls MUTEX_LOCK(_PyRuntime.ceval.gil.mutex), which is either EnterCriticalSection() or AcquireSRWLockExclusive(). So unless we can be sure that those functions can't clobber the last error (or we redesign GIL to have a fast-path like an atomic compare-exchange in non-contended case), I don't see how we can avoid the last error bookkeeping.

----------

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

From report at bugs.python.org  Thu Mar  8 14:04:00 2018
From: report at bugs.python.org (Petter S)
Date: Thu, 08 Mar 2018 19:04:00 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520535840.94.0.467229070634.issue32972@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

> 1. Do we need support for async versions of setUp, setUpClass, etc?  In my opinion: yes.

I completely agree. I would imagine many or most real-world tests requiring async setUp. There is also the question on how a custom loop etc. can be used in the unit test class.

How about this: unittest.TestCase gets a very small refactor in which a overridable helper method is used to run the test method. This helper method can then be changed to run async methods in a subclass AsyncioTestCase (that probably should live in asyncio).

Pull request 6005 contained such a helper method, but the async part could be implemented in the subclass instead.

----------

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

From report at bugs.python.org  Thu Mar  8 14:12:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 19:12:29 +0000
Subject: [issue33029] Invalid function cast warnings with gcc 8 for getter and
 setter functions
In-Reply-To: <1520522102.88.0.467229070634.issue33029@psf.upfronthosting.co.za>
Message-ID: <1520536349.16.0.467229070634.issue33029@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.8

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

From report at bugs.python.org  Thu Mar  8 15:00:01 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 20:00:01 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520539201.39.0.467229070634.issue32981@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +5796

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

From report at bugs.python.org  Thu Mar  8 15:02:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 20:02:17 +0000
Subject: [issue32981] Catastrophic backtracking in poplib and difflib
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520539337.06.0.467229070634.issue32981@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +5797

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

From report at bugs.python.org  Thu Mar  8 15:03:57 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 08 Mar 2018 20:03:57 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520539437.51.0.467229070634.issue32972@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

You should also think about loop lifecycle: right now it's using the same loop for all test cases, so callbacks can leak between tests. Twisted actually goes a step further and explicitly checks for left over callbacks and fails the test if any are found.

----------

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

From report at bugs.python.org  Thu Mar  8 15:06:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Mar 2018 20:06:11 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520539571.64.0.467229070634.issue26701@psf.upfronthosting.co.za>


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

What about __floor__ and __ceil__?

I think all these three method do not deserve separate paragraphs in Doc/reference/datamodel.rst, but they should be grouped together with __round__.

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

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

From report at bugs.python.org  Thu Mar  8 15:20:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Mar 2018 20:20:10 +0000
Subject: [issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and
 difflib (CVE-2018-1061)
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520540410.11.0.467229070634.issue32981@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
keywords: +security_issue
nosy: +larry
priority: normal -> critical
title: Catastrophic backtracking in poplib and difflib -> Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)
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/issue32981>
_______________________________________

From report at bugs.python.org  Thu Mar  8 16:30:30 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 21:30:30 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1520544630.9.0.467229070634.issue33030@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> Before take_gil() knows whether it has to do any work

I thought we had a check for when the GIL was not even initialized, but that doesn't seem to exist in master any more.

Preserving GetLastError() at the same place we do errno is probably sufficient. There shouldn't be any more of a performance penalty (and maybe we don't have to preserve errno on Windows? That will save a TLS lookup at least)

----------

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

From report at bugs.python.org  Thu Mar  8 16:37:09 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 21:37:09 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520545029.73.0.467229070634.issue33023@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

Hi Christian, thank you for following up. Here is my use case, and perhaps you can suggest something else that will work:

I am refactoring the transport layer in the Pika AMQP client library. The user provides an ssl.SSLContext instance for connecting to an AMQP broker (e.g., RabbitMQ). Pika will resolve the hostname via getaddrinfo and make attempts to establish TCP and AMQP connection to the candidate IP addresses until one succeeds in establishing an AMQP connection over SSL. Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts.

How can I obtain this pristine clone cleanly for each new connection attempt?

----------

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

From report at bugs.python.org  Thu Mar  8 16:40:39 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 08 Mar 2018 21:40:39 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520545239.18.0.467229070634.issue33023@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

Also, updating ssl.SSLContext documentation about intentional inability to copy generically and suggestion how to go about it if you need to obtain a clone or similar would be terrific and save developers time so they won't run into this gotcha when designing and implementing solutions. Many thanks!

----------

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

From report at bugs.python.org  Thu Mar  8 17:00:59 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 08 Mar 2018 22:00:59 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1520546459.29.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

The issue was resolved by updating my version of the rest of the package apparently and remaking the whole thing, must have been some outdated stuff on my end causing the issue

----------

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

From report at bugs.python.org  Thu Mar  8 17:16:30 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 08 Mar 2018 22:16:30 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1520547390.84.0.467229070634.issue33030@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

FYI, here's a sampling of successful calls that modify the last error value.

Most Create- functions intentionally set the last error to 0 on success, such as CreateFile, CreateFileMapping, CreateSymbolicLink, CreateJobObject, CreateEvent, CreateMutex, CreateSemaphore, and CreateWaitableTimer. 

Some other functions also intentionally set the last error to 0 on success, such as SetWaitableTimer and the functions that work with security identifiers (SIDs) such as EqualSid, GetLengthSid, GetSidIdentifierAuthority, and GetSidSubAuthority.

The return value of some functions is the low DWORD of a file size, such as GetCompressedFileSize, GetFileSize, and SetFilePointer. In this case 0xFFFFFFFF is either a valid size or indicates an error. The function is forced to clarify this by setting the last error to 0 on success. GetFileSizeEx and SetFilePointerEx are preferred, since they don't have this problem.

Some functions make internal calls to CreateFile or DeviceIoControl. These cases might even set the last error to a non-zero value on success. Examples include GetVolumePathName (e.g. ERROR_MORE_DATA from DeviceIoControl), GetFinalPathNameByHandle (opening  "\\.\MountPointManager"), and GetDriveType (e.g. for junction mountpoints).

----------
nosy: +eryksun

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

From report at bugs.python.org  Thu Mar  8 17:27:25 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 22:27:25 +0000
Subject: [issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS
In-Reply-To: <1520526361.38.0.467229070634.issue33030@psf.upfronthosting.co.za>
Message-ID: <1520548045.22.0.467229070634.issue33030@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

@eryksun Very interesting! BTW, I looked at CreateFile docs, and the fact that it may set the last error to zero is even documented there.

@steve.dower
> maybe we don't have to preserve errno on Windows?

There are still places where errno is relied upon. PR 5784 shows one such place: os.[f]truncate(). Others are e.g. os.open() and os.lseek().

----------

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

From report at bugs.python.org  Thu Mar  8 17:29:58 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 22:29:58 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520548198.4.0.467229070634.issue33016@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Copying the comment of @eryksun from PR 6010 for reference.

Because we only try VOLUME_NAME_DOS, this function always fails for a volume that's not mounted as either a drive letter or a junction mount point. The error in this case is ERROR_PATH_NOT_FOUND. We know that the path is valid because we have a handle (in this case the file system ensures that no parent directory in the path can be unlinked or renamed). To address this, if the flags parameter isn't already VOLUME_NAME_GUID, it could switch to it and continue the while loop (no need to realloc). Otherwise if it's already VOLUME_NAME_GUID or for any other error, the call should fail.

For DOS devices in paths (e.g. "C:\Temp\NUL"), CreateFile commonly succeeds, but GetFinalPathNameByHandle commonly fails with either ERROR_INVALID_FUNCTION or ERROR_INVALID_PARAMETER. What do you think about handling this failure by calling GetFullPathName instead (e.g. "C:\Temp\NUL" => "\\.\NUL")? That way most DOS device paths won't cause this function to fail (e.g. when called by pathlib's resolve method). We could do the same if CreateFile fails with ERROR_INVALID_PARAMETER, which should only occur for CON (e.g. "C:\Temp\CON") because it needs to be opened with either generic read or generic write access.

CreatFile also commonly fails here with either ERROR_SHARING_VIOLATION (from a paging file) or ERROR_ACCESS_DENIED. But I think those are best handled by the caller, with a PermissionError exception handler. Currently pathlib's resolve method doesn't handle PermissionError like I think it should in non-strict mode. It only handles FileNotFoundError

----------

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

From report at bugs.python.org  Thu Mar  8 17:50:38 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 22:50:38 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520549438.98.0.467229070634.issue33016@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 32efcd13069a89abf007373274ee1bc0909d1996 by Steve Dower in branch '3.6':
bpo-33016: Fix potential use of uninitialized memory in nt._getfinalpathname (GH-6032)
https://github.com/python/cpython/commit/32efcd13069a89abf007373274ee1bc0909d1996


----------

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

From report at bugs.python.org  Thu Mar  8 17:51:17 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Mar 2018 22:51:17 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520549477.2.0.467229070634.issue33016@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Leaving this open for commit review (and buildbots) for a little while, but then I'll close it if we're all good.

----------
assignee:  -> steve.dower
stage: patch review -> commit review

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

From report at bugs.python.org  Thu Mar  8 17:55:51 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 22:55:51 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520549751.08.0.467229070634.issue33016@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Because we only try VOLUME_NAME_DOS, this function always fails for a volume that's not mounted as either a drive letter or a junction mount point.

If a volume is not mounted, users have to use \\?\ or \\.\ either directly or indirectly via a symlink or a junction to get to it, right? Do you think such uses are common enough to warrant dealing with VOLUME_NAME_GUID? Also note that pathlib currently expects DOS paths only: it will strip '\\?\' prefix in resolve(), making GUID path "invalid" (and, also, precluding direct usage of '\\?\' prefix with resolve() in other cases unless users are not prepared to deal with it).

----------

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

From report at bugs.python.org  Thu Mar  8 18:22:07 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 23:22:07 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520551327.83.0.467229070634.issue33016@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> unless users are not prepared to deal with it
ARE prepared

> What do you think about handling this failure by calling GetFullPathName instead (e.g. "C:\Temp\NUL" => "\\.\NUL")?

I think it would indeed be nice if pathlib handled such paths in its resolve(), especially since os.path.abspath() does handle them, and it looks weird that even resolve(strict=False) fails. That could be an enhancement, but note that it'll expose users to '\\.\'-prefixed paths which can't be returned from resolve() now. It is not necessary a problem because users should be prepared to handle UNC-like paths anyway.

> Currently pathlib's resolve method doesn't handle PermissionError like I think it should in non-strict mode. It only handles FileNotFoundError

That behavior doesn't look good, and it's inconsistent with POSIX resolve() which doesn't propagate any OSError in non-strict mode. I think this warrants an issue report.

----------

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

From report at bugs.python.org  Thu Mar  8 18:22:58 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Mar 2018 23:22:58 +0000
Subject: [issue33032] Mention implicit cache in struct.Struct docs
Message-ID: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The struct.Struct docs claim that creating and re-using a Struct object will be noticeably faster than calling the module level methods repeatedly with the same format string, as it will avoid parsing the format string multiple times: https://docs.python.org/3/library/struct.html#struct.Struct

This claim is questionable, as struct has used an internal Struct cache since at least 2.5, so if you're using less than 100 different struct layouts in any given process, the only thing you'll be saving is a string-keyed dictionary lookup.

----------
assignee: docs at python
components: Documentation
messages: 313468
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Mention implicit cache in struct.Struct docs
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Mar  8 18:25:47 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Mar 2018 23:25:47 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520551547.73.0.467229070634.issue33016@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> We know that the path is valid because we have a handle (in this case the file system ensures that no parent directory in the path can be unlinked or renamed).

Thank you for pointing this out. I erroneously stated that the length of the path could increase between GetFinalPathNameByHandle calls because an intermediate directory could be renamed, but actually I've only checked that the last part can be renamed (or even deleted, though it'll still linger in inaccessible state until the handle is closed).

----------

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

From report at bugs.python.org  Thu Mar  8 18:27:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Mar 2018 23:27:51 +0000
Subject: [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1520551671.27.0.467229070634.issue33032@psf.upfronthosting.co.za>


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

The note on https://docs.python.org/3/library/re.html#re.compile provides a useful precedent for possible wording here, as the struct cache and the regex cache are quite similar.

----------

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

From report at bugs.python.org  Thu Mar  8 19:47:58 2018
From: report at bugs.python.org (Antony Lee)
Date: Fri, 09 Mar 2018 00:47:58 +0000
Subject: [issue33033] Clarify that the signed number convertors to
 PyArg_ParseTuple... *do* overflow checking
Message-ID: <1520556478.43.0.467229070634.issue33033@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

At https://docs.python.org/3/c-api/arg.html#numbers, it is explicitly documented that the unsigned number convertors do not perform overflow checking.  Implicitly, this suggests that the signed convertors *do* perform overflow checking, which they indeed do; but it would be nice to document this behavior explicitly (as overflow checking is not always expected of C-level functions).

----------
assignee: docs at python
components: Documentation
messages: 313471
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Clarify that the signed number convertors to PyArg_ParseTuple... *do* overflow checking
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar  8 21:36:34 2018
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 09 Mar 2018 02:36:34 +0000
Subject: [issue28626] Tutorial: rearrange discussion of output formatting to
 encourage f-strings
In-Reply-To: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za>
Message-ID: <1520562994.8.0.467229070634.issue28626@psf.upfronthosting.co.za>


Change by A.M. Kuchling <amk at amk.ca>:


----------
pull_requests: +5798

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

From report at bugs.python.org  Fri Mar  9 01:15:25 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 09 Mar 2018 06:15:25 +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: <1520576125.69.0.467229070634.issue32517@psf.upfronthosting.co.za>


Change by Nathan Henrie <n8henrie at gmail.com>:


----------
keywords: +patch
pull_requests: +5799
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Mar  9 01:16:09 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 09 Mar 2018 06:16:09 +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: <1520576169.47.0.467229070634.issue32517@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

It seems to work if you close proto.transport (as is done in `test_write_pty()`).

----------

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

From report at bugs.python.org  Fri Mar  9 02:16:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Mar 2018 07:16:24 +0000
Subject: [issue33033] Clarify that the signed number convertors to
 PyArg_ParseTuple... *do* overflow checking
In-Reply-To: <1520556478.43.0.467229070634.issue33033@psf.upfronthosting.co.za>
Message-ID: <1520579784.98.0.467229070634.issue33033@psf.upfronthosting.co.za>


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

This doesn't look a good idea to me. It is implied that all checks are performed. For example it is implied that an error will be raised if the argument is of wrong type. I think that adding "with overflow checking" to every converting from a Python integer will just clutter the documentation.

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

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

From report at bugs.python.org  Fri Mar  9 03:24:01 2018
From: report at bugs.python.org (Jonathan)
Date: Fri, 09 Mar 2018 08:24:01 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
Message-ID: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>


New submission from Jonathan <bugreports at lightpear.com>:

(Confirmed in 2.7.14, 3.5.4, and 3.6.3)

I have this really bad URL from a crawl:
"http://Server=sde; Service=sde:oracle$sde:oracle11g:geopp; User=bodem; Version=SDE.DEFAULT"

if I try and parse it with wither urlparse or urlsplit it works - no errors. But when I try and get the port, I get a ValueError.

> from urllib.parse import urlparse
> r = urlparse('http://Server=sde; Service=sde:oracle$sde:oracle11g:geopp; User=bodem; Version=SDE.DEFAULT')
ParseResult(scheme='http', netloc='Server=sde; Service=sde:oracle$sde:oracle11g:geopp; User=bodem; Version=SDE.DEFAULT', path='', params='', query='', fragment='')

Ok, great, now to use the result:
> print(r.port)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "E:\Software\_libs\Python36\lib\urllib\parse.py", line 167, in port
    port = int(port, 10)
ValueError: invalid literal for int() with base 10: 'oracle$sde:oracle11g:geopp; User=bodem; Version=SDE.DEFAULT'


I'm not a Python Guru, but to me at least it's inconsistent with how every other Python Function works. In all other builtin functions I've used it would fail with the exception when I ran the function, not when I try and get the results. This caused a good few minutes of head-scratching while I tried to debug why my try/except wasn't catching it.

This inconsistency makes the results more difficult to use. Now a user needs to wrap all calls to the *results* in a try/except, or write an entire function just to "read" the results into a won't-except tuple/dict. Seems sub-optimal.


(May relate to: https://bugs.python.org/issue20059)

----------
messages: 313475
nosy: jonathan-lp
priority: normal
severity: normal
status: open
title: urllib.parse.urlparse and urlsplit not raising ValueError for bad port
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri Mar  9 03:24:24 2018
From: report at bugs.python.org (Jonathan)
Date: Fri, 09 Mar 2018 08:24:24 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1520583864.91.0.467229070634.issue33034@psf.upfronthosting.co.za>


Change by Jonathan <bugreports at lightpear.com>:


----------
versions: +Python 3.5

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

From report at bugs.python.org  Fri Mar  9 03:25:30 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Fri, 09 Mar 2018 08:25:30 +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: <1520583930.25.0.467229070634.issue32576@psf.upfronthosting.co.za>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Could you get this fixed in earlier versions of CPython? Given that 3.7 is not yet released, having this broken in 3.5 and 3.6 is highly undesirable. This apparently seems to affect our tooling [1] and telling our users to use 3.7 beta is not an option.

[1]:https://bugs.gentoo.org/647964

----------
nosy: +mgorny

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

From report at bugs.python.org  Fri Mar  9 04:15:35 2018
From: report at bugs.python.org (Jonathan)
Date: Fri, 09 Mar 2018 09:15:35 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1520586935.52.0.467229070634.issue33034@psf.upfronthosting.co.za>


Jonathan <bugreports at lightpear.com> added the comment:

Arguably the same logic applies to out-of-range ports:

> a = urlsplit('http://example.com:4444444')
> a.port
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "E:\Software\_libs\Python36\lib\urllib\parse.py", line 169, in port
    raise ValueError("Port out of range 0-65535")
ValueError: Port out of range 0-65535

----------

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

From report at bugs.python.org  Fri Mar  9 04:34:18 2018
From: report at bugs.python.org (Antony Lee)
Date: Fri, 09 Mar 2018 09:34:18 +0000
Subject: [issue33033] Clarify that the signed number convertors to
 PyArg_ParseTuple... *do* overflow checking
In-Reply-To: <1520556478.43.0.467229070634.issue33033@psf.upfronthosting.co.za>
Message-ID: <1520588058.75.0.467229070634.issue33033@psf.upfronthosting.co.za>


Antony Lee <anntzer.lee at gmail.com> added the comment:

One could just add, immediately below the "Numbers" section, something like: "The signed convertors (b, h, i, ...) perform overflow checking.  The unsigned convertors (B, H, I, ...) do not."  That would actually be shorter than the current version, which repeats the second half for each unsigned entry...

----------

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

From report at bugs.python.org  Fri Mar  9 04:52:23 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Mar 2018 09:52: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: <1520589143.76.0.467229070634.issue32576@psf.upfronthosting.co.za>


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

Micha?, sorry, I doubt it.  The fix is highly non-trivial as it first requires backporting a new feature (see issue14976).  I'm cc'ing the 3.6 branch release manager just in case.

If apparently you're witnessing this in controlled situations (the "gemato" utility, IIUC?), one workaround would be to disable the cyclic GC (call gc.disable()).  If your program doesn't create any cyclic references, or if those references don't keep too much memory alive, that would probably work.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Mar  9 05:39:23 2018
From: report at bugs.python.org (TitanSnow)
Date: Fri, 09 Mar 2018 10:39:23 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520591963.01.0.467229070634.issue32917@psf.upfronthosting.co.za>


TitanSnow <tttnns1024 at gmail.com> added the comment:

I?m afraid of breaking the backward compatibility.

----------

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

From report at bugs.python.org  Fri Mar  9 07:08:41 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 09 Mar 2018 12:08:41 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520597321.56.0.467229070634.issue32972@psf.upfronthosting.co.za>


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

1. We have an agreement that we need `asyncSetUp` and all family. I strongly support it. `super()` call is crucial argument I think.

2. Should async setup/teardown methods be a part of `unittest.TestCase` or we need a new AsyncTestCase class?

I believe adding async methods to TestCase makes no sense: without instructions how to run async code these methods are pretty useless and error-prone. Implementation of async startup/teardown without providing async runner (read about a runner below) looks like a error. If we mix everything into TestCase we should support virtually both modes in the single TestCase class: one for sync-only test case and other for async tests with async setup/teardown.

3. The next question is: should we support *every not existing yet* async framework by our tools or asyncio-compatible only. 
*Not existing yet* means we have no idea how to create a test loop, prepare it, run a test by loop, tear down everything.
Sure, we can invite a `async function runner` concept but I request a PEP for such significant addition with full specification.

Zachary Ware proposed `coroutine_runner` property in `TestCase`.
What is `coroutine_runner`? How should it work? How to run a coroutine? Subscribe for a UNIX signal or spawn a subprocess (asyncio has many tricks for signal/subprocess support, pretty sure they are not compatible with curio/trio approach)? Should we expose unified timer/socket/file API?
Is it ok that correct asyncio code will fail or even hang if `coroutine_runner` is not compatible with asyncio? If no -- that is benefit of *unified runner* if we need to use concrete runner family for writing tests?

In case of limiting build-in `AsyncioTestCase` to asyncio only we narrow down to very well defined asyncio API. Tornado and Twisted declared asyncio compatibility, they should work with the test case class.

curio/trio explicitly declared incompatibility with asyncio. That's fine, we should not support them by standard unittest classes too because we have no way to write tests for non-specified-yet contracts.

----------

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

From report at bugs.python.org  Fri Mar  9 07:40:47 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 09 Mar 2018 12:40:47 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520599247.08.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

>> Isn't it just a limitation?
>> Most Python-implemented objects supports weakref. I don't think "requiring weakref support implies it must be type object".

> Formally, there is no implication. It is the abc module authors who know the truth. But I can't imagine why anybody would impose such a limitation by design, because while instances of user-defined classes support weakrefs, built-in classes used by everybody like tuple, list and dict don't. That's why I guessed that non-types were not meant to be supported.

Of course, issubclass(42, AnyABC) must raise TypeError.  They aren't class-like object. I didn't discuss on it.

I talked about class-like objects.
For example, this code works on Python 3.6, but not on 3.7.  typing.Mapping looks like type, but it is just an instance for 3.7.

  import typing
  import collections.abc as cabc
  print(issubclass(typing.MutableMapping, cabc.Mapping))  # Python 3.7 raises TypeError

I don't think it's real problem.  But if someone claims it's real issue, we can make typing.MutableMapping more "class-like" by adding __mro__.

diff --git a/Lib/typing.py b/Lib/typing.py
index 7ca080402e..2edaa3f868 100644
--- a/Lib/typing.py
+++ b/Lib/typing.py
@@ -619,6 +619,7 @@ def __init__(self, origin, params, *, inst=True, special=False, name=None):
                               a for a in params)
         self.__parameters__ = _collect_type_vars(params)
         self.__slots__ = None  # This is not documented.
+        self.__mro__ = (origin,) + getattr(origin, '__mro__', (object,))
         if not name:
             self.__module__ = origin.__module__


Again, I don't think it's a real problem.
Maybe, we can add the check, and revert it if someone claims.

----------

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

From report at bugs.python.org  Fri Mar  9 07:56:44 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 09 Mar 2018 12:56:44 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520600204.9.0.467229070634.issue33018@psf.upfronthosting.co.za>


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

To be honest I am still undecided on this. In principle, I am OK with status quo, but I am also OK, with the PR that will prohibit non-classes. I am a bit worried that it may break some existing code, so it is probably not for 3.7.

----------

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

From report at bugs.python.org  Fri Mar  9 08:59:21 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 09 Mar 2018 13:59:21 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520603961.46.0.467229070634.issue33018@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Regarding status quo (expanding the examples of @inada.naoki and @jab):

>>> import typing
>>> import collections.abc as cabc
>>> issubclass(typing.Mapping, cabc.Mapping)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
TypeError: issubclass() arg 1 must be a class
>>> from abc import ABC
>>> issubclass(typing.Mapping, ABC)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
  File "/home/izbyshev/workspace/cpython/Lib/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
  File "/home/izbyshev/workspace/cpython/Lib/contextlib.py", line 30, in __subclasshook__
    return _collections_abc._check_methods(C, "__enter__", "__exit__")
  File "/home/izbyshev/workspace/cpython/Lib/_collections_abc.py", line 73, in _check_methods
    mro = C.__mro__
  File "/home/izbyshev/workspace/cpython/Lib/typing.py", line 706, in __getattr__
    raise AttributeError(attr)
AttributeError: __mro__
>>> ABC.register(int)
<class 'int'>
>>> issubclass(typing.Mapping, ABC)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
TypeError: issubclass() arg 1 must be a class
>>> typing.Mapping.__mro__ = ()
>>> issubclass(typing.Mapping, ABC)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
TypeError: issubclass() arg 1 must be a class
>>> typing.Mapping.__bases__ = ()
>>> issubclass(typing.Mapping, ABC)
False

Can't say that I'm OK with it :) 

I'm for forbidding non-types in ABCMeta.__subclasscheck__, but if we are to add clean support for "class-likes" instead, I think that "class-like" objects should be clearly defined, for example, that they must have __mro__ and __bases__ (and probably support weakrefs unless we want to skip caching if they don't). ABCMeta.__subclasscheck__ is not standalone: it relies on issubclass() and __subclasshook__, and both of them have some expectations in practice.

----------

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

From report at bugs.python.org  Fri Mar  9 10:27:32 2018
From: report at bugs.python.org (Stephen Wille Padnos)
Date: Fri, 09 Mar 2018 15:27:32 +0000
Subject: [issue33035] Some examples in documentation section 4.7.2 are
 incorrect
Message-ID: <1520609252.53.0.467229070634.issue33035@psf.upfronthosting.co.za>


New submission from Stephen Wille Padnos <steve at thothsystems.com>:

Section 4.7.2 of the documentation, "Keyword Arguments", has several examples of valid calls to the sample function parrot.

The function definition is:
def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):

The last two calls in the valid samples are actually not valid, since they are missing the required "voltage" parameter.
parrot('a million', 'bereft of life', 'jump')         # 3 positional arguments
parrot('a thousand', state='pushing up the daisies')  # 1 positional, 1 keyword

They should be changed to include a value for voltage, along with a change to the comment:
parrot(1000, 'a million', 'bereft of life', 'jump')         # 4 positional arguments
parrot(1000, 'a thousand', state='pushing up the daisies')  # 2 positional, 1 keyword

This issue is present in all currently available versions of the documentation: 2.7; 3.5; 3.6.4; pre (3.7); and dev (3.8).

----------
assignee: docs at python
components: Documentation
messages: 313485
nosy: docs at python, stephenwp
priority: normal
severity: normal
status: open
title: Some examples in documentation section 4.7.2 are incorrect
type: enhancement
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/issue33035>
_______________________________________

From report at bugs.python.org  Fri Mar  9 10:35:26 2018
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 09 Mar 2018 15:35:26 +0000
Subject: [issue33035] Some examples in documentation section 4.7.2 are
 incorrect
In-Reply-To: <1520609252.53.0.467229070634.issue33035@psf.upfronthosting.co.za>
Message-ID: <1520609726.74.0.467229070634.issue33035@psf.upfronthosting.co.za>


Emanuel Barry <barry at dadadata.net> added the comment:

The documentation is correct. The first argument in both of those cases is a str, which may not be what you were expecting, but the calls are still valid.

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

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

From report at bugs.python.org  Fri Mar  9 11:53:58 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 09 Mar 2018 16:53:58 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
Message-ID: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>


New submission from Nathan Henrie <n8henrie at gmail.com>:

Failing for me on latest 3.6, 3.6.1, 3.5.5, may be related to https://bugs.python.org/issue32517, presumably a change on macOS KQueue stuff.

Can anyone else on macOS 10.13.3 see if they can reproduce?

```
make clean && ./configure --with-pydebug && make -j
./python.exe -m unittest -v test.test_selectors.PollSelectorTestCase
```

----------
components: Tests
messages: 313487
nosy: n8henrie
priority: normal
severity: normal
status: open
title: test_selectors.PollSelectorTestCase failing on macOS 10.13.3
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar  9 11:55:24 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 09 Mar 2018 16:55:24 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1520614524.59.0.467229070634.issue33036@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

Traceback:

```
  File "cpython/Lib/test/test_selectors.py", line 453, in test_above_fd_setsize
    self.assertEqual(NUM_FDS // 2, len(s.select()))
  File "cpython/Lib/selectors.py", line 376, in select
    fd_event_list = self._poll.poll(timeout)
OSError: [Errno 22] Invalid argument
```

----------

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

From report at bugs.python.org  Fri Mar  9 12:26:11 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 17:26:11 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1520616371.06.0.467229070634.issue33036@psf.upfronthosting.co.za>


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

Sorry, I am not seeing this failure on 10.13.3 with either current 3.6 head or with v3.6.1.  Didn't try anything else.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Mar  9 12:39:00 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 17:39:00 +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: <1520617140.71.0.467229070634.issue32576@psf.upfronthosting.co.za>


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

Yes, backporting all of the required code to earlier releases would be out of scope for a maintenance release, particularly at this late stage in the 3.6 life cycle.  Let's see whether disabling the GC is a sufficient workaround until 3.7 is available.

----------

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

From report at bugs.python.org  Fri Mar  9 12:43:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 09 Mar 2018 17:43:47 +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: <1520617427.67.0.467229070634.issue32517@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 12f74d8608c15cacd9d5786524e2be9ca36f007e by Yury Selivanov (Nathan Henrie) in branch '3.6':
bpo-32517: fix test_read_pty_output() hangs on macOS 10.13.2+ (GH-6037)
https://github.com/python/cpython/commit/12f74d8608c15cacd9d5786524e2be9ca36f007e


----------

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

From report at bugs.python.org  Fri Mar  9 12:44:07 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 17:44:07 +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: <1520617447.53.0.467229070634.issue32517@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5801

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

From report at bugs.python.org  Fri Mar  9 13:14:17 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 18:14:17 +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: <1520619257.66.0.467229070634.issue32517@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3c39beb65d003b209a98a79af4aaf94ba16d0d29 by Miss Islington (bot) in branch '3.7':
bpo-32517: fix test_read_pty_output() hangs on macOS 10.13.2+ (GH-6037)
https://github.com/python/cpython/commit/3c39beb65d003b209a98a79af4aaf94ba16d0d29


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Mar  9 14:31:12 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 19:31:12 +0000
Subject: [issue32993] urllib and webbrowser.open() can open w/ file: protocol
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520623872.67.0.467229070634.issue32993@psf.upfronthosting.co.za>


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

This is now marked as a security issue but I do not understand what the problem is.  urllib / urllib2 are supposed to be able to open file:// style URLs, that was not the point of Issue11662.  

https://docs.python.org/3/library/urllib.request.html#urllib.request.URLopener

And webbrowser also supports file: URLs if the underlying browser does; again, that's a standard feature.

So what's the problem here?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Mar  9 15:02:07 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 20:02:07 +0000
Subject: [issue33020] Tkinter old style classes
In-Reply-To: <1520453002.72.0.467229070634.issue33020@psf.upfronthosting.co.za>
Message-ID: <1520625727.8.0.467229070634.issue33020@psf.upfronthosting.co.za>


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

Thanks for the suggestion but I agree with Serhiy.  We should not make this kind of significant change to 2.7 at this stage of its life cycle.

----------
nosy: +ned.deily
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  9 15:03:25 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 20:03:25 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520625805.47.0.467229070634.issue32758@psf.upfronthosting.co.za>


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


New changeset 7a7f100eb352d08938ee0f5ba59c18f56dc4a7b5 by Brett Cannon in branch 'master':
bpo-32758: Warn that ast.parse() and ast.literal_eval() can segfault the interpreter (GH-5960)
https://github.com/python/cpython/commit/7a7f100eb352d08938ee0f5ba59c18f56dc4a7b5


----------

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

From report at bugs.python.org  Fri Mar  9 15:04:31 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 20:04:31 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520625871.21.0.467229070634.issue32758@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5802

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

From report at bugs.python.org  Fri Mar  9 15:06:30 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 20:06:30 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520625990.7.0.467229070634.issue32758@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5803

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

From report at bugs.python.org  Fri Mar  9 15:13:26 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 20:13:26 +0000
Subject: [issue30077] Support Apple AIFF-C pseudo compression in aifc.py
In-Reply-To: <1492281879.16.0.0196863971193.issue30077@psf.upfronthosting.co.za>
Message-ID: <1520626406.79.0.467229070634.issue30077@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Fri Mar  9 15:19:50 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Mar 2018 20:19:50 +0000
Subject: [issue32987] tokenize.py parses unicode identifiers incorrectly
In-Reply-To: <1520033569.84.0.467229070634.issue32987@psf.upfronthosting.co.za>
Message-ID: <1520626790.85.0.467229070634.issue32987@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified on Win10 with 3.5 (which cannot be patched) and 3.7.0b2 that ab?cd is accepted as a name and that tokenize fails as described.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  9 15:20:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 20:20:17 +0000
Subject: [issue30940] Documentation for round() is incorrect.
In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za>
Message-ID: <1520626817.07.0.467229070634.issue30940@psf.upfronthosting.co.za>


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

This issue seems to have slipped through the cracks with a couple of long-standing PR's open.  Anyone feel up to finishing it?

----------
nosy: +ned.deily
stage: needs patch -> patch review
versions: +Python 3.8 -Python 3.5

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

From report at bugs.python.org  Fri Mar  9 15:21:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Mar 2018 20:21:18 +0000
Subject: [issue33007] Objects referencing private-mangled names do not
 roundtrip properly under pickling.
In-Reply-To: <1520314612.17.0.467229070634.issue33007@psf.upfronthosting.co.za>
Message-ID: <1520626878.82.0.467229070634.issue33007@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Fri Mar  9 15:25:05 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 20:25:05 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1520627105.08.0.467229070634.issue24084@psf.upfronthosting.co.za>


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

Based on the review comments, it looks like the existing PR 3931 needs to be revised and resubmitted against current master branch.  So, can we close PR 3931?

----------
nosy: +ned.deily
versions: +Python 3.8 -Python 3.5

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

From report at bugs.python.org  Fri Mar  9 15:26:06 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Mar 2018 20:26:06 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520627166.45.0.467229070634.issue33014@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

No new string method ;-).  "Call function keyword.iskeyword() ..." should make it clear that iskeyword is not a string method.  Samyam, I suggest getting agreement on new wording first.  Then do PR that is more or less 'pre-approved'.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Mar  9 15:27:54 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Mar 2018 20:27:54 +0000
Subject: [issue33015] Fix function cast warning in thread_pthread.h
In-Reply-To: <1520362573.83.0.467229070634.issue33015@psf.upfronthosting.co.za>
Message-ID: <1520627274.17.0.467229070634.issue33015@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +brett.cannon, pitrou

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

From report at bugs.python.org  Fri Mar  9 15:35:23 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 20:35:23 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520627723.54.0.467229070634.issue32758@psf.upfronthosting.co.za>


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


New changeset b316c44b0105d11a80ff971636143735f3655bbf by Brett Cannon (Miss Islington (bot)) in branch '3.6':
bpo-32758: Warn that ast.parse() and ast.literal_eval() can segfault the interpreter (GH-5960) (GH-6042)
https://github.com/python/cpython/commit/b316c44b0105d11a80ff971636143735f3655bbf


----------

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

From report at bugs.python.org  Fri Mar  9 15:35:44 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 20:35:44 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520627744.52.0.467229070634.issue32758@psf.upfronthosting.co.za>


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


New changeset f2fffd41b42d88fe36b483852ae33d5a415b7082 by Brett Cannon (Miss Islington (bot)) in branch '3.7':
bpo-32758: Warn that ast.parse() and ast.literal_eval() can segfault the interpreter (GH-5960) (GH-6041)
https://github.com/python/cpython/commit/f2fffd41b42d88fe36b483852ae33d5a415b7082


----------

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

From report at bugs.python.org  Fri Mar  9 15:42:59 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 20:42:59 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520628179.37.0.467229070634.issue32758@psf.upfronthosting.co.za>


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

I have the changes in for Python 3 for the ast module.

Updated TODO list:

- [x] ast module
- [ ] compile()
- [ ] eval() for >= 3.7
- [ ] exec() for >= 3.7
- [ ] dbm.dumb.open()
- [ ] inspect

----------

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

From report at bugs.python.org  Fri Mar  9 15:43:53 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 20:43:53 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520628233.28.0.467229070634.issue32758@psf.upfronthosting.co.za>


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

Actually, the TODO list is:

- [x] ast module for Python 3
- [ ] compile()
- [ ] eval() for >= 3.7
- [ ] exec() for >= 3.7
- [ ] dbm.dumb.open()
- [ ] inspect
- [ ] ast module for Python 2 (see https://github.com/python/cpython/pull/5960)

----------

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

From report at bugs.python.org  Fri Mar  9 15:44:25 2018
From: report at bugs.python.org (David Beazley)
Date: Fri, 09 Mar 2018 20:44:25 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520628265.45.0.467229070634.issue33014@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

That wording isn't much better in my opinion.  If I'm sitting there looking at methods like str.isdigit(), str.isnumeric(), str.isascii(), and str.isidentifier(), seeing keyword.iskeyword() makes me think it's a method regardless of whether you label it a function or method.  Explicitly stating that "keyword" is actually the keyword module makes it much clearer. Or at least including the argument as well keyword.iskeyword(kw).

It really should be a string method though ;-)

----------

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

From report at bugs.python.org  Fri Mar  9 15:53:30 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 20:53:30 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520628810.63.0.467229070634.issue32758@psf.upfronthosting.co.za>


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


----------
pull_requests: +5804

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

From report at bugs.python.org  Fri Mar  9 16:00:42 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 09 Mar 2018 21:00:42 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
Message-ID: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Now asyncio raises exceptions like "None type has no method feed_appdata" because self._sslpipe is set to None on closing.


See https://github.com/aio-libs/aiohttp/issues/2546 for more details.

IMHO the fix should just skip accessing self._sslpipe methods if the pipe was deleted.

----------
components: Library (Lib), asyncio
messages: 313505
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Skip sending/receiving after SSL transport closing
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:03:42 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 09 Mar 2018 21:03:42 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
In-Reply-To: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>
Message-ID: <1520629422.14.0.467229070634.issue33037@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +5805
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:19:40 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 21:19:40 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520630380.46.0.467229070634.issue32758@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5806

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:19:47 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 21:19:47 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520630387.16.0.467229070634.issue32758@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5807

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:19:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Mar 2018 21:19:56 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520630396.7.0.467229070634.issue32758@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think we can ignore the inspect module. It is unlikely that it will cause a crash unintentionally, and it is hard to use this for attacks. The attacker needs to create an extension function with malicious __text_signature__, but if he is able to execute arbitrary binary code, there is a much larger problem.

And perhaps there is no need to repeat the warning for exec() and eval(). They are considered more dangerous than compile().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:38:33 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Mar 2018 21:38:33 +0000
Subject: [issue32458] test_asyncio failures on Windows
In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za>
Message-ID: <1520631513.87.0.467229070634.issue32458@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Note, I think this failure is still happening occasionally on the windows7 buildbot; for example:

http://buildbot.python.org/all/#/builders/111/builds/68/steps/3/logs/stdio
http://buildbot.python.org/all/#/builders/111/builds/85/steps/3/logs/stdio

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32458>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:42:35 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 21:42:35 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520631755.63.0.467229070634.issue32758@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the feedback, Serhiy! Based on that, the new TODO list is:

- [x] ast module for Python 3
- [x] compile() for Python 3
- [ ] dbm.dumb.open()
- [ ] ast module for Python 2 (see https://github.com/python/cpython/pull/5960)
- [ ] compile() for Python 2 (see https://github.com/python/cpython/pull/6043)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:55:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Mar 2018 21:55:01 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520632501.61.0.467229070634.issue32758@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In 3.7 compile() can crash not only when compiling to an AST object (due to recursive AST optimization).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 16:55:26 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 09 Mar 2018 21:55:26 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520632526.34.0.467229070634.issue32758@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/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 18:17:10 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 23:17:10 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520637430.96.0.467229070634.issue32758@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

@Serhiy: Correct, which is what the warning says: https://github.com/python/cpython/pull/6043/files .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 18:53:07 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Mar 2018 23:53:07 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520639587.46.0.467229070634.issue32758@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
pull_requests: +5808

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 18:59:26 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 09 Mar 2018 23:59:26 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520639966.02.0.467229070634.issue32758@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5809

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 19:14:06 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Mar 2018 00:14:06 +0000
Subject: [issue32758] Stack overflow when parse long expression to AST
In-Reply-To: <1517682171.17.0.467229070634.issue32758@psf.upfronthosting.co.za>
Message-ID: <1520640846.75.0.467229070634.issue32758@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

- [x] ast module for Python 3
- [x] compile() for Python 3
- [x] dbm.dumb.open()
- [ ] ast module for Python 2 (see https://github.com/python/cpython/pull/5960)
- [ ] compile() for Python 2 (see https://github.com/python/cpython/pull/6043)

At this point there is only Python 2 stuff and I'm not bothered enough to see those changed, so I will leave this open for anyone who wants to put in the effort to backport the warnings.

----------
assignee: brett.cannon -> 
keywords: +easy -patch
versions:  -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32758>
_______________________________________

From report at bugs.python.org  Fri Mar  9 19:46:11 2018
From: report at bugs.python.org (Diego Argueta)
Date: Sat, 10 Mar 2018 00:46:11 +0000
Subject: [issue33038] GzipFile doesn't always ignore None as filename
Message-ID: <1520642770.84.0.467229070634.issue33038@psf.upfronthosting.co.za>


New submission from Diego Argueta <diego.argueta at gmail.com>:

The Python documentation states that if the GzipFile can't determine a filename from `fileobj` it'll use an empty string and won't be included in the header. Unfortunately, this doesn't work for SpooledTemporaryFile which has a `name` attribute but doesn't set it initially. The result is a crash.

To reproduce

```
import gzip
import tempfile

with tempfile.SpooledTemporaryFile() as fd:
    with gzip.GzipFile(mode='wb', fileobj=fd) as gz:
        gz.write(b'asdf')
```

Result:
```
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Users/diegoargueta/.pyenv/versions/2.7.14/lib/python2.7/gzip.py", line 136, in __init__
    self._write_gzip_header()
  File "/Users/diegoargueta/.pyenv/versions/2.7.14/lib/python2.7/gzip.py", line 170, in _write_gzip_header
    fname = os.path.basename(self.name)
  File "/Users/diegoargueta/.pyenv/versions/gds27/lib/python2.7/posixpath.py", line 114, in basename
    i = p.rfind('/') + 1
AttributeError: 'NoneType' object has no attribute 'rfind'
```

This doesn't happen on Python 3.6, where the null filename is handled properly. I've attached a patch file that fixed the issue for me.

----------
components: Library (Lib)
files: gzip_filename_fix.patch
keywords: patch
messages: 313512
nosy: da
priority: normal
severity: normal
status: open
title: GzipFile doesn't always ignore None as filename
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47473/gzip_filename_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33038>
_______________________________________

From report at bugs.python.org  Sat Mar 10 01:37:28 2018
From: report at bugs.python.org (TitanSnow)
Date: Sat, 10 Mar 2018 06:37:28 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520663848.03.0.467229070634.issue32917@psf.upfronthosting.co.za>


TitanSnow <tttnns1024 at gmail.com> added the comment:

If we treat the original behavior as a bug,
it?s much easier to write a patch
that just changes the default behavior
and never outputs a final blank line.

I have looked through the testsuite of it.
It seems that the original author had knew
the final blank line and treat it as
expect result. I?m not sure about it.

----------
Added file: https://bugs.python.org/file47474/simple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32917>
_______________________________________

From report at bugs.python.org  Sat Mar 10 03:44:20 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Mar 2018 08:44:20 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520671460.34.0.467229070634.issue26701@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 308eab979d153f1ab934383dc08bc4546ced8b6c by Nick Coghlan (Eric Appelt) in branch 'master':
bpo-26701: Add documentation for __trunc__ (GH-6022)
https://github.com/python/cpython/commit/308eab979d153f1ab934383dc08bc4546ced8b6c


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 03:44:23 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 08:44:23 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520671463.18.0.467229070634.issue26701@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5810

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 03:45:21 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 08:45:21 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520671521.49.0.467229070634.issue26701@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5811

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 03:57:11 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Mar 2018 08:57:11 +0000
Subject: [issue33039] int() and math.trunc don't accept objects that only
 define __index__
Message-ID: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

(Note: I haven't categorised this yet, as I'm not sure how it *should* be categorised)

Back when the __index__/nb_index slot was added, the focus was on allowing 3rd party integer types to be used in places where potentially lossy conversion with __int__/nb_int *wasn't* permitted.

However, this has led to an anomaly where the lossless conversion method *isn't* tried implicitly for the potentially lossy int() and math.trunc() calls, but is tried automatically in other contexts:

```
>>> import math
>>> class MyInt:
...     def __index__(self):
...         return 42
... 
>>> int(MyInt())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string, a bytes-like object or a number, not 'MyInt'
>>> math.trunc(MyInt())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type MyInt doesn't define __trunc__ method
>>> hex(MyInt())
'0x2a'
>>> len("a" * MyInt())
42

```

Supporting int() requires also setting `__int__`:

```
>>> MyInt.__int__ = MyInt.__index__
>>> int(MyInt())
42
```

Supporting math.trunc() requires also setting `__trunc__`:

```
>>> MyInt.__trunc__ = MyInt.__index__
>>> math.trunc(MyInt())
42
```

(This anomaly was noticed by Eric Appelt while updating the int() docs to cover the fallback to trying __trunc__ when __int__ isn't defined: https://github.com/python/cpython/pull/6022#issuecomment-371695913)

----------
messages: 313515
nosy: Eric Appelt, mark.dickinson, ncoghlan
priority: normal
severity: normal
status: open
title: int() and math.trunc don't accept objects that only define __index__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33039>
_______________________________________

From report at bugs.python.org  Sat Mar 10 04:03:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Mar 2018 09:03:27 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520672607.02.0.467229070634.issue26701@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think __trunc__ is special here, as it's called by a built-in type constructor, whereas __floor__ and __ceil__ really are specific to their respective math module functions. That said, I also wouldn't be opposed to listing all 4 methods together (or else listing __floor__ and __ceil__ with the just added entry for __trunc__).

I also filed https://bugs.python.org/issue33039 to cover an anomaly Eric found after I suggested adding __index__ to the list of methods tried, which is that int() and math.trunc() *don't* call __index__ implicitly: the type has to set "__int__ = __index__" and "__trunc__ = __index__" to get them to work.

I suspect we just didn't notice when PEP 357 was implemented because the developers that wanted __index__ were adding it to types that *already* defined __int__ and __trunc__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 04:18:46 2018
From: report at bugs.python.org (TitanSnow)
Date: Sat, 10 Mar 2018 09:18:46 +0000
Subject: [issue33040] Make itertools.islice supports negative values for start
 and stop arguments for sized iterable object
Message-ID: <1520673526.96.0.467229070634.issue33040@psf.upfronthosting.co.za>


New submission from TitanSnow <tttnns1024 at gmail.com>:

``islice()`` does not support negative values for start or stop,
which does not matter for plain iterators.
However, for some cases, we have a sized iterable object
which is not subscriptable, using ``islice()`` makes
code ugly::

    d = OrderedDict()
    for i in range(10): d[i] = i
    dv = d.keys()
    # dv is a KeysView which is a sized iterable

    # now I wanna get a slice of dv which does not contain the last element
    islice(dv, len(dv) - 1)

As it shows, I have to use ``len(dv)`` to get its length.

For sized iterable objects, ``islice()`` could
support negative values for start or stop.
In this way, the above code can be written like this::

    islice(dv, -1)

For iterable objects which is not sized,
it could still be not supported::

    islice(iter(range(10)), -1)

raises a ValueError as its original behavior.

----------
components: Library (Lib)
files: islice.patch
keywords: patch
messages: 313517
nosy: tttnns
priority: normal
severity: normal
status: open
title: Make itertools.islice supports negative values for start and stop arguments for sized iterable object
type: enhancement
Added file: https://bugs.python.org/file47475/islice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33040>
_______________________________________

From report at bugs.python.org  Sat Mar 10 05:27:48 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 10 Mar 2018 10:27:48 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1520663848.03.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <20180310102741.GL18868@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Sat, Mar 10, 2018 at 06:37:28AM +0000, TitanSnow wrote:
> 
> TitanSnow <tttnns1024 at gmail.com> added the comment:
> 
> If we treat the original behavior as a bug,
> it?s much easier to write a patch
> that just changes the default behavior
> and never outputs a final blank line.

Remind me, why do we care about that extra blank line?

> I have looked through the testsuite of it.
> It seems that the original author had knew
> the final blank line and treat it as
> expect result. I?m not sure about it.

Is there a test for it? If so, then it should stay unless the author 
agrees it can go, or we get approval on the Python-Dev mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32917>
_______________________________________

From report at bugs.python.org  Sat Mar 10 05:30:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 10:30:36 +0000
Subject: [issue33040] Make itertools.islice supports negative values for start
 and stop arguments for sized iterable object
In-Reply-To: <1520673526.96.0.467229070634.issue33040@psf.upfronthosting.co.za>
Message-ID: <1520677836.33.0.467229070634.issue33040@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think this is suitable for the itertools module. It is designed to work with iterators, i.e. with objects that support the iterator protocol. What if the iterable change the size during iteration? Should the islice iterator produce less or larger number of items than the initial estimation? Or detect this change and raise an error? Should it revive the iteration if new items were added after consuming the last item? These design questions should have thoughtful answers. And handling all corner cases will complicate the code. I afraid that after adding support of negative start and stop we will get a request for supporting negative step.

It is possible to implement support of negative indices for arbitrary iterators using tee() or deque, but this will complicate the islice() code even more for a small niche case.

This may be a use case for the new module that works specially with sequences. It will be added once we will have enough use cases.

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33040>
_______________________________________

From report at bugs.python.org  Sat Mar 10 05:36:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 10:36:50 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520678210.38.0.467229070634.issue32917@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I thought a blank line between sections is just for readability, and no program will break if drop it. Removing the final blank line can harm the readability in the case of sequential writes to the same file (unless we detect the start of the file, that is problematic in the case of non-seekable streams). But I didn't thought that a superfluous final blank line causes any problems. What software has a problem with it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32917>
_______________________________________

From report at bugs.python.org  Sat Mar 10 06:11:47 2018
From: report at bugs.python.org (Petter S)
Date: Sat, 10 Mar 2018 11:11:47 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520680307.43.0.467229070634.issue32972@psf.upfronthosting.co.za>


Change by Petter S <petter.strandmark at gmail.com>:


----------
keywords: +patch
pull_requests: +5812
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Sat Mar 10 06:32:41 2018
From: report at bugs.python.org (TitanSnow)
Date: Sat, 10 Mar 2018 11:32:41 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520681561.69.0.467229070634.issue32917@psf.upfronthosting.co.za>


TitanSnow <tttnns1024 at gmail.com> added the comment:

> But I didn't thought that a superfluous final blank line causes any problems. What software has a problem with it?

Currently I have not found a program that has problem with
the superfluous final blank line, and I think there won?t be.

> Removing the final blank line can harm the readability in the case of sequential writes to the same file

Sorry that I have not thought about this.
In this way, the prev patch that adds two new parameters might be better.

> Remind me, why do we care about that extra blank line?

Well, though it seems that that extra blank line won?t cause any problem,
it does not look nice I think, and is different with INI files written
by other applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32917>
_______________________________________

From report at bugs.python.org  Sat Mar 10 06:34:44 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Mar 2018 11:34:44 +0000
Subject: [issue33039] int() and math.trunc don't accept objects that only
 define __index__
In-Reply-To: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za>
Message-ID: <1520681684.27.0.467229070634.issue33039@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Marking this as a documentation enhancement request for now, but I think we should also consider changing the type creation behaviour in 3.8 to implicitly add __int__ and __trunc__ definitions when __index__ is defined, but they aren't.

That way, no behaviour will change for classes that explicitly define __int__ or __trunc__, but classes that only define __index__ without defining the other methods will behave more intuitively.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33039>
_______________________________________

From report at bugs.python.org  Sat Mar 10 07:32:51 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 10 Mar 2018 12:32:51 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520685171.92.0.467229070634.issue33018@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

My current opinion is:

* -1 for 3.6:  Behavior should not be changed without strong reason, even the behavior is not documented.
* +1 for 3.8:  I like strict and less magic.
* +0 for 3.7:  beta3 is bit late, but this change has very little chance to cause real world problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Sat Mar 10 07:37:09 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 10 Mar 2018 12:37:09 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520685429.31.0.467229070634.issue33018@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I agree except that I'd like to see it in 3.7 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Sat Mar 10 07:57:50 2018
From: report at bugs.python.org (TitanSnow)
Date: Sat, 10 Mar 2018 12:57:50 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520686670.4.0.467229070634.issue32917@psf.upfronthosting.co.za>


TitanSnow <tttnns1024 at gmail.com> added the comment:

For the case of sequential writes to the same file,
I think it?s a invalid use case.
The file can be created or modified by
user or other applications, breaking the assume of
ConfigParser. It?s better to have a method to merge
two ConfigParser objects then writes it into the file
at one time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32917>
_______________________________________

From report at bugs.python.org  Sat Mar 10 08:10:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 13:10:41 +0000
Subject: [issue33041] Issues with "async for"
Message-ID: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There is a number of issues with "async for".

1. When assigning to the target raises StopAsyncIteration (in custom __setitem__, __setattr__ or __iter__) it will be silenced and will cause to stop iteration.

2. StopAsyncIteration is dynamically looked up in globals. If set the global StopAsyncIteration or delete it from builtins (for example at the shutdown stage), this will break any "async for".

3. The f_lineno setter doesn't handle jumping into or out of the "async for" block. Jumping into is not forbidden, and jumping out doesn't update the stack correctly. This can cause a crash or incorrect behavior (like iterating wrong loop).

4. The compiler doesn't check all errors when creating new blocks. Some blocks are not used. And the resulting bytecode is suboptimal.

I'll create a series of pull request for fixing all this issue. Some of them can be backported. Others require changes in bytecode or are too hard for implementing in 3.7 and earlier versions (the related code was changed in issue17611). Some of them depend on other PRs or other issues (like issue33026) and need to wait until their be merged.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 313526
nosy: serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Issues with "async for"
type: crash
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 08:39:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 13:39:51 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520689191.95.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5813
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 08:40:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 13:40:38 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520689238.85.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5814

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 08:46:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 13:46:31 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520689591.63.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 6052 fixes issue 1. I don't know what is the best place for tests. There are two files with tests for "async for": test_coroutines.py and test_asyncgen.py. I'm not sure that new tests use the simplest way for testing this behavior. Could you please look at them Yury?

PR 6053 fixes issue 4. Adds missed error checks, removes unused variables and removes generating redundant bytecode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 09:10:40 2018
From: report at bugs.python.org (yao zhihua)
Date: Sat, 10 Mar 2018 14:10:40 +0000
Subject: [issue32993] urllib and webbrowser.open() can open w/ file: protocol
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520691040.59.0.467229070634.issue32993@psf.upfronthosting.co.za>


yao zhihua <hackyzh001 at gmail.com> added the comment:

Borrow what others have said from Issue11662.
--------------------
The Python urllib and urllib2 modules are typically used to fetch web
pages but by default also contains handlers for ftp:// and file:// URL
schemes.

Now unfortunately it appears that it is possible for a web server to
redirect (HTTP 302) a urllib request to any of the supported
schemes. Examples on how this could turn bad:

 1) File disclosure: A web application, that normally fetches and
 displays a web page, is redirected to file:///etc/passwd and
 discloses it.

 2) Denial of Service: An application is redirected to a system device
 (e.g. file:///dev/zero) which will result in excessive CPU/memory/disk
 usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32993>
_______________________________________

From report at bugs.python.org  Sat Mar 10 09:20:19 2018
From: report at bugs.python.org (yao zhihua)
Date: Sat, 10 Mar 2018 14:20:19 +0000
Subject: [issue32993] urllib and webbrowser.open() can open w/ file: protocol
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520691619.05.0.467229070634.issue32993@psf.upfronthosting.co.za>


yao zhihua <hackyzh001 at gmail.com> added the comment:

Here about webbrowser vulnerability.
https://bugs.python.org/issue32367

You could execute command with file protocols in python 2.7.10.

poc :
import webbrowser, os
filename = "/bin/ls"
webbrowser.open(os.path.realpath(filename))

If python has fixed this vulnerability,why can I access file:///etc/passwd? But I can't access /etc/shadow.Is this it fixed incomplete?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32993>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:02:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 15:02:23 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520694143.21.0.467229070634.issue26701@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5815

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:05:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 15:05:50 +0000
Subject: [issue32917] ConfigParser writes a superfluous final blank line
In-Reply-To: <1519349390.35.0.467229070634.issue32917@psf.upfronthosting.co.za>
Message-ID: <1520694350.9.0.467229070634.issue32917@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If there is no real problem, I think it is not worth to change this.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32917>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:08:29 2018
From: report at bugs.python.org (TitanSnow)
Date: Sat, 10 Mar 2018 15:08:29 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1520694509.3.0.467229070634.issue12345@psf.upfronthosting.co.za>


Change by TitanSnow <tttnns1024 at gmail.com>:


----------
pull_requests: +5816

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:10:39 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Mar 2018 15:10:39 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520694639.46.0.467229070634.issue26701@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset f34e0d60e27acff3f9604ec63e9de36878c3743a by Nick Coghlan (Miss Islington (bot)) in branch '3.7':
bpo-26701: Add documentation for __trunc__ (GH-6049)
https://github.com/python/cpython/commit/f34e0d60e27acff3f9604ec63e9de36878c3743a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:10:48 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Mar 2018 15:10:48 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520694648.04.0.467229070634.issue26701@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 1028ca4f04c14cf40a8f3e7951623a96ec0143c2 by Nick Coghlan (Miss Islington (bot)) in branch '3.6':
bpo-26701: Add documentation for __trunc__ (GH-6050)
https://github.com/python/cpython/commit/1028ca4f04c14cf40a8f3e7951623a96ec0143c2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:16:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 15:16:36 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520694996.72.0.467229070634.issue33014@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If this docstring needs an improvement Terry's wording LGTM. I'm -1 for further complicating it.

Where did you get the idea that iskeyword() is a string method? Nothing in the docstring points to this. "keyword" is not used as an alias of "str". It is not used anywhere else in the docstring at all.

I think this is an attempt to solve a non-problem.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:17:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 15:17:20 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1520695040.46.0.467229070634.issue12345@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -5816

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:18:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 15:18:35 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520695115.04.0.467229070634.issue26701@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 496431ffb6c29719332bf2af773349e8dd85e45a by Serhiy Storchaka in branch 'master':
bpo-26701: Improve documentation for the rounding special methods. (#6054)
https://github.com/python/cpython/commit/496431ffb6c29719332bf2af773349e8dd85e45a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:19:42 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 15:19:42 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520695182.03.0.467229070634.issue26701@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5817

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:20:41 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 15:20:41 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520695241.18.0.467229070634.issue26701@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5818

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:48:37 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 10 Mar 2018 15:48:37 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
In-Reply-To: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>
Message-ID: <1520696917.65.0.467229070634.issue33037@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 5e80a71ab67045fecec46573a1892e240b569ace by Andrew Svetlov in branch 'master':
bpo-33037: Skip sending/receiving after SSL transport closing (GH-6044)
https://github.com/python/cpython/commit/5e80a71ab67045fecec46573a1892e240b569ace


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:49:26 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 15:49:26 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520696966.72.0.467229070634.issue26701@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 89090789debb9d76892af566277cb71740808945 by Miss Islington (bot) in branch '3.7':
bpo-26701: Improve documentation for the rounding special methods. (GH-6054)
https://github.com/python/cpython/commit/89090789debb9d76892af566277cb71740808945


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:49:44 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 15:49:44 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
In-Reply-To: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>
Message-ID: <1520696984.56.0.467229070634.issue33037@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5819

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:55:15 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 15:55:15 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520697315.22.0.467229070634.issue26701@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset de8567e38c44b1509f0b906aec54437256848f14 by Miss Islington (bot) in branch '3.6':
bpo-26701: Improve documentation for the rounding special methods. (GH-6054)
https://github.com/python/cpython/commit/de8567e38c44b1509f0b906aec54437256848f14


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:56:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 10 Mar 2018 15:56:11 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520697371.44.0.467229070634.issue33041@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks so much for looking into this, Serhiy!

> 2. StopAsyncIteration is dynamically looked up in globals. If set the global StopAsyncIteration or delete it from builtins (for example at the shutdown stage), this will break any "async for".

IIRC I adapted the approach from some other place in compile.c. Quick looking at it reveals that the `assert` statement is compiled in a similar way w.r.t. how AssertionError is looked up at runtime.  You might want to check if there are other places in compile.c that need to be fixed.

> PR 6052 fixes issue 1. I don't know what is the best place for tests. There are two files with tests for "async for": test_coroutines.py and test_asyncgen.py. I'm not sure that new tests use the simplest way for testing this behavior. Could you please look at them Yury?

I think the new tests are fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 10:58:39 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 10 Mar 2018 15:58:39 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
In-Reply-To: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>
Message-ID: <1520697519.83.0.467229070634.issue33037@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +5820

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:22:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 16:22:36 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520698956.26.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 24d3201eb7f0b39a7eaf2a5b2a2ceca10ad1f8eb by Serhiy Storchaka in branch 'master':
bpo-33041: Fixed bytecode generation for "async for" with a complex target. (#6052)
https://github.com/python/cpython/commit/24d3201eb7f0b39a7eaf2a5b2a2ceca10ad1f8eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:24:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Mar 2018 16:24:47 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520699087.55.0.467229070634.issue33014@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I don't think my suggestion is much better either, and I otherwise agree with Serhiy.  There are a thousand+ more important doc issues.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:27:03 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 10 Mar 2018 16:27:03 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
In-Reply-To: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>
Message-ID: <1520699223.84.0.467229070634.issue33037@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset bf0d1165174e8347b4d3a731c4e47e8288f1d01b by Andrew Svetlov (Miss Islington (bot)) in branch '3.7':
bpo-33037: Skip sending/receiving after SSL transport closing (GH-6044) (GH-6057)
https://github.com/python/cpython/commit/bf0d1165174e8347b4d3a731c4e47e8288f1d01b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:27:32 2018
From: report at bugs.python.org (David Beazley)
Date: Sat, 10 Mar 2018 16:27:32 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520699252.18.0.467229070634.issue33014@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

s = 'Some String'
s.isalnum()
s.isalpha()
s.isdecimal()
s.isdigit()
s.isidentifier()
s.islower()
s.isnumeric()
s.isprintable()
s.isspace()
s.istitle()
s.isupper()

Not really sure where I would have gotten the idea that it might be referring to s.iskeyword().  But what do I know?  I'll stop submitting further suggestions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:29:07 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Mar 2018 16:29:07 +0000
Subject: [issue30249] improve struct.unpack_from's error message like
 struct.pack_into
In-Reply-To: <1493801720.08.0.647129145601.issue30249@psf.upfronthosting.co.za>
Message-ID: <1520699347.87.0.467229070634.issue30249@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +5821
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30249>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:30:58 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Mar 2018 16:30:58 +0000
Subject: [issue30249] improve struct.unpack_from's error message like
 struct.pack_into
In-Reply-To: <1493801720.08.0.647129145601.issue30249@psf.upfronthosting.co.za>
Message-ID: <1520699458.7.0.467229070634.issue30249@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
assignee:  -> xiang.zhang
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30249>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:49:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 16:49:28 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520700568.83.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 67ee07795bcd84b679c000780212d4d81a1490a3 by Serhiy Storchaka in branch 'master':
bpo-33041: Add missed error checks when compile "async for" (#6053)
https://github.com/python/cpython/commit/67ee07795bcd84b679c000780212d4d81a1490a3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:53:39 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Mar 2018 16:53:39 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520700819.55.0.467229070634.issue33014@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Part of my reason for closing is that we have an index entry "iskeyword() (in module keyword)"  to help anyone who tries the function as a method.  But I am reopening for 2 reasons:

 1. I think the following is a better improvement that reads better as well as being more informative.  I would be willing to merge it.

"Call keyword.iskeyword(s) to test whether string s is a reserved identifier, such as "def" or "class".

2. We should fix the buggy iskeyword docstring in 2.7 and 3.x.

>>> keyword.iskeyword.__doc__
'x.__contains__(y) <==> y in x.'

Replace with the doc entry: "Return true if s is a Python keyword."

----------
resolution: rejected -> 
stage: resolved -> needs patch
status: closed -> open
type:  -> behavior
versions: +Python 2.7, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:55:10 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Mar 2018 16:55:10 +0000
Subject: [issue33014] Clarify str.isidentifier docstring,
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520700910.62.0.467229070634.issue33014@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Clarify doc string for str.isidentifier() -> Clarify str.isidentifier docstring, fix keyword.iskeyword docstring

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 11:58:30 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Mar 2018 16:58:30 +0000
Subject: [issue33040] Make itertools.islice supports negative values for start
 and stop arguments for sized iterable object
In-Reply-To: <1520673526.96.0.467229070634.issue33040@psf.upfronthosting.co.za>
Message-ID: <1520701110.13.0.467229070634.issue33040@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Serhiy.  This doesn't make sense for itertools.

Marking this as closed. Thank you for the suggestion.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33040>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:00:47 2018
From: report at bugs.python.org (Hartmut Goebel)
Date: Sat, 10 Mar 2018 17:00:47 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
Message-ID: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>


New submission from Hartmut Goebel <h.goebel at crazy-compilers.com>:

PyInstaller is a tool for freezing Python applications into stand-alone packages, much like py2exe. py2app, and bbfreeze. PyInstaller is providing *one* bootloader for all versions of Python supported (2.7, 3.4-3.6).

In PyInstaller the startup sequence is implemented in
pyi_pylib_start_python() in bootloader/src/pyi_pythonlib.c. The workflow roughly is:

- SetProgramName
- SetPythonHome
- Py_SetPath
- Setting runtime options
  - some flags using the global variables
  - PySys_AddWarnOption -> crash
- Py_Initialize
- PySys_SetPath

The crash occurs due to tstate (thread state) not being initialized when
calling PySys_AddWarnOption.

----------
components: Interpreter Core
messages: 313546
nosy: htgoebel
priority: normal
severity: normal
status: open
title: New 3.7 startup sequence crashes PyInstaller
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:09:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 10 Mar 2018 17:09:09 +0000
Subject: [issue33037] Skip sending/receiving after SSL transport closing
In-Reply-To: <1520629242.5.0.467229070634.issue33037@psf.upfronthosting.co.za>
Message-ID: <1520701749.96.0.467229070634.issue33037@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 017e9fda922a143ac9f1601cbde05e80214852d2 by Andrew Svetlov in branch '3.6':
[3.6] bpo-33037: Skip sending/receiving after SSL transport closing (GH-6044) (GH-6058)
https://github.com/python/cpython/commit/017e9fda922a143ac9f1601cbde05e80214852d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33037>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:11:50 2018
From: report at bugs.python.org (Carol Willing)
Date: Sat, 10 Mar 2018 17:11:50 +0000
Subject: [issue33014] Clarify doc string for str.isidentifier()
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520701910.6.0.467229070634.issue33014@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Terry's latest documentation suggestion sounds good and "explicit" by including an example.

David, I appreciate your doc suggestions. If it's befuddling you, it's likely doing the same for others.

CuriousLearner, do you wish to try to incorporate Terry's latest suggestions?

Thanks all.

----------
nosy: +willingc
title: Clarify str.isidentifier docstring, fix keyword.iskeyword docstring -> Clarify doc string for str.isidentifier()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:30:28 2018
From: report at bugs.python.org (Carol Willing)
Date: Sat, 10 Mar 2018 17:30:28 +0000
Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of
 docs.python.org
Message-ID: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za>


New submission from Carol Willing <willingc at gmail.com>:

Adding a 'Contributing to Docs' link at the bottom of the docs.python.org page between 'Reporting bugs' and 'About Documentation'.

This could link to the devguide section on contributing to docs or provide a short paragraph including:
- the importance of CPython docs as well as other Python projects (warehouse, popular libraries, etc.)
- link to the devguide and its section on documentation
- link to the core mentorship mailing list
- link to docs mailing list

As an example, the Rust project's Docs-Contributing page is a good start: https://www.rust-lang.org/en-US/contribute-docs.html

----------
assignee: docs at python
components: Documentation
messages: 313549
nosy: docs at python, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a 'Contributing to Docs' link at the bottom of docs.python.org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33043>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:34:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 17:34:22 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520703262.18.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5822

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:44:28 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Mar 2018 17:44:28 +0000
Subject: [issue33014] Clarify str.isidentifier docstring,
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520703868.67.0.467229070634.issue33014@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Debating historical design decisions that effectively cannot be changed is off topic for the tracker (but fair game on python-list).  However, I will explain this much.  The s.isxyz questions are answered by examining the characters and codepoints in s.  Answering iskeyword(s) requires reference to the collection of keywords, kwlist, which must be exposed to users, and which may change in any new version.  We usually attach constant data attributes to modules (other than builtins), and never (that I can think of) to built-in classes.  "def iskeyword(s): return s in kwlist:" belongs in the module with kwlist.

----------
nosy:  -willingc
title: Clarify doc string for str.isidentifier() -> Clarify str.isidentifier docstring, fix keyword.iskeyword docstring

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:51:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Mar 2018 17:51:08 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520704268.49.0.467229070634.issue33014@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +willingc -serhiy.storchaka
title: Clarify str.isidentifier docstring, fix keyword.iskeyword docstring -> Clarify str.isidentifier docstring; fix keyword.iskeyword docstring
versions:  -Python 2.7, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 12:51:44 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Mar 2018 17:51:44 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520704304.81.0.467229070634.issue33014@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:28:00 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Sat, 10 Mar 2018 18:28:00 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520706480.8.0.467229070634.issue26680@psf.upfronthosting.co.za>


Robert Smallshire <rob at sixty-north.com> added the comment:

I've recently run into this issue impeding duck-typing between int and float again, when used in conjunction the int.__pow__, which may variously return an int or float depending on the value - not the type - of the arguments.

This is succinctly demonstrated by this example:

  >>> (10 ** -2).is_integer()
  False
  >>> (10 ** 2).is_integer()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  AttributeError: 'int' object has no attribute 'is_integer'

I hear the argument about Python being harder to learn if more methods are supported on the built-in types - and perhaps float.is_integer should never have been added, but now its there, but I think Python is harder to learn and teach in the presence of these differences. Is is harder to learn "Real numbers support an is_integer() method", than it is "float supports an is_integer() method"?

I'm happy to put in the work bring my original patches up-to-date, or create a PR depending on what current process is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:31:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Mar 2018 18:31:50 +0000
Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of
 docs.python.org
In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za>
Message-ID: <1520706710.46.0.467229070634.issue33043@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

That's a good idea.  I see that there is already a "Found a bug?" link at the bottom of each doc page and that links to a page like:

https://docs.python.org/3/bugs.html

and that page has a Documentation Bugs section.  Perhaps adding a link or two in there would help.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33043>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:35:34 2018
From: report at bugs.python.org (Himanshu Lakhara)
Date: Sat, 10 Mar 2018 18:35:34 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1520706934.06.0.467229070634.issue27428@psf.upfronthosting.co.za>


Change by Himanshu Lakhara <himanshulakhara1947 at gmail.com>:


----------
keywords: +patch
pull_requests: +5823
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:41:45 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Mar 2018 18:41:45 +0000
Subject: [issue32165] PyEval_InitThreads is called before Py_Initialize in
 LoadPython in Modules/_ctypes/callbacks.c
In-Reply-To: <1511924168.1.0.213398074469.issue32165@psf.upfronthosting.co.za>
Message-ID: <1520707305.6.0.467229070634.issue32165@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32165>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:45:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Mar 2018 18:45:07 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520707507.52.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9e94c0d3c78d1bc582c865240ed9353fe9689b2a by Serhiy Storchaka in branch '3.7':
[3.7] bpo-33041: Add missed error checks when compile "async for" (GH-6053) (GH-6060)
https://github.com/python/cpython/commit/9e94c0d3c78d1bc582c865240ed9353fe9689b2a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:46:16 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 18:46:16 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520707576.57.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5824

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:47:25 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Mar 2018 18:47:25 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1520707645.22.0.467229070634.issue33042@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +eric.snow, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sat Mar 10 13:58:54 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Mar 2018 18:58:54 +0000
Subject: [issue30249] improve struct.unpack_from's error message like
 struct.pack_into
In-Reply-To: <1493801720.08.0.647129145601.issue30249@psf.upfronthosting.co.za>
Message-ID: <1520708334.92.0.467229070634.issue30249@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset c10b288f345aaef66d2c844924b9a576f9ea4f8b by Xiang Zhang in branch 'master':
bpo-30249: Improve struct.unpack_from() error messages (GH-6059)
https://github.com/python/cpython/commit/c10b288f345aaef66d2c844924b9a576f9ea4f8b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30249>
_______________________________________

From report at bugs.python.org  Sat Mar 10 14:00:24 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Mar 2018 19:00:24 +0000
Subject: [issue30249] improve struct.unpack_from's error message like
 struct.pack_into
In-Reply-To: <1493801720.08.0.647129145601.issue30249@psf.upfronthosting.co.za>
Message-ID: <1520708424.78.0.467229070634.issue30249@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/issue30249>
_______________________________________

From report at bugs.python.org  Sat Mar 10 14:32:52 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 19:32:52 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520710372.92.0.467229070634.issue33041@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d0826340d96e0953793b86d0b8475d2f43a280b6 by Miss Islington (bot) in branch '3.6':
[3.7] bpo-33041: Add missed error checks when compile "async for" (GH-6053) (GH-6060)
https://github.com/python/cpython/commit/d0826340d96e0953793b86d0b8475d2f43a280b6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sat Mar 10 14:53:14 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Mar 2018 19:53:14 +0000
Subject: [issue33015] Fix function cast warning in thread_pthread.h
In-Reply-To: <1520362573.83.0.467229070634.issue33015@psf.upfronthosting.co.za>
Message-ID: <1520711594.07.0.467229070634.issue33015@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33015>
_______________________________________

From report at bugs.python.org  Sat Mar 10 15:48:11 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Mar 2018 20:48:11 +0000
Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does
 not validate strings
In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za>
Message-ID: <1520714891.93.0.467229070634.issue32367@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Update: https://security-tracker.debian.org/tracker/CVE-2017-17522

"** DISPUTED [...] NOTE: a software maintainer indicates that exploitation is impossible because the code relies on subprocess.Popen and the default shell=False setting."

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32367>
_______________________________________

From report at bugs.python.org  Sat Mar 10 16:41:25 2018
From: report at bugs.python.org (Ishan Srivastava)
Date: Sat, 10 Mar 2018 21:41:25 +0000
Subject: [issue33044] pdb from base class, get inside a method of derived class
Message-ID: <1520718085.04.0.467229070634.issue33044@psf.upfronthosting.co.za>


New submission from Ishan Srivastava <ishan.srt at gmail.com>:

I need to use `pdb.set_trace()` in the base class. It has a method:

```
def run(self, *args, **kwargs):
    raise NotImplementedError
```
Since this base class is derived by many subclasses I don't know before hand which class' `run()` method I need to get inside. Also there is some pre processing of the arguments given to the `run()` method. So when `pdb` reaches the line,

```
q=self.run(arguments)
```

and I hit `s` it acts as if I have given the command `next`.

How can I get inside the derived class' `run()` method with `pdb` and debug the code over there?

----------
components: Library (Lib)
messages: 313557
nosy: ishanSrt
priority: normal
severity: normal
status: open
title: pdb from base class, get inside a method of derived class
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33044>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:08:34 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 10 Mar 2018 22:08:34 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520719714.3.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset d7aed4102d2a40c74553240c7f03585624d27aea by Berker Peksag (Emanuele Gaifas) in branch 'master':
bpo-27645: Add support for native backup facility of SQLite (GH-4238)
https://github.com/python/cpython/commit/d7aed4102d2a40c74553240c7f03585624d27aea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:09:48 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 22:09:48 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520719788.84.0.467229070634.issue27645@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5825

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:27:05 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sat, 10 Mar 2018 22:27:05 +0000
Subject: [issue33045] SSL Dcumentation Error
Message-ID: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>


New submission from Matt Eaton <agnosticdev at gmail.com>:

I was reading through the SSL documentation and noticed a typo on Diffe-Hellman and wanted to clean it up.  

PR is coming soon.

----------
assignee: docs at python
components: Documentation
messages: 313559
nosy: agnosticdev, docs at python
priority: normal
severity: normal
status: open
title: SSL Dcumentation Error
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:29:21 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 10 Mar 2018 22:29:21 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520720961.38.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e8a5a92037b1f27809806bb87c17976d2d48d3e9 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-27645: Add support for native backup facility of SQLite (GH-4238)
https://github.com/python/cpython/commit/e8a5a92037b1f27809806bb87c17976d2d48d3e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:32:03 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 10 Mar 2018 22:32:03 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520721123.59.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks, Lele.

Note that Ned gave his permission to get this into 3.7.0b3 at https://github.com/python/cpython/pull/4238#issuecomment-371947334 We can, of course, still revert it before 3.7.0 final.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:35:06 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sat, 10 Mar 2018 22:35:06 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520721306.22.0.467229070634.issue33045@psf.upfronthosting.co.za>


Change by Matt Eaton <agnosticdev at gmail.com>:


----------
keywords: +patch
pull_requests: +5826
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:48:07 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 10 Mar 2018 22:48:07 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520722087.66.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

>From http://buildbot.python.org/all/#/builders/13/builds/808

======================================================================
FAIL: test_bad_target_in_transaction (sqlite3.test.backup.BackupTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/sqlite3/test/backup.py", line 44, in test_bad_target_in_transaction
    self.cx.backup(bck)
AssertionError: OperationalError not raised

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 17:52:50 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 10 Mar 2018 22:52:50 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520722370.04.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

>From test.pythoninfo:

sqlite3.sqlite_version: 3.8.7.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 18:09:29 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 10 Mar 2018 23:09:29 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520723369.05.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

AppVeyor:

sqlite3.sqlite_version: 3.21.0 (passed)

Travis CI:

sqlite3.sqlite_version: 3.8.2 (passed)

http://buildbot.python.org/all/#/builders/88/builds/799

sqlite3.sqlite_version: 3.8.2 (passed)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 18:11:49 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 10 Mar 2018 23:11:49 +0000
Subject: [issue32836] Symbol table for comprehensions (list, dict,
 set) still includes temporary _[1] variable
In-Reply-To: <1518471231.56.0.467229070634.issue32836@psf.upfronthosting.co.za>
Message-ID: <1520723509.85.0.467229070634.issue32836@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5506d603021518eaaa89e7037905f7a698c5e95c by Miss Islington (bot) in branch '3.7':
bpo-32836: Remove obsolete code from symtable pass (GH-5680)
https://github.com/python/cpython/commit/5506d603021518eaaa89e7037905f7a698c5e95c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32836>
_______________________________________

From report at bugs.python.org  Sat Mar 10 18:25:47 2018
From: report at bugs.python.org (Carol Willing)
Date: Sat, 10 Mar 2018 23:25:47 +0000
Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of
 docs.python.org
In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za>
Message-ID: <1520724347.34.0.467229070634.issue33043@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Great suggestion Ned. It would be great to have some links on the bug page too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33043>
_______________________________________

From report at bugs.python.org  Sat Mar 10 18:41:26 2018
From: report at bugs.python.org (Carol Willing)
Date: Sat, 10 Mar 2018 23:41:26 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1520725286.23.0.467229070634.issue25910@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

A number of PRs have been merged since this issue opened in 2015. After Victor's merge of GH-1933 in January 2018, this looks ready to close. I'm going to close it. 

If there are further links that need fixing as they sometimes fall out of date, please open a new issue with specific links needing updating. Thanks.

----------
nosy: +willingc
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:19:04 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 00:19:04 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520727544.22.0.467229070634.issue27645@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +5828
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:35:15 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 00:35:15 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520728515.23.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Test also passed on my MBP with SQLite 3.22.0 and the following line

    rc = _pysqlite_seterror(bck_conn, NULL);

returns

    1 (SQLITE_ERROR)

with

    "SQL logic error"

Looging at https://www.sqlite.org/src/artifact?ln=on&name=faf17e60b43233c2, checkReadTransaction() returns

    sqlite3ErrorWithMsg(db, SQLITE_ERROR, "destination database is in use");
    return SQLITE_ERROR;

I've opened PR 6067 to skip the test under SQLite 3.8.7.1 for now.

Lele, could you take a look at this please? It's almost 4 am here I won't be able to work on this in the next 10-15 hours.

----------
resolution: fixed -> 
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:35:39 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 00:35:39 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520728539.8.0.467229070634.issue27645@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:38:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 00:38:52 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520728732.31.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 7280a4eef5fbe17e8ac82afd71fe6e51843240a5 by Berker Peksag in branch 'master':
bpo-27645: Skip test_bad_target_in_transaction if SQLite == 3.8.7.1 (GH-6067)
https://github.com/python/cpython/commit/7280a4eef5fbe17e8ac82afd71fe6e51843240a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:39:11 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 00:39:11 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520728751.36.0.467229070634.issue27645@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5829

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:48:01 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 11 Mar 2018 00:48:01 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1520729281.4.0.467229070634.issue33034@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sat Mar 10 19:59:13 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 00:59:13 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520729953.45.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c546a62c4d7b37ead10f986554a01d6d593227a1 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-27645: Skip test_bad_target_in_transaction if SQLite == 3.8.7.1 (GH-6067)
https://github.com/python/cpython/commit/c546a62c4d7b37ead10f986554a01d6d593227a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:00:07 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 01:00:07 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520730007.41.0.467229070634.issue33045@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 9cf8c42f3231d3f066670d087a997bd1278482a0 by Berker Peksag (Matt Eaton) in branch 'master':
bpo-33045: Fix typos in SSL documentation (GH-6065)
https://github.com/python/cpython/commit/9cf8c42f3231d3f066670d087a997bd1278482a0


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:00:20 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 01:00:20 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520730020.17.0.467229070634.issue33045@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5830

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:01:12 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 01:01:12 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520730072.87.0.467229070634.issue33045@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5831

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:21:30 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 01:21:30 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520731290.07.0.467229070634.issue33045@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 17b6c19d39229619de649f5a9e28a46779ef1c51 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-33045: Fix typos in SSL documentation (GH-6065)
https://github.com/python/cpython/commit/17b6c19d39229619de649f5a9e28a46779ef1c51


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:26:03 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 01:26:03 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520731563.83.0.467229070634.issue33045@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 3f439d14ad48f5d4f6017fc814326fb1f6237b53 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-33045: Fix typos in SSL documentation (GH-6065)
https://github.com/python/cpython/commit/3f439d14ad48f5d4f6017fc814326fb1f6237b53


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:27:05 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 01:27:05 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520731625.81.0.467229070634.issue33045@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you, Matt (and welcome to Python development!)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:29:23 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sun, 11 Mar 2018 01:29:23 +0000
Subject: [issue33045] SSL Dcumentation Error
In-Reply-To: <1520720825.94.0.467229070634.issue33045@psf.upfronthosting.co.za>
Message-ID: <1520731763.6.0.467229070634.issue33045@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Thank you very much, Berker!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33045>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:48:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 01:48:17 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520732897.1.0.467229070634.issue32996@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 51302a5fcc557e6afc0bf1e3b371f5f37c76dc77 by Serhiy Storchaka in branch 'master':
bpo-32996: Improve What's New in 3.7. (#5983)
https://github.com/python/cpython/commit/51302a5fcc557e6afc0bf1e3b371f5f37c76dc77


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:49:29 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 01:49:29 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520732969.79.0.467229070634.issue32996@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5832

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sat Mar 10 20:51:41 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 11 Mar 2018 01:51:41 +0000
Subject: [issue33038] GzipFile doesn't always ignore None as filename
In-Reply-To: <1520642770.84.0.467229070634.issue33038@psf.upfronthosting.co.za>
Message-ID: <1520733101.22.0.467229070634.issue33038@psf.upfronthosting.co.za>


bbayles <bbayles at gmail.com> added the comment:

da, would you mind if I add a test and a news entry to your patch and submit it as a Github pull request?

----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33038>
_______________________________________

From report at bugs.python.org  Sat Mar 10 23:58:03 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Mar 2018 04:58:03 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520744283.02.0.467229070634.issue26680@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry Robert, but I object to this going forward.

1) We do not and should not require that every float() method also be in int():

   >>> set(dir(float)) - set(dir(int))			 
   {'fromhex', 'hex', 'is_integer', '__getformat__', '__setformat__', 
    'as_integer_ratio'}

2) Your use case is trivially solved in a portable, trivial, and readable way:

   a == int(a)

3) I really don't want to clutter the other types with this method when it does nothing useful for those types.  In particular, I expect that the presence of "is_integer()" in the int() class will likely create more confusion than it solves (perhaps not for you, but for the vast majority of users, none of whom have ever requested this behavior over the entire history of the language).

4) Also, I don't what this to have to propagate to every project that ever registers their custom numeric types with the numeric tower.  Adding this method to the tower is essentially making a requirement that everyone, everywhere must add this method.   That is not in the spirit of what the ABCs are all about -- they mostly require a small and useful subset of the behaviors of the related concrete classes (i.e. the concrete collections all have more methods than are required by their collections.abc counterparts).

5) Lastly, the spirit of the decimal module was to stick as closely as possible to the decimal specification and assiduously avoid extending the spec with new inventions (risking duplication of functionality, risking non-portability with other implementations, risking not handling special values in a way that is consistent with the spec, risking our going down a path that intentionally not chosen by the spec creators, or risking being at odds with subsequent updates to the spec).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Sun Mar 11 00:14:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Mar 2018 05:14:08 +0000
Subject: [issue33046] IDLE option to strip trailing whitespace automatically
 on save
Message-ID: <1520745248.32.0.467229070634.issue33046@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Add option to IDLE preferences in the general section to automatically run Strip Trailing Whitespace before saving.

People who use Strip Trailing Whitespace generally do so just before saving and they do it over and over again as they develop and check in code.  It would be nice to have this done automatically.  In general, trailing whitespace is almost never desireable.

----------
assignee: terry.reedy
components: IDLE
messages: 313580
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE option to strip trailing whitespace automatically on save
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33046>
_______________________________________

From report at bugs.python.org  Sun Mar 11 01:29:35 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 06:29:35 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520749775.59.0.467229070634.issue32996@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 720a4b69c6b66ae5d6f447d5814bd204170c94b3 by Miss Islington (bot) in branch '3.7':
bpo-32996: Improve What's New in 3.7. (GH-5983)
https://github.com/python/cpython/commit/720a4b69c6b66ae5d6f447d5814bd204170c94b3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sun Mar 11 01:32:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 06:32:49 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520749969.67.0.467229070634.issue33026@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 26c9f565d016db21257a60d29ab2c99383dd5ac7 by Serhiy Storchaka in branch 'master':
bpo-33026: Fix jumping out of "with" block by setting f_lineno. (#6026)
https://github.com/python/cpython/commit/26c9f565d016db21257a60d29ab2c99383dd5ac7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 01:38:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 06:38:15 +0000
Subject: [issue32338] Save OrderedDict import in re
In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za>
Message-ID: <1520750295.92.0.467229070634.issue32338@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b931bd0a2fe7e9293339019352baf3317166b769 by Serhiy Storchaka in branch 'master':
bpo-32338: OrderedDict import is no longer needed in re. (#4891)
https://github.com/python/cpython/commit/b931bd0a2fe7e9293339019352baf3317166b769


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32338>
_______________________________________

From report at bugs.python.org  Sun Mar 11 01:39:27 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 06:39:27 +0000
Subject: [issue32338] Save OrderedDict import in re
In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za>
Message-ID: <1520750367.88.0.467229070634.issue32338@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5833

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32338>
_______________________________________

From report at bugs.python.org  Sun Mar 11 01:51:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 06:51:38 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520751098.0.0.467229070634.issue33026@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5834

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 03:02:00 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 07:02:00 +0000
Subject: [issue32338] Save OrderedDict import in re
In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za>
Message-ID: <1520751720.49.0.467229070634.issue32338@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 39441fce0218a3f51a80cf17aa179a32651a02f6 by Miss Islington (bot) in branch '3.7':
bpo-32338: OrderedDict import is no longer needed in re. (GH-4891)
https://github.com/python/cpython/commit/39441fce0218a3f51a80cf17aa179a32651a02f6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32338>
_______________________________________

From report at bugs.python.org  Sun Mar 11 03:05:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 07:05:34 +0000
Subject: [issue32337] Dict order is now guaranteed, so add tests and doc for it
In-Reply-To: <1514287514.34.0.213398074469.issue32337@psf.upfronthosting.co.za>
Message-ID: <1520751934.1.0.467229070634.issue32337@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/issue32337>
_______________________________________

From report at bugs.python.org  Sun Mar 11 03:06:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 07:06:10 +0000
Subject: [issue32338] Save OrderedDict import in re
In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za>
Message-ID: <1520751970.81.0.467229070634.issue32338@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython 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/issue32338>
_______________________________________

From report at bugs.python.org  Sun Mar 11 03:30:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 07:30:16 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520753416.02.0.467229070634.issue33026@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 04aadf23eac51fec2e436c5960c1362bbb7d03de by Serhiy Storchaka in branch '3.7':
[3.7] bpo-33026: Fix jumping out of "with" block by setting f_lineno. (GH-6026). (#6074)
https://github.com/python/cpython/commit/04aadf23eac51fec2e436c5960c1362bbb7d03de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 03:31:22 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 07:31:22 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520753482.6.0.467229070634.issue33026@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5835

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 03:32:24 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 07:32:24 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520753544.0.0.467229070634.issue33026@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5836

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:21:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:21:15 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520756475.51.0.467229070634.issue33026@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 20ac11a9fb027f183914bbaaaed091b57c882e54 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-33026: Fix jumping out of "with" block by setting f_lineno. (GH-6026). (GH-6074) (GH-6075)
https://github.com/python/cpython/commit/20ac11a9fb027f183914bbaaaed091b57c882e54


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:52:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:52:41 +0000
Subject: [issue32946] Speed up import from non-packages
In-Reply-To: <1519548414.92.0.467229070634.issue32946@psf.upfronthosting.co.za>
Message-ID: <1520758361.93.0.467229070634.issue32946@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4e2442505c5e9eec396dcef4d2e6bdd2b6f92fc9 by Serhiy Storchaka in branch 'master':
bpo-32946: Speed up "from ... import ..." from non-packages. (GH-5873)
https://github.com/python/cpython/commit/4e2442505c5e9eec396dcef4d2e6bdd2b6f92fc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32946>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:54:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:54:49 +0000
Subject: [issue32925] AST optimizer: Change a list into tuple in iterations
 and containment tests
In-Reply-To: <1519422258.29.0.467229070634.issue32925@psf.upfronthosting.co.za>
Message-ID: <1520758489.67.0.467229070634.issue32925@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3f7e9aa2ef215917b9f1521441f67f4ecd33a1bc by Serhiy Storchaka in branch 'master':
bpo-32925: Optimized iterating and containing test for literal lists (GH-5842)
https://github.com/python/cpython/commit/3f7e9aa2ef215917b9f1521441f67f4ecd33a1bc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32925>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:56:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:56:01 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520758561.87.0.467229070634.issue33026@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3854f5885edc8dc67b1aba82fbb525604fbc625b by Serhiy Storchaka (Miss Islington (bot)) in branch '2.7':
[2.7] bpo-33026: Fix jumping out of "with" block by setting f_lineno. (GH-6026). (GH-6074) (GH-6076)
https://github.com/python/cpython/commit/3854f5885edc8dc67b1aba82fbb525604fbc625b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:56:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:56:24 +0000
Subject: [issue33026] Fix jumping out of "with" block
In-Reply-To: <1520495198.82.0.467229070634.issue33026@psf.upfronthosting.co.za>
Message-ID: <1520758584.98.0.467229070634.issue33026@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/issue33026>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:57:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:57:09 +0000
Subject: [issue32925] AST optimizer: Change a list into tuple in iterations
 and containment tests
In-Reply-To: <1519422258.29.0.467229070634.issue32925@psf.upfronthosting.co.za>
Message-ID: <1520758629.47.0.467229070634.issue32925@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/issue32925>
_______________________________________

From report at bugs.python.org  Sun Mar 11 04:58:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 08:58:13 +0000
Subject: [issue32946] Speed up import from non-packages
In-Reply-To: <1519548414.92.0.467229070634.issue32946@psf.upfronthosting.co.za>
Message-ID: <1520758693.77.0.467229070634.issue32946@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/issue32946>
_______________________________________

From report at bugs.python.org  Sun Mar 11 05:07:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 09:07:09 +0000
Subject: [issue32970] Improve disassembly of the MAKE_FUNCTION instruction
In-Reply-To: <1519835491.83.0.467229070634.issue32970@psf.upfronthosting.co.za>
Message-ID: <1520759229.08.0.467229070634.issue32970@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e2732d3e66eba9ec13f9d55c499f2437ead552db by Serhiy Storchaka in branch 'master':
bpo-32970: Improve disassembly of the MAKE_FUNCTION instruction. (GH-5937)
https://github.com/python/cpython/commit/e2732d3e66eba9ec13f9d55c499f2437ead552db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32970>
_______________________________________

From report at bugs.python.org  Sun Mar 11 05:07:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 09:07:42 +0000
Subject: [issue32970] Improve disassembly of the MAKE_FUNCTION instruction
In-Reply-To: <1519835491.83.0.467229070634.issue32970@psf.upfronthosting.co.za>
Message-ID: <1520759262.26.0.467229070634.issue32970@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/issue32970>
_______________________________________

From report at bugs.python.org  Sun Mar 11 05:22:55 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 11 Mar 2018 09:22:55 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1520760175.59.0.467229070634.issue12486@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

> Why not just bless the existing generate_tokens() function as a public API

We're actually using generate_tokens() from IPython - we wanted a way to tokenize unicode strings, and although it's undocumented, it's been there for a number of releases and does what we want. So +1 to promoting it to a public API.

In fact, at the moment, IPython has its own copy of tokenize to fix one or two old issues. I'm trying to get rid of that and use the stdlib module again, which is how I came to notice that we're using an undocumented API.

----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12486>
_______________________________________

From report at bugs.python.org  Sun Mar 11 06:14:06 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 11 Mar 2018 10:14:06 +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: <1520763246.4.0.467229070634.issue32576@psf.upfronthosting.co.za>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Well, according to the reporters disabling GC doesn't help at all. Maybe it's another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Sun Mar 11 06:21:00 2018
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 11 Mar 2018 10:21:00 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1520763660.54.0.467229070634.issue33016@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> pathlib currently expects DOS paths only: it will strip '\\?\' 
> prefix in resolve()

pathlib's unqualified conversion from the extended form to classic DOS form is a bug. The resolved path may be invalid as a classic DOS path. It may be too long, a DOS device name (e.g. "nul.txt"), or end with trailing spaces or dots (e.g. "spam."). 

Here's another pathlib bug with device paths:

    >>> print(pathlib.Path(r'\\.\C:'))
    \\.\C:\
    >>> print(pathlib.Path('//./CON'))
    \\.\CON\

In the first case, the input path is the "C:" volume device, but pathlib changes it to the file-system root directory. The second case is invalid in general, though some devices will ignore a remaining path.

As background, note that the Windows runtime library classifies paths into 6 types:

    >>> ntdll = ctypes.WinDLL('ntdll')
    >>> GetDosPathNameType = ntdll.RtlDetermineDosPathNameType_U

    UNC Absolute
    >>> GetDosPathNameType(r'\\eggs\spam')
    1

    Drive Absolute
    >>> GetDosPathNameType(r'C:\spam')
    2

    Drive Relative
    >>> GetDosPathNameType('C:spam')
    3

    Rooted
    >>> GetDosPathNameType(r'\spam')
    4

    Relative
    >>> GetDosPathNameType('spam')
    5

    Local Device
    >>> GetDosPathNameType(r'\\.\C:\spam')
    6
    >>> GetDosPathNameType(r'\\?\C:\spam')
    6

A local-device path is always absolute, so it's the only way to reference a volume device by a DOS drive letter. Without the prefix, "C:" is a drive-relative path.

If the prefix is exactly "\\\\?\\" (no forward slashes), then a local-device path is an extended path. This path type never gets normalized in any way, except to replace the WinAPI prefix with NTAPI "\\??\\". For all other local-device paths, the runtime library resolves "." and ".." components, translates forward slash to backslash, and strips trailing spaces and dots from the final component. Unlike DOS paths, local-device paths do not reserve DOS device names (e.g. "NUL" or "NUL:").

pathlib should never add a trailing slash to a local-device path. Also, the is_reserved() method needs to distinguish the DOS, device ("\\\\.\\"), and extended device ("\\\\?\\") namespaces.

> it would indeed be nice if pathlib handled [device] paths in its resolve()

I suggested handling volume GUID and device paths in _getfinalpathname, so it's not special-cased just in pathlib (e.g. if we were to implement ntpath.realpath). OTOH, pathlib's resolve() method should handle high-level mitigation, such as working around bad links and permission errors in non-strict mode.

> I erroneously stated that the length of the path could increase 
> between GetFinalPathNameByHandle calls because an intermediate
> directory could be renamed

The rules for the rename operation are discussed in the documentation for NtSetInformationFile, FileRenameInformation [1], and explained in detail in File Systems Algorithms, 2.1.5.14.11 FileRenameInformation [2].

[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/ns-ntifs-_file_rename_information
[2]: https://msdn.microsoft.com/en-us/library/ff469527

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33016>
_______________________________________

From report at bugs.python.org  Sun Mar 11 06:37:13 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 11 Mar 2018 10:37:13 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520764633.61.0.467229070634.issue17288@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Serhiy, I have updated the tests for using the jump_test() decorator and replied to your comment about RETURN_VALUE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Sun Mar 11 06:38:30 2018
From: report at bugs.python.org (Zac Medico)
Date: Sun, 11 Mar 2018 10:38:30 +0000
Subject: [issue22087] asyncio: support multiprocessing (support fork)
In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za>
Message-ID: <1520764710.74.0.467229070634.issue22087@psf.upfronthosting.co.za>


Change by Zac Medico <zmedico at gentoo.org>:


----------
nosy: +zmedico

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22087>
_______________________________________

From report at bugs.python.org  Sun Mar 11 06:51:55 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 10:51:55 +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: <1520765515.3.0.467229070634.issue32576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps the gemato issue has nothing to do with multiprocessing indeed.  I would suggest add some progress logging to your program to see whether/where it actually hangs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Sun Mar 11 06:59:32 2018
From: report at bugs.python.org (Ma Lin)
Date: Sun, 11 Mar 2018 10:59:32 +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: <1520765972.13.0.467229070634.issue32174@psf.upfronthosting.co.za>


Ma Lin <malincns at 163.com> added the comment:

Here is a solution:
1, open a page(whatever) with Internet Explorer.
2, right click the page -> Encoding -> check "Auto-Select"
Then the wrong characters (?/?) will disappear forever.

> Does anyone else see this problem?
Probably a lot of people have this problem.
I installed a clean Windows 10 recently, I believe it's the default visual effect of Python .chm document.
BTW my local is Simplified Chinese.

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32174>
_______________________________________

From report at bugs.python.org  Sun Mar 11 07:04:58 2018
From: report at bugs.python.org (Ma Lin)
Date: Sun, 11 Mar 2018 11:04:58 +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: <1520766298.19.0.467229070634.issue32174@psf.upfronthosting.co.za>


Change by Ma Lin <malincns at 163.com>:


Added file: https://bugs.python.org/file47476/screenshot.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32174>
_______________________________________

From report at bugs.python.org  Sun Mar 11 08:24:30 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Mar 2018 12:24:30 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520771070.71.0.467229070634.issue28788@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 09:14:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 13:14:01 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520774041.81.0.467229070634.issue28788@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is a problem with writing two lines of code?

    with open(...) as f:
        config.write(f)

If combine ConfigParser.write() with builtin open() you will need to add support of encoding, errors, buffering, newline, and other arguments supported by open(). And don't forgot to update this method after adding new parameters to open().

I'm -1. Not every two lines of code deserve including as a function in the stdlib. This will clutter the user interface, complicate the implementation, and add the burden to core developers for maintaining this code.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 09:52:31 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Mar 2018 13:52:31 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520776351.29.0.467229070634.issue28788@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

George, your third sentence is missing a closing ')' somewhere.  In the first part, I believe you meant that the user is able to create a bad file by directly writing other content or calling cf.write more than once.  I don't get the part about duplicated sections.

I was otherwise +-0 about the feature until Serhiy articulated the negatives.  I am now more inclined to close this.

I just reviewed the PR, and the added complications in the test mirror the added complication in the code. With the patch as is, we should document that if a filename is passed, it would be opened with default args other than the mode.

There are other filename or file APIs, but that does not mean that they are without problems.  I suspect that at least some date to times before the addition of with statements.

----------
nosy: +terry.reedy -serhiy.storchaka
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 10:57:23 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sun, 11 Mar 2018 14:57:23 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1520780243.93.0.467229070634.issue33034@psf.upfronthosting.co.za>


Change by Matt Eaton <agnosticdev at gmail.com>:


----------
keywords: +patch
pull_requests: +5837
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sun Mar 11 11:06:52 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sun, 11 Mar 2018 15:06:52 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1520780812.95.0.467229070634.issue33034@psf.upfronthosting.co.za>


Change by Matt Eaton <agnosticdev at gmail.com>:


----------
pull_requests: +5838

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sun Mar 11 11:07:15 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sun, 11 Mar 2018 15:07:15 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1520780835.18.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

I agree.  I think an explicit exception message would be appropriate when the cast fails to cast from string to int in int(post, 10).

Putting in a PR to fix this now.
https://github.com/python/cpython/pull/6078

----------
nosy: +agnosticdev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sun Mar 11 11:16:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Mar 2018 15:16:21 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520781381.23.0.467229070634.issue28788@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 11:32:24 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 15:32:24 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520782344.41.0.467229070634.issue28788@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I agree with Serhiy and Terry. Also, PR 5999 does not accept pathlib.Path() objects at the moment. This and Serhiy's following comment are good examples of why it shouldn't be added to the standard library in my opinion:

> If combine ConfigParser.write() with builtin open() you will need to
> add support of encoding, errors, buffering, newline, and other
> arguments supported by open(). And don't forgot to update this method
> after adding new parameters to open().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 11:42:34 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sun, 11 Mar 2018 15:42:34 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520782954.25.0.467229070634.issue28788@psf.upfronthosting.co.za>


Matej Cepl <mcepl at cepl.eu> added the comment:

OK, Serhiy you have the point: it was just a good exercise for me, but the benefit is doubtful. Could somebody close this ticket then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 11:47:25 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Mar 2018 15:47:25 +0000
Subject: [issue28788] ConfigParser should be able to write config to a given
 filename, not only into file object
In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za>
Message-ID: <1520783245.1.0.467229070634.issue28788@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28788>
_______________________________________

From report at bugs.python.org  Sun Mar 11 12:02:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 16:02:46 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520784166.83.0.467229070634.issue32996@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The most breaking change in 3.7 (according to the statistics of GitHub issues) is making async a keyword. But this change is even not mentioned in What's New.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sun Mar 11 13:19:59 2018
From: report at bugs.python.org (Adrien)
Date: Sun, 11 Mar 2018 17:19:59 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
Message-ID: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>


New submission from Adrien <delgan.py at gmail.com>:

Hello.

I am strangely encountering an error whil trying to run "python -m trace -c script.py" on this simple code:

> import multiprocessing
> queue = multiprocessing.Queue()
> queue.put("a")

Which raises on Windows 10 using Python 3.6.3:

> Traceback (most recent call last):
>   File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
>     "__main__", mod_spec)
>   File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
>     exec(code, run_globals)
>   File "/usr/lib/python3.6/trace.py", line 742, in <module>
>     main()
>   File "/usr/lib/python3.6/trace.py", line 739, in main
>     results.write_results(opts.missing, opts.summary, opts.coverdir)
>   File "/usr/lib/python3.6/trace.py", line 258, in write_results
>     for filename, lineno in self.counts:
> RuntimeError: dictionary changed size during iteration

Fixing it seems straightforward, but I do not know what is causing the bug internally.

----------
components: Library (Lib)
messages: 313604
nosy: Delgan
priority: normal
severity: normal
status: open
title: "RuntimeError: dictionary changed size during iteration" using trace.py module
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33047>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:06:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:06:33 +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: <1520791593.96.0.467229070634.issue31804@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +5840

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:12:42 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:12:42 +0000
Subject: [issue33048] macOS job broken on Travis CI
Message-ID: <1520791962.83.0.467229070634.issue33048@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Well, it didn't take long. The macOS job broke on Travis CI. Apparently "brew" thinks Python 2 and Python 3 are the same thing, so "brew install python3" now fails with an error message telling to use "brew upgrade" instead.  But it did work before...
https://travis-ci.org/python/cpython/jobs/352036713

This should be simple to fix, though I wonder whether this could be taken over by our macOS maintainers? :-)

----------
components: Build
messages: 313605
nosy: ned.deily, pitrou, ronaldoussoren
priority: normal
severity: normal
status: open
title: macOS job broken on Travis CI
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33048>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:15:55 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:15:55 +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: <1520792155.7.0.467229070634.issue31804@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
superseder: multiprocessing.Process depends on sys.stdout being open -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:16:31 2018
From: report at bugs.python.org (Trey Hunner)
Date: Sun, 11 Mar 2018 18:16:31 +0000
Subject: [issue33049] itertools.count() confusingly mentions zip() and
 sequence numbers
Message-ID: <1520792191.75.0.467229070634.issue33049@psf.upfronthosting.co.za>


New submission from Trey Hunner <trey at truthful.technology>:

>From the itertools documentation: https://docs.python.org/3/library/itertools.html?highlight=itertools#itertools.count

> Also, used with zip() to add sequence numbers.

I'm not certain what the goal of the original sentence was, but I think it's unclear as currently written.

I assume this is what's meant:

my_sequence = [1, 2, 3, 4]
for i, item in zip(count(1), my_sequence):
    print(i, item)

This is a strange thing to note though because enumerate would be a better use here.

my_sequence = [1, 2, 3, 4]
for i, item in enumerate(my_sequence, start=1):
    print(i, item)

Maybe what is meant is that count can be used with a step while enumerate cannot?

my_sequence = [1, 2, 3, 4]
for i, item in zip(count(step=5), my_sequence):
    print(i, item)

If that's the case it seems like step should instead be mentioned there instead of "sequence numbers".

----------
assignee: docs at python
components: Documentation
messages: 313606
nosy: docs at python, trey
priority: normal
severity: normal
status: open
title: itertools.count() confusingly mentions zip() and sequence numbers
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/issue33049>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:17:26 2018
From: report at bugs.python.org (Timothy VanSlyke)
Date: Sun, 11 Mar 2018 18:17:26 +0000
Subject: [issue33050] Centralized documentation of assumptions made by C code
Message-ID: <1520792246.5.0.467229070634.issue33050@psf.upfronthosting.co.za>


New submission from Timothy VanSlyke <vanslyke.t at husky.neu.edu>:

It would be nice for those who write C extensions to have a resource that explicitly states what assumptions are made by the CPython implementation that are otherwise implementation-defined in standard C.  

For example, Python versions >= 3.6 require:
- That UCHAR_MAX is defined to be 255 (from Python.h)
- That fixed-width intXX_t and uintXX_t types are provided in stdint.h and inttypes.h (from PEP7)

These two requirements also pretty much guarantee that CHAR_BIT == 8.  These kinds of things are nice to know for anybody working with the C API; we can make the same assumptions in our own code without having hunt through the API docs or the CPython source tree every time something comes up.

>From what I've found, there isn't any component of the documentation that explicitly lists these assumptions in one place (I apologize if there is and I somehow missed it...).  Could this be addressed in the future?  

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 313607
nosy: docs at python, tvanslyke
priority: normal
severity: normal
status: open
title: Centralized documentation of assumptions made by C code
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33050>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:21:40 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:21:40 +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: <1520792500.94.0.467229070634.issue31804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset e756f66c83786ee82f5f7d45931ae50a6931dd7f by Antoine Pitrou in branch 'master':
bpo-31804: Fix multiprocessing.Process with broken standard streams (#6079)
https://github.com/python/cpython/commit/e756f66c83786ee82f5f7d45931ae50a6931dd7f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:24:19 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 11 Mar 2018 18:24:19 +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: <1520792659.86.0.467229070634.issue31804@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5841

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:28:17 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:28:17 +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: <1520792897.8.0.467229070634.issue31804@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +5842

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:28:55 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Mar 2018 18:28:55 +0000
Subject: [issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and
 difflib (CVE-2018-1061)
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520792935.46.0.467229070634.issue32981@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 942cc04ae44825ea120e3a19a80c9b348b8194d0 by larryhastings (Ned Deily) in branch '3.4':
[3.4] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6035)
https://github.com/python/cpython/commit/942cc04ae44825ea120e3a19a80c9b348b8194d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32981>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:29:08 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Mar 2018 18:29:08 +0000
Subject: [issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and
 difflib (CVE-2018-1061)
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520792948.05.0.467229070634.issue32981@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 937ac1fe069a4dc8471dff205f553d82e724015b by larryhastings (Ned Deily) in branch '3.5':
[3.5] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6034)
https://github.com/python/cpython/commit/937ac1fe069a4dc8471dff205f553d82e724015b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32981>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:29:43 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Mar 2018 18:29:43 +0000
Subject: [issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and
 difflib (CVE-2018-1061)
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1520792983.03.0.467229070634.issue32981@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Is this ready to close?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32981>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:35:42 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:35:42 +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: <1520793342.15.0.467229070634.issue31804@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.8 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:37:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Mar 2018 18:37:59 +0000
Subject: [issue33049] itertools.count() confusingly mentions zip() and
 sequence numbers
In-Reply-To: <1520792191.75.0.467229070634.issue33049@psf.upfronthosting.co.za>
Message-ID: <1520793479.01.0.467229070634.issue33049@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For example zip(my_sequence, count(1)).

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33049>
_______________________________________

From report at bugs.python.org  Sun Mar 11 14:42:40 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 18:42:40 +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: <1520793760.08.0.467229070634.issue31804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset ff5d21331ec6cefec6ba5b78d256d8dbcd67a069 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
bpo-31804: Fix multiprocessing.Process with broken standard streams (GH-6079) (GH-6080)
https://github.com/python/cpython/commit/ff5d21331ec6cefec6ba5b78d256d8dbcd67a069


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:04:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Mar 2018 19:04:13 +0000
Subject: [issue33048] macOS job broken on Travis CI
In-Reply-To: <1520791962.83.0.467229070634.issue33048@psf.upfronthosting.co.za>
Message-ID: <1520795053.49.0.467229070634.issue33048@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> This should be simple to fix, though I wonder whether this could be taken over by our macOS maintainers? :-)

I'm not sure what you mean by *this*.  If it's the Travis configuration, I don't use Homebrew myself and I have little experience with Travis or with our current configuration.  I have seen that the Homebrew project recently changed their defaults so that "python" pointed to "python3" and, because of pushback, have changed some things (see https://docs.brew.sh/Homebrew-and-Python.html).  I also see the pre-revert of our .travis.yaml did not try to install the brew python3 (https://github.com/python/cpython/pull/3367/files).  Perhaps someone more familiar with both can take a quick look.  I'm really busy with other things right now.

----------
nosy: +brett.cannon, zach.ware -ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33048>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:08:00 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 19:08:00 +0000
Subject: [issue33048] macOS job broken on Travis CI
In-Reply-To: <1520791962.83.0.467229070634.issue33048@psf.upfronthosting.co.za>
Message-ID: <1520795280.73.0.467229070634.issue33048@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I meant that the Travis macOS configuration could indeed be maintained by macOS experts, indeed.

The alternative, IMHO, would be to declare that bugs in macOS can appear without the offending PR being reverted if it was submitted by a non-macOS developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33048>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:09:22 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 19:09:22 +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: <1520795362.62.0.467229070634.issue31804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 069b8d20be8018fbd49ed5aaf64c4caba311e48f by Antoine Pitrou in branch '3.6':
[3.6] bpo-31804: Fix multiprocessing.Process with broken standard streams (GH-6079) (GH-6081)
https://github.com/python/cpython/commit/069b8d20be8018fbd49ed5aaf64c4caba311e48f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:10:53 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 19:10: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: <1520795452.99.0.467229070634.issue31804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is all fixed in the Python 3 branches now.  I won't bother with Python 2 as it has quite a different code structure and backporting would take too much of my time.

Pox TheGreat, thanks for reporting and the initial patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:26:19 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 11 Mar 2018 19:26:19 +0000
Subject: [issue33051] IDLE: Create new tab for editor options in configdialog
Message-ID: <1520796379.91.0.467229070634.issue33051@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

Split out editor options from general tab in Config Dialog.

----------
assignee: terry.reedy
components: IDLE
messages: 313618
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Create new tab for editor options in configdialog
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33051>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:28:39 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Mar 2018 19:28:39 +0000
Subject: [issue32971] Docs on unittest.TestCase.assertRaises() should clarify
 context manager details
In-Reply-To: <1519840682.18.0.467229070634.issue32971@psf.upfronthosting.co.za>
Message-ID: <1520796519.31.0.467229070634.issue32971@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The implementation is literally that no non-keyword arguments other than the exception are given.  If any keyword arguments other than msg are given, you get a warning. To say just "no callable" would be about as confusing as the 'and possibly' given the documented prototype, since in fact any non-keyword argument will be assumed to be the callable. So the text is correct as written, and I'm not sure how one would make it clearer and still be technically correct.  But further suggestions are welcome.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32971>
_______________________________________

From report at bugs.python.org  Sun Mar 11 15:32:18 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 11 Mar 2018 19:32:18 +0000
Subject: [issue33051] IDLE: Create new tab for editor options in configdialog
In-Reply-To: <1520796379.91.0.467229070634.issue33051@psf.upfronthosting.co.za>
Message-ID: <1520796738.44.0.467229070634.issue33051@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5843
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33051>
_______________________________________

From report at bugs.python.org  Sun Mar 11 16:26:27 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 11 Mar 2018 20:26:27 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520799987.03.0.467229070634.issue32996@psf.upfronthosting.co.za>


bbayles <bbayles at gmail.com> added the comment:

Two things I'm familiar with that should probably be mentioned in the Library updates:

* bpo-32102: New argument capture_output for subprocess.run
* bpo-21417: Added support for setting the compression level for zipfile.ZipFile.

----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sun Mar 11 17:23:51 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 21:23:51 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520803431.04.0.467229070634.issue33023@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts.

What would those side-effects be?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sun Mar 11 17:24:04 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 21:24:04 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520803444.81.0.467229070634.issue33023@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sun Mar 11 17:29:49 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Mar 2018 21:29:49 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1520803789.91.0.467229070634.issue32996@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the comments here.  As noted by Yury in PR 5983:  "Looks good. Keep in mind that @elprans and I will edit what's new (as we did for 3.5 & 3.6) closer to 3.7 release."

----------
nosy: +Elvis.Pranskevichus, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sun Mar 11 17:32:59 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 21:32:59 +0000
Subject: [issue33052] Sporadic segmentation fault in test_datetime
Message-ID: <1520803979.78.0.467229070634.issue33052@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Just spotted this in a Travis-CI job:
https://travis-ci.org/python/cpython/jobs/351010039#L2002

I'm not sure there's anything to do but I figured it was worth reporting anyway.

----------
components: Library (Lib), Tests
messages: 313623
nosy: belopolsky, pitrou
priority: normal
severity: normal
status: open
title: Sporadic segmentation fault in test_datetime
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33052>
_______________________________________

From report at bugs.python.org  Sun Mar 11 17:42:35 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Mar 2018 21:42:35 +0000
Subject: [issue32337] Dict order is now guaranteed, so add tests and doc for it
In-Reply-To: <1514287514.34.0.213398074469.issue32337@psf.upfronthosting.co.za>
Message-ID: <1520804555.61.0.467229070634.issue32337@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Raymond, do you want to review the current state of the PR before 3.7.0b4?  Otherwise, I'll probably ask that it be merged as is.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32337>
_______________________________________

From report at bugs.python.org  Sun Mar 11 18:20:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Mar 2018 22:20:58 +0000
Subject: [issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64)
 architecture
In-Reply-To: <1489413054.1.0.4012026352.issue29804@psf.upfronthosting.co.za>
Message-ID: <1520806858.72.0.467229070634.issue29804@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

OK, PR 1559 (in 3.7.0) for Issue30353 has been backported to 3.6 in PR 5954 for release in 3.6.5.  So based on msg312200, I'm going to assume the problem is no longer reproducible in 3.6 and close this issue.  If not, please reopen.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29804>
_______________________________________

From report at bugs.python.org  Sun Mar 11 18:55:17 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 11 Mar 2018 22:55:17 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1520808917.85.0.467229070634.issue18802@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests: +5844

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Sun Mar 11 18:56:14 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 11 Mar 2018 22:56:14 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1520808974.52.0.467229070634.issue18802@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I've made a PR for Berker's patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Sun Mar 11 19:39:24 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Mar 2018 23:39:24 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1520811564.42.0.467229070634.issue33021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 4484f9dca9149da135bbae035f10a50d20d1cbbb by Antoine Pitrou (Nir Soffer) in branch 'master':
bpo-33021: Release the GIL during fstat() calls (GH-6019)
https://github.com/python/cpython/commit/4484f9dca9149da135bbae035f10a50d20d1cbbb


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Sun Mar 11 20:35:01 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 12 Mar 2018 00:35:01 +0000
Subject: [issue32993] urllib and webbrowser.open() can open w/ file: protocol
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520814901.81.0.467229070634.issue32993@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Hi Yao, I tend to agree with Ned. The support for ?file:? URLs is by design. I don?t see any security problems. I suggest to close this.

In Issue 11662, it was decided that a web server redirecting to a ?file:? URL was a security problem. This is because the mechanism that follows the redirect is automatic, and the target of the redirect is under the control of the remote server, not the local user or program. But other parts of the Python library still support ?file:? URLs without causing any problems. Those URLs are under control of the caller, like in your ?poc.py? file.

The /etc/passwd file may be readable by ordinary users. But /etc/shadow may require special permission to read, because it holds password hashes. Or it may not exist under that name, depending on the OS. If a web application calls ?urllib.request.urlopen?, I think it is up to the application to validate the URL it passes. It may want to deny or limit access to specific directories, URL schemes, host names, etc. It is not up to Python to make those decisions.

When I tried your ?webbrowser.open? demonstration, it made Firefox offer to ?download? (i.e. copy) the ?ls? executable file. I think this is normal behaviour, and does not indicate a security problem. A plausible use-case would be opening a local README.html file distributed with a program in a web browser.

----------
nosy: +martin.panter
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32993>
_______________________________________

From report at bugs.python.org  Sun Mar 11 20:42:44 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Mar 2018 00:42:44 +0000
Subject: [issue32982] Parse out invisible Unicode characters?
In-Reply-To: <1519970690.52.0.467229070634.issue32982@psf.upfronthosting.co.za>
Message-ID: <1520815364.44.0.467229070634.issue32982@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think it sounds like a good idea to put the printed representation as a repered string, followed by the code point representation in parenthesis, in that message after "invalid character".

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32982>
_______________________________________

From report at bugs.python.org  Sun Mar 11 20:49:50 2018
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Mar 2018 00:49:50 +0000
Subject: [issue32985] subprocess.Popen: Confusing documentation for
 restore_signals
In-Reply-To: <1520011885.85.0.467229070634.issue32985@psf.upfronthosting.co.za>
Message-ID: <1520815790.79.0.467229070634.issue32985@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, I imagine the original author thought of "python" as python itself, not the user's python program.  That's certainly how I understood it when I read it in your message.  It would not be a bad thing to clarify that, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32985>
_______________________________________

From report at bugs.python.org  Sun Mar 11 21:32:52 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Mar 2018 01:32:52 +0000
Subject: [issue32993] urllib and webbrowser.open() can open w/ file: protocol
In-Reply-To: <1520168712.39.0.467229070634.issue32993@psf.upfronthosting.co.za>
Message-ID: <1520818372.15.0.467229070634.issue32993@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
stage:  -> resolved
status: pending -> closed
type: security -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32993>
_______________________________________

From report at bugs.python.org  Sun Mar 11 23:45:55 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Mar 2018 03:45:55 +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: <1520826355.28.0.467229070634.issue32719@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Looks to me it's because the KeyboardInterrupt breaks `_wait_for_thread_shutdown` and reproduces the situation in #23309. @Antonie, do you think anything worth to improve here? Otherwise I'll take this as design.

----------
nosy: +pitrou
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 00:08:21 2018
From: report at bugs.python.org (Diego Argueta)
Date: Mon, 12 Mar 2018 04:08:21 +0000
Subject: [issue33038] GzipFile doesn't always ignore None as filename
In-Reply-To: <1520642770.84.0.467229070634.issue33038@psf.upfronthosting.co.za>
Message-ID: <1520827701.93.0.467229070634.issue33038@psf.upfronthosting.co.za>


Diego Argueta <diego.argueta at gmail.com> added the comment:

Yeah that's fine. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33038>
_______________________________________

From report at bugs.python.org  Mon Mar 12 01:07:35 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Mar 2018 05:07:35 +0000
Subject: [issue33049] itertools.count() confusingly mentions zip() and
 sequence numbers
In-Reply-To: <1520792191.75.0.467229070634.issue33049@psf.upfronthosting.co.za>
Message-ID: <1520831255.74.0.467229070634.issue33049@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> This is a strange thing to note though because enumerate 
> would be a better use here.

IIRC, the wording predates the addition of enumerate() and before enumerate() grew a *start* argument.  That said, enumerate() just addresses care the most common case.  It is still worth mentioning that count() is still useful for the general case of adding sequence numbers to data streams woven together by zip() -- like the way auto-increment is used in SQL:

    from time import ctime

    def timestamp():
        while True:
            yield ctime()
           
    def user_request():
        while True:
            yield input()
     
    logged_requests = zip(user_request(), count(1), timestamp(), cycle(available_servers))

> it seems like step should instead be mentioned there
> instead of "sequence numbers".

The *step* argument was a late addition to the API and isn't used much in practice.  When it is used, its meaning and use case tend to be self-evident (i.e. counting 60 seconds at a time, or counting backwards), so it doesn't warrant further elaboration.

The sentence as-is is imperfect (it makes you wonder why not just use enumerate) but it seems better than either saying less by not mentioning the use case or getting too wordy which would place too much emphasis on use cases less common that those served by enumerate().  So, my preference is to leave the sentence as it stands.  The intent of the two sentences mentioning map() and zip() was to hint at the possibilities while still keeping the paragraph primary focused on what count() actually does.

----------
assignee: docs at python -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33049>
_______________________________________

From report at bugs.python.org  Mon Mar 12 02:29:39 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Mar 2018 06:29:39 +0000
Subject: [issue33050] Centralized documentation of assumptions made by C code
In-Reply-To: <1520792246.5.0.467229070634.issue33050@psf.upfronthosting.co.za>
Message-ID: <1520836179.51.0.467229070634.issue33050@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

In general, we try to confine ourselves to C99 aside from widely supported extensions like intXX_t (no one wants to go around writing int_least32_t).

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33050>
_______________________________________

From report at bugs.python.org  Mon Mar 12 03:05:44 2018
From: report at bugs.python.org (Lele Gaifax)
Date: Mon, 12 Mar 2018 07:05:44 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1520838344.54.0.467229070634.issue27645@psf.upfronthosting.co.za>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

Sorry, I could not find an easy enough way to compile against SQLite 3.8.7.1, being on Debian sid myself (3.22). I hope to find some time to try harder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Mon Mar 12 05:20:43 2018
From: report at bugs.python.org (TitanSnow)
Date: Mon, 12 Mar 2018 09:20:43 +0000
Subject: [issue33040] Make itertools.islice supports negative values for start
 and stop arguments for sized iterable object
In-Reply-To: <1520673526.96.0.467229070634.issue33040@psf.upfronthosting.co.za>
Message-ID: <1520846443.21.0.467229070634.issue33040@psf.upfronthosting.co.za>


TitanSnow <tttnns1024 at gmail.com> added the comment:

Now I have thought about it and realized that
it's not suitable for islice.
But there's still a common use case to
drop some elements from the beginning or
ending of a iterable, which is also a main
reason why I wanted islice to support
negative values of start and stop.
So how about adding two functions
``drop_first`` and ``drop_last``
to do such things. They can be implemented
like this, in which way they support
arbitrary iterators::

    def drop_first(iterable, n=1):
        for _ in range(n):
            next(iterable)
        for e in iterable:
            yield e

    def drop_last(iterable, n=1):
        dq = deque()
        for _ in range(n):
            dq.append(next(iterable))
        for e in iterable:
            dq.append(e)
            yield dq.popleft()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33040>
_______________________________________

From report at bugs.python.org  Mon Mar 12 05:29:17 2018
From: report at bugs.python.org (Ma Lin)
Date: Mon, 12 Mar 2018 09:29:17 +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: <1520846957.86.0.467229070634.issue32174@psf.upfronthosting.co.za>


Ma Lin <malincns at 163.com> added the comment:

The source code of .chm changed between 3.6.2 and 3.6.3, the former uses escaped html entities.
I couldn't find out which commit caused this change.

3.6.2 chm: <h1>What&#8217;s New In Python 3.6</h1>
3.6.3 chm: <h1>What? New In Python 3.6</h1>

3.6.2 chm: <h2>Summary &#8211; Release highlights</h2>
3.6.3 chm: <h2>Summary ?Release highlights</h2>

Release date:
3.6.2 final: 2017-07-17
3.6.3 final: 2017-10-03

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32174>
_______________________________________

From report at bugs.python.org  Mon Mar 12 07:30:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 11:30:54 +0000
Subject: [issue32489] Allow 'continue' in 'finally' clause
In-Reply-To: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>
Message-ID: <1520854254.03.0.467229070634.issue32489@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If there are no objections I'll merge this PR soon.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32489>
_______________________________________

From report at bugs.python.org  Mon Mar 12 07:42:28 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 12 Mar 2018 11:42:28 +0000
Subject: [issue22102] Zipfile generates Zipfile error in zip with 0 total
 number of disk in Zip64 end of central directory locator
In-Reply-To: <1406670130.27.0.606950005482.issue22102@psf.upfronthosting.co.za>
Message-ID: <1520854948.1.0.467229070634.issue22102@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

Do you know what tool created the zip file? I can't find anything in the spec (https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT ) to say whether 0 is a valid value for the number of disks.

----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22102>
_______________________________________

From report at bugs.python.org  Mon Mar 12 07:54:20 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 11:54:20 +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: <1520855660.86.0.467229070634.issue32719@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, I don't think this can be fixed in an easy way. Let's say that users will have to live with that.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 07:57:15 2018
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 12 Mar 2018 11:57:15 +0000
Subject: [issue33053] Running a module with `-m` will add empty directory to
 sys.path
Message-ID: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>


New submission from Antti Haapala <antti at haapala.name>:

I think this is a really stupid security bug. Running a module with `-mmodule` seems to add '' as a path in sys.path, and in front. This is doubly wrong, because '' will stand for whatever the current working directory might happen to be at the time of the *subsequent import statements*, i.e. it is far worse than https://bugs.python.org/issue16202

I.e. whereas python3 /usr/lib/module.py wouldn't do that, python3 -mmodule would make it so that following a chdirs in code, imports would be executed from arbitrary locations. Verified on MacOS X, Ubuntu 17.10, using variety of Python versions up to 3.7.

----------
components: Interpreter Core
messages: 313641
nosy: ztane
priority: normal
severity: normal
status: open
title: Running a module with `-m` will add empty directory to sys.path
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Mon Mar 12 08:08:12 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 12 Mar 2018 12:08:12 +0000
Subject: [issue22102] Zipfile generates Zipfile error in zip with 0 total
 number of disk in Zip64 end of central directory locator
In-Reply-To: <1406670130.27.0.606950005482.issue22102@psf.upfronthosting.co.za>
Message-ID: <1520856492.76.0.467229070634.issue22102@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

I found source code for some other projects handling the same data. They all seem to agree that it should be 1:

- Golang's zip reading code: https://github.com/golang/go/blob/f7ac70a56604033e2b1abc921d3f0f6afc85a7b3/src/archive/zip/reader.go#L536-L538
- A C contrib file with zlib: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/minizip/zip.c#L620-L624
- Code from Info-ZIP, which is used by many Linux distros, is a bit less clear, but it has an illuminating comment:

    if ((G.ecrec.number_this_disk != 0xFFFF) &&
        (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
      /* Note: For some unknown reason, the developers at PKWARE decided to
         store the "zip64 total disks" value as a counter starting from 1,
         whereas all other "split/span volume" related fields use 0-based
         volume numbers. Sigh... */

So I think you've got an invalid zip file. If it's otherwise valid, there might be a case for Python tolerating that particular mistake. But it's probably better to fix whatever is making the incorrect zip file, because other tools are also going to reject it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22102>
_______________________________________

From report at bugs.python.org  Mon Mar 12 08:28:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Mar 2018 12:28:27 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1520857707.85.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I don't think we made any start-up changes that were specific to PySys_AddWarnOption, so my suspicion is that the crash is going to be related to a change in the constraints on either the unicode object creation or the list append operation.

The attached patch adds a new test case (I also cleaned up several other details related to test_embed execution in order to more easily see where the segfault happens on failure).

Unfortunately, it isn't yet suitable for use with `git bisect`, as I checked 3.7.0a3 (the earliest tag where the patch applied cleanly), and that commit also segfaults. So setting up for git bisect testing (as per the hot-fix example in https://git-scm.com/docs/git-bisect#_examples ) will require:

* checking the commit where "test_embed.py" was extracted from "test_capi.py" and seeing whether or not that segfaults
* if it *doesn't* segfault, git bisect between there and v3.7.0a3
* if it *does* segfault, make a revised test patch that applies cleanly to early versions, and then go back through the 3.7.0 pre-releases to find one that works

----------
keywords: +patch
nosy: +ncoghlan
Added file: https://bugs.python.org/file47477/bpo-33042-test-case.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 12 08:28:53 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Mar 2018 12:28:53 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1520857733.68.0.467229070634.issue33042@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/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 12 08:55:57 2018
From: report at bugs.python.org (Eric Dujardin)
Date: Mon, 12 Mar 2018 12:55:57 +0000
Subject: [issue29712] --enable-optimizations does not work with --enable-shared
In-Reply-To: <1488555923.14.0.550158164587.issue29712@psf.upfronthosting.co.za>
Message-ID: <1520859357.21.0.467229070634.issue29712@psf.upfronthosting.co.za>


Eric Dujardin <eric.dujardin at laposte.net> added the comment:

I have the same error when building 3.6.4, however not exactly with the same options. Some context first:
$ lsb_release -d; lscpu |head -1
Description:        Ubuntu 14.04.5 LTS
Architecture:          x86_64
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4

I'm careful to start from a freshly untarred source tree. 

This configuration builds a working installation:
$ ./configure --prefix=$PYTHON --enable-optimizations --enable-shared LDFLAGS="-Wl,-rpath=$PYTHON/lib -Wl,-Bsymbolic-functions -Wl,-z,relro" --with-computed-gotos --with-system-ffi --with-fpectl --with-system-libmpdec
$ make profile-opt

However, I get the reported error when CFLAGS="-mtune=core-avx2  -march=core-avx2" is added. 

This set of options works fine without --enable-shared, i.e. this is what I am using for static builds:
$ ./configure --prefix=$PYTHON --enable-optimizations LDFLAGS="-Wl,-z,relro" --with-computed-gotos --with-system-ffi --with-fpectl --with-system-libmpdec CFLAGS="-mtune=core-avx2 -march=core-avx2 -Wformat -Werror=format-security"

Note, with the following configuration (-mtune without -march), compilation just blocks on Objects/memoryobject.c (ie, gcc never completes):
$ ./configure --prefix=$PYTHON --enable-optimizations --enable-shared LDFLAGS="-Wl,-rpath=$PYTHON/lib -Wl,-Bsymbolic-functions -Wl,-z,relro" --with-computed-gotos --with-system-ffi --with-fpectl --with-system-libmpdec CFLAGS="-mtune=core-avx2  -Werror=format-security"
$ make profile-opt

----------
nosy: +eric957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29712>
_______________________________________

From report at bugs.python.org  Mon Mar 12 08:59:00 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Mar 2018 12:59:00 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520859540.3.0.467229070634.issue26680@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One quibble with Raymond's response:

> 2) Your use case is trivially solved in a portable, trivial, and readable > way:
> 
>    a == int(a)

For Decimal, I'd recommend using `a == a.to_integral_value()` instead. Using  `a == int(a)` will be inefficient if `a` has large exponent, so it's not a good general-purpose solution (though it's probably good enough in most real-world cases).

Here's an extreme example:

    In [1]: import decimal
    In [2]: x = decimal.Decimal('1e99999')
    In [3]: %timeit x == int(x)
    1.42 s ? 6.27 ms per loop (mean ? std. dev. of 7 runs, 1 loop each)
    In [4]: %timeit x == x.to_integral_value()
    230 ns ? 2.03 ns per loop (mean ? std. dev. of 7 runs, 1000000 loops each)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 08:59:11 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Mon, 12 Mar 2018 12:59:11 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1520859551.0.0.467229070634.issue33018@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

I'll share the use case that prompted me to submit this PR in the first place.

I am the author of bidict (https://pypi.python.org/pypi/bidict), which provides a bidirectional dict class. A bidict is just like a dict, except it automatically maintains its inverse bidict, which is accessible via its .inv attribute. To prevent a bidict and its inverse from creating a strong reference cycle, a weak ref is used to store the reference one direction.

bidicts implement my BidirectionalMapping ABC, which extends collections.abc.Mapping to include the .inv abstractproperty. BidirectionalMapping overrides __subclasshook__ so that outside implementations that don't subclass it explicitly may still be considered subclasses.

Recently, I tried something like `issublass('foo', BidirectionalMapping)`, and got the "cannot create weak reference to 'str' object" error. Because this error message differs from the (much more helpful) "arg 1 must be a class" error message that you get when you do e.g. `issubclass('foo', Mapping)`, I thought there might be a bug somewhere in my code. Then I looked deeper and found where this is really coming from.

I experimented more and noticed that `issubclass('foo', Reversible)` raises AttributeError, which isn't even the same type of error.

The exceptions that are raised in these cases seem like an abstraction leak. The error messages do not help users immediately realize what they did wrong and how they can fix it; more knowledge of internals is required to make sense of what's going on than should be needed. The inconsistency in these errors is a further problem. The same mistake should not cause three different errors unless there is some really good reason. This seems unintentional. Can any of the original authors say whether this is working as intended or if this is in fact an oversight?

The current behavior causes confusion for both less experienced and more experienced Python users alike. (Would anyone else here have correctly predicted all of the different errors that the examples above cause? How many other Python experts could have?) For less experienced users, Python's general consistency and predictability, lack of gotchas, and good errors are some of its best features. This is such an exception that it seems like a bug.

I'm happy for some other patch than the one I submitted in https://github.com/python/cpython/pull/5944 to land if necessary, as long as something fixes this. And fwiw, +1 for 3.7, unless anyone can demonstrate any credible risk.

Thanks for your consideration :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Mon Mar 12 09:03:01 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Mar 2018 13:03:01 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1520859781.41.0.467229070634.issue26701@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

With both Eric's and Serhiy's updates merged, and issue 33039 broken out for the __index__ oddities, this is resolved now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26701>
_______________________________________

From report at bugs.python.org  Mon Mar 12 09:12:55 2018
From: report at bugs.python.org (Kenneth Chik)
Date: Mon, 12 Mar 2018 13:12:55 +0000
Subject: [issue33054] unittest blocks when testing function using
 multiprocessing.Pool with state spawn
Message-ID: <1520860375.4.0.467229070634.issue33054@psf.upfronthosting.co.za>


New submission from Kenneth Chik <tarotcard at gmail.com>:

I am not sure if this is python or OS problem, I just installed Ubuntu 18.04 LTS which comes with python3 v3.6.4. When I try to unittest code which contains multiprocessing.Pool with spawn, the unittest.main() blocks after completing all the tests. This problem did not exist on prior versions of Ubuntu/Python. Below is the printout after I KeyboardInterrupt the process.


...
----------------------------------------------------------------------
Ran 13 tests in 10.472s

OK
^CException ignored in: <module 'threading' from '/usr/lib/python3.6/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 1294, in _shutdown
    t.join()
  File "/usr/lib/python3.6/threading.py", line 1056, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.6/threading.py", line 1072, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt

The spawned processes have all completed and not visible on the process list, but the semaphore_tracker process is still there. This is the same with previous working system though. Thanks.

----------
messages: 313648
nosy: Kenneth Chik
priority: normal
severity: normal
status: open
title: unittest blocks when testing function using multiprocessing.Pool with state spawn
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33054>
_______________________________________

From report at bugs.python.org  Mon Mar 12 09:33:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Mar 2018 13:33:23 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1520861603.18.0.467229070634.issue33042@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Python documentation was enhanced in Python 3.7 to explicitly list all functions safe to call *before* Py_Initialize():

https://docs.python.org/dev/c-api/init.html#before-python-initialization

PySys_AddWarnOption() is not part of the list. While it's not in the list, I'm kind of unhappy that we broke your use case: it wasn't my intent. Because I broken your use case with this change part of the big bpo-32030 refactoring:

commit f7e5b56c37eb859e225e886c79c5d742c567ee95
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Wed Nov 15 15:48:08 2017 -0800

    bpo-32030: Split Py_Main() into subfunctions (#4399)

IHMO the regression is that PySys_AddWarnOption() now calls _PySys_GetObjectId(): in Python 3.6, it wasn't the case.

Python 3.6 code:
---
void
PySys_AddWarnOptionUnicode(PyObject *unicode)
{
    if (warnoptions == NULL || !PyList_Check(warnoptions)) {
        Py_XDECREF(warnoptions);
        warnoptions = PyList_New(0);
        if (warnoptions == NULL)
            return;
    }
    PyList_Append(warnoptions, unicode);
}
---

Again, it's a bad idea to use the Python API before Py_Initialize(): you likely have to build a Unicode string and you use a list, whereas these two object types are not properly initialized...

The PEP 432 and bpo-32030 prepared Python to have a much better API in Python 3.8 for embedding Python. You will be able to use a wchar_t* string to pass warning options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 12 09:42:57 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 13:42:57 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520862177.38.0.467229070634.issue22674@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 09:43:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 13:43:19 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520862199.76.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is now pushed.  Thank you Antoine!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 10:02:34 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Mar 2018 14:02:34 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1520863354.29.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Adding a bit of context from my prior email discussion with Hartmut: CPython actually reads sys.warnoptions at the end of Py_Initialize (its the last thing we do before the function returns).

It also reads sys._xoptions during startup, since that's one way of enabling settings like dev mode and UTF-8 mode.

That means that even though PySys_AddWarnOption and PySys_AddXOption weren't documented as being safe to call before Py_Initialize, they likely *won't* have the desired effect if an embedding application defers calling them until later, and their absence from the list of "safe to call before Py_Initialize" functions was itself a documentation bug.

For 3.8, I'd hoped that the resolution might be as simple as a hard requirement on embedding applications to call PyRuntime_Initialize() before doing *anything* with the C API, but including the "internal/pystate.h" header and adding a call to _PyRuntime_Initialize() wasn't enough to keep the draft test case in my patch from segfaulting :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 12 10:18:32 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 14:18:32 +0000
Subject: [issue32608] Incompatibilities with the socketserver and
 multiprocessing packages
In-Reply-To: <1516539327.3.0.467229070634.issue32608@psf.upfronthosting.co.za>
Message-ID: <1520864312.53.0.467229070634.issue32608@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi Michael, sorry for the silence on this issue.  I think the ProcessingMixIn feature is a good idea, I'll give the PR a review when I get the time.

----------
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/issue32608>
_______________________________________

From report at bugs.python.org  Mon Mar 12 10:28:02 2018
From: report at bugs.python.org (FHTMitchell)
Date: Mon, 12 Mar 2018 14:28:02 +0000
Subject: [issue33055] bytes does not implement __bytes__()
Message-ID: <1520864882.07.0.467229070634.issue33055@psf.upfronthosting.co.za>


New submission from FHTMitchell <fergus.htm at gmail.com>:

Every object which has a corresponding dunder protocol also implements said protocol with one exception:


>>> 'hello'.__str__()
'hello'

>>> (3.14).__float__()
3.14

>>> (101).__int__()
101

>>> True.__bool__()
True

>>> iter(range(10)).__iter__()
<range_iterator at 0xf6b08b0>

>>> b'hello'.__bytes__()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
----> 1 b'hello'.__bytes__()

AttributeError: 'bytes' object has no attribute '__bytes__'

This was brought up on SO as being inconsistent: https://stackoverflow.com/questions/49236655/bytes-doesnt-have-bytes-method/49237034?noredirect=1#comment85477673_49237034

----------
components: Interpreter Core
messages: 313653
nosy: FHTMitchell
priority: normal
severity: normal
status: open
title: bytes does not implement __bytes__()
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33055>
_______________________________________

From report at bugs.python.org  Mon Mar 12 10:42:44 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Mon, 12 Mar 2018 14:42:44 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1520744283.02.0.467229070634.issue26680@psf.upfronthosting.co.za>
Message-ID: <CAHYrD20Hn_NkgiW2kSo0Ht8duGia0wHRFdeC7Su=iRuDpKv-vw@mail.gmail.com>


Robert Smallshire <rob at sixty-north.com> added the comment:

To respond to Raymond's points:

1) Nobody is suggesting that every float method should also be available on
int.  Clearly some methods on float are not applicable to int.

2) Taken narrowly, you're right that is_integer() does nothing useful for
int.  Neither do imag, denominator, __floor__, or __trunc__. They're all
present so we can successfully use integers in duck-typing situations along
with the other number types. My claim is that int.is_integer() is useful
for the same reasons.

The problem isn't that you or I don't know that we should write a == int(a)
to be portable, the problem is that code that *already* uses x.is_integer()
fails hard when x happens to be an int. As I've demonstrated, some built-in
operators and functions can return either int or float, even when the
operand types are all int, depending only on the *values* of the operands.

This wouldn't matter if nobody ever wrote f.is_integer(), and instead used
the trivially portable solution, but they do, and at your behest: In 2011
you published "f.is_integer() is the new way to test whether a float is
integral. The old way, x==int(x), is history."  The reality is that folks
often write Python functions which accept *numbers*, without giving too
much thought to whether calling my_func(42.0) will work, but my_func(42)
will cause an unhandled exception that nobody is expecting. Indeed, one of
the joys of Python is that we often don't need to overthink this.

The trivial portable solution is also nearly three times slower than
float.is_integer() and int.is_integer(). Moreso if you package it up in a
function so it can be applied to more complex expressions in, say, a
comprehension, where an intermediate assignment is not possible.

I'm not the only person to be thrown by this. See this:

    is_integer() not working: https://stackoverflow.com/
questions/17170226/is-integer-not-working/17170511

and this:

   https://www.reddit.com/r/learnpython/comments/4tp4hy/
need_help_with_identify_number_as_integer/

and this

    https://wiesmann.codiferes.net/wordpress/?p=13366

Furthermore, once the is_integer() method is discovered, it leads to folks
writing odd code in order to leverage it, such as always converting user
integer input to float in order to check that it's really is an integer
(which of course subtly limits the precision of allowable integers).
There's an example of this on page 14 of the book *Doing Math With Python*.
https://www.amazon.com/Doing-Math-Python-Programming-Statistics/dp/1593276400

Other prolific and widely respected Python programmers have described this
behaviour as "kind of nuts" (though I'm not going to involve them here).
The behaviour has also invited unfortunate comparisons with similar
non-obvious behaviour in Javascript.

3) I'd be very surprised if the presence of this method on int caused any
more confusion, or impediment to learning than do the presence of int.imag
or int.denominator.

4) I'm less bothered about the numeric tower aspect than I am about
duck-type compatibility between the built-in types int and float. That
said, a key part of what I think is your concern about creating work for
subclass implementers can be addressed by providing a default
implementation Real.is_integer() in terms of int(x) == x.

5) The decimal spec doesn't require an is_decimal function, but it doesn't
forbid it either. In any case, the Decimal implementation already
implements is_integer internally as `cpx_mpd_isinteger` ? and uses it a
great deal, which demonstrates its utility. My patch simply exposes it to
Python. There's no danger of violating any specification, unless that
specification says that you must not implement a method called is_integer,
which it doesn't, especially as we would be using a definition which is
already de facto compatible with the standard.  I don't care very much
about Decimal either for my own work, especially as it already stands apart
from the numeric tower. I implemented it to be consistent with my argument
about duck typed numbers (which still largely holds for Decimal, except for
floor division and modulus I believe).

Solutions for which use `a == int(a)` or `a == a.to_integral_value()` fail
for NaN and infinities, whereas float.is_integer() is more robust. It turns
out the trivial portable solution isn't so trivial, or so portable, if
implemented robustly, performantly and with duck-typing in mind.

Ultimately, my argument is one about duck typing across numbers types. If
if that abstraction isn't valued, I have nowhere to go.

*Robert Smallshire | *Managing Director
*Sixty North* | Applications | Consulting | Training
rob at sixty-north.com | T +47 63 01 04 44 | M +47 924 30 350
http://sixty-north.com

On 11 March 2018 at 05:58, Raymond Hettinger <report at bugs.python.org> wrote:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> Sorry Robert, but I object to this going forward.
>
> 1) We do not and should not require that every float() method also be in
> int():
>
>    >>> set(dir(float)) - set(dir(int))
>    {'fromhex', 'hex', 'is_integer', '__getformat__', '__setformat__',
>     'as_integer_ratio'}
>
> 2) Your use case is trivially solved in a portable, trivial, and readable
> way:
>
>    a == int(a)
>
> 3) I really don't want to clutter the other types with this method when it
> does nothing useful for those types.  In particular, I expect that the
> presence of "is_integer()" in the int() class will likely create more
> confusion than it solves (perhaps not for you, but for the vast majority of
> users, none of whom have ever requested this behavior over the entire
> history of the language).
>
> 4) Also, I don't what this to have to propagate to every project that ever
> registers their custom numeric types with the numeric tower.  Adding this
> method to the tower is essentially making a requirement that everyone,
> everywhere must add this method.   That is not in the spirit of what the
> ABCs are all about -- they mostly require a small and useful subset of the
> behaviors of the related concrete classes (i.e. the concrete collections
> all have more methods than are required by their collections.abc
> counterparts).
>
> 5) Lastly, the spirit of the decimal module was to stick as closely as
> possible to the decimal specification and assiduously avoid extending the
> spec with new inventions (risking duplication of functionality, risking
> non-portability with other implementations, risking not handling special
> values in a way that is consistent with the spec, risking our going down a
> path that intentionally not chosen by the spec creators, or risking being
> at odds with subsequent updates to the spec).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue26680>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 10:56:49 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Mon, 12 Mar 2018 14:56:49 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520866609.06.0.467229070634.issue26680@psf.upfronthosting.co.za>


Robert Smallshire <rob at sixty-north.com> added the comment:

Apologies for the email splurge. That's the first and last time I'll use the email interface to bugs.python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 11:09:15 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Mon, 12 Mar 2018 15:09:15 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
Message-ID: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>


New submission from Thomas Moreau <thomas.moreau.2010 at gmail.com>:

The recent changes introduced by https://github.com/python/cpython/pull/3895 leaks some file descriptors (the Pipe open in _ThreadWakeup).
They should be properly closed at shutdown.

----------
components: Library (Lib)
messages: 313656
nosy: tomMoral
priority: normal
pull_requests: 5845
severity: normal
status: open
title: LEaking files in concurrent.futures.process
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Mon Mar 12 11:24:21 2018
From: report at bugs.python.org (Guillaume Carre)
Date: Mon, 12 Mar 2018 15:24:21 +0000
Subject: [issue22102] Zipfile generates Zipfile error in zip with 0 total
 number of disk in Zip64 end of central directory locator
In-Reply-To: <1520856492.76.0.467229070634.issue22102@psf.upfronthosting.co.za>
Message-ID: <CAOZ3DuKQUbbQ8o0iZhkSsY+C0mLBo+_k7Y3G21H+bWYfAgwMgw@mail.gmail.com>


Guillaume Carre <gcarre20 at gmail.com> added the comment:

Hi,
In my case the zip file was created from windows 7  context menu (send to)
Regards,
Guillaume

On Mon, Mar 12, 2018 at 5:08 AM, Thomas Kluyver <report at bugs.python.org>
wrote:

>
> Thomas Kluyver <thomas at kluyver.me.uk> added the comment:
>
> I found source code for some other projects handling the same data. They
> all seem to agree that it should be 1:
>
> - Golang's zip reading code: https://github.com/golang/go/blob/
> f7ac70a56604033e2b1abc921d3f0f6afc85a7b3/src/archive/zip/
> reader.go#L536-L538
> - A C contrib file with zlib: https://github.com/madler/zlib/blob/
> cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/minizip/zip.c#L620-L624
> - Code from Info-ZIP, which is used by many Linux distros, is a bit less
> clear, but it has an illuminating comment:
>
>     if ((G.ecrec.number_this_disk != 0xFFFF) &&
>         (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
>       /* Note: For some unknown reason, the developers at PKWARE decided to
>          store the "zip64 total disks" value as a counter starting from 1,
>          whereas all other "split/span volume" related fields use 0-based
>          volume numbers. Sigh... */
>
> So I think you've got an invalid zip file. If it's otherwise valid, there
> might be a case for Python tolerating that particular mistake. But it's
> probably better to fix whatever is making the incorrect zip file, because
> other tools are also going to reject it.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue22102>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22102>
_______________________________________

From report at bugs.python.org  Mon Mar 12 11:49:06 2018
From: report at bugs.python.org (John Andersen)
Date: Mon, 12 Mar 2018 15:49:06 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520869746.56.0.467229070634.issue32972@psf.upfronthosting.co.za>


John Andersen <johnandersenpdx at gmail.com> added the comment:

I've updated my pull request to do the following:

1. Provide a new AsyncTestCase class which is a subclass of TestCase
2. Run coroutines with a coroutineRunner property.
  a. In 3.6 this calls get_evet_loop.run_until_complete
  b. In 3.7 > this calls asyncio.run
3. setUp, testMethod s, and tearDown can be either async or not

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:01:19 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 12 Mar 2018 16:01:19 +0000
Subject: [issue22102] Zipfile generates Zipfile error in zip with 0 total
 number of disk in Zip64 end of central directory locator
In-Reply-To: <1406670130.27.0.606950005482.issue22102@psf.upfronthosting.co.za>
Message-ID: <1520870479.23.0.467229070634.issue22102@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

If every Windows 7 computer is generating zipfiles which are invalid in this way, that would be a pretty strong argument for Python (and other tools) to accept it. But if that was the case, I would also expect that there would be many more issues about it.

Are the files you're compressing large (multi-GB)? Python only uses the zip64 format when the files are too big for the older zip format; maybe Windows is doing the same. Even in that case, I'm still surprised that more people don't hit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22102>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:07:03 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Mar 2018 16:07:03 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520870823.52.0.467229070634.issue22674@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

test_strsignal is failing on macOS.

======================================================================
FAIL: test_strsignal (test.test_signal.PosixTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/nad/Projects/PyDev/active/dev/3x/source/Lib/test/test_signal.py", line 61, in test_strsignal
    self.assertEqual(signal.strsignal(signal.SIGINT), "Interrupt")
AssertionError: 'Interrupt: 2' != 'Interrupt'
- Interrupt: 2
?          ---
+ Interrupt


Also:
http://buildbot.python.org/all/#/builders/14/builds/779/steps/4/logs/stdio
http://buildbot.python.org/all/#/builders/93/builds/435/steps/4/logs/stdio

----------
nosy: +ned.deily
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:09:51 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 16:09:51 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520870991.88.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ned, this is why I'd like issue33048 to be solved :-) Having to rely on the buildbot fleet for bugfix iteration is not convenient at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:18:05 2018
From: report at bugs.python.org (Ben Feinstein)
Date: Mon, 12 Mar 2018 16:18:05 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
Message-ID: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>


New submission from Ben Feinstein <feinsteinben at gmail.com>:

In logging.Manager, the logRecordFactory attribute is never used.

One would expect that makeRecord() (in logging.Logger) would generate a record using its manager's logRecordFactory, or fallback to the global _logRecordFactory (if has no manager, or manager.logRecordFactory is None), but the latter is used exclusively.

----------
components: Library (Lib)
files: issue_logRecordFactory.py
messages: 313662
nosy: feinsteinben, vinay.sajip
priority: normal
severity: normal
status: open
title: logging.Manager.logRecordFactory is never used
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/file47478/issue_logRecordFactory.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:24:30 2018
From: report at bugs.python.org (Antoine Pietri)
Date: Mon, 12 Mar 2018 16:24:30 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520871870.97.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pietri <antoine.pietri1 at gmail.com> added the comment:

Yes, sorry, the issue is that we decided with pitrou to remove the osx specific handling.

The fix should be:

diff --git a/Lib/test/test_signal.py b/Lib/test/test_signal.py
index fbb12a5b67..ae0351e992 100644
--- a/Lib/test/test_signal.py
+++ b/Lib/test/test_signal.py
@@ -58,8 +58,10 @@ class PosixTests(unittest.TestCase):
         self.assertEqual(signal.getsignal(signal.SIGHUP), hup)
 
     def test_strsignal(self):
-        self.assertEqual(signal.strsignal(signal.SIGINT), "Interrupt")
-        self.assertEqual(signal.strsignal(signal.SIGTERM), "Terminated")
+        self.assertTrue(signal.strsignal(signal.SIGINT)
+                        .startswith("Interrupt"))
+        self.assertTrue(signal.strsignal(signal.SIGTERM)
+                        .startswith("Terminated"))
 
     # Issue 3864, unknown if this affects earlier versions of freebsd also
     def test_interprocess_signal(self):


Should I submit a new PR for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:25:04 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Mar 2018 16:25:04 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1520871904.2.0.467229070634.issue12345@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Why does this issue keep ending up as the target of unrelated PR notifications?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:25:11 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 16:25:11 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520871911.29.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should I submit a new PR for this?

Please do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:27:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 16:27:52 +0000
Subject: [issue33055] bytes does not implement __bytes__()
In-Reply-To: <1520864882.07.0.467229070634.issue33055@psf.upfronthosting.co.za>
Message-ID: <1520872072.64.0.467229070634.issue33055@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This isn't one exception. For example complex doesn't have the __complex__ method.

__str__, __float__, __int__ and __bool__ are implemented in str, float, int and bool because there are corresponding special slots in a type object. But __bytes__ and __complex__ were added later and they have no slots. Calling them for bytes and complex will slowdown creating new object.

The user code rarely needs to call these methods directly. Just call bytes(), complex(), str(), float(), etc.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33055>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:32:49 2018
From: report at bugs.python.org (Antoine Pietri)
Date: Mon, 12 Mar 2018 16:32:49 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520872369.64.0.467229070634.issue22674@psf.upfronthosting.co.za>


Change by Antoine Pietri <antoine.pietri1 at gmail.com>:


----------
pull_requests: +5846
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:33:33 2018
From: report at bugs.python.org (Antoine Pietri)
Date: Mon, 12 Mar 2018 16:33:33 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520872413.24.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pietri <antoine.pietri1 at gmail.com> added the comment:

Done, https://github.com/python/cpython/pull/6085

As I said in the PR body, I can't test it myself, I don't have an OSX VM setup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 12:33:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 16:33:38 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1520872418.33.0.467229070634.issue12345@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Because of its lucky number. See https://github.com/python/core-workflow/issues/223 (fixed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:18:46 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 12 Mar 2018 17:18:46 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
In-Reply-To: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>
Message-ID: <1520875126.37.0.467229070634.issue33056@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 095ee415cee41bf24c3a1108c23307e5baf168dd by Andrew Svetlov (Thomas Moreau) in branch 'master':
bpo-33056 FIX leaking fd in concurrent.futures.ProcessPoolExecutor (#6084)
https://github.com/python/cpython/commit/095ee415cee41bf24c3a1108c23307e5baf168dd


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:41:08 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 12 Mar 2018 17:41:08 +0000
Subject: [issue33048] macOS job broken on Travis CI
In-Reply-To: <1520791962.83.0.467229070634.issue33048@psf.upfronthosting.co.za>
Message-ID: <1520876468.89.0.467229070634.issue33048@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
keywords: +patch
pull_requests: +5847
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33048>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:41:18 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Mar 2018 17:41:18 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520876478.97.0.467229070634.issue22674@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> Ned, this is why I'd like issue33048 to be solved :-) Having to rely on the buildbot fleet for bugfix iteration is not convenient at all.

I want to see it solved, too. :-)  But there are other core-devs out there who are in a better position to solve it at the moment; it's not particularly a macOS problem; it's a problem with using Homebrew and Travis, neither one of which I'm all that familiar with and which others have set up.  And I'm in the middle of trying to get some releases and other stuff out the door.  So, I'm not going to be able to spend time on it right now.  Sorry!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:42:34 2018
From: report at bugs.python.org (Ben Feinstein)
Date: Mon, 12 Mar 2018 17:42:34 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <1520876554.07.0.467229070634.issue33057@psf.upfronthosting.co.za>


Change by Ben Feinstein <feinsteinben at gmail.com>:


----------
keywords: +patch
pull_requests: +5848
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:45:35 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 12 Mar 2018 17:45:35 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1520876735.59.0.467229070634.issue3014@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
keywords: +patch
pull_requests: +5849
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:47:25 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 12 Mar 2018 17:47:25 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520876845.48.0.467229070634.issue33014@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
keywords: +patch
pull_requests: +5850
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:48:49 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 12 Mar 2018 17:48:49 +0000
Subject: [issue33048] macOS job broken on Travis CI
In-Reply-To: <1520791962.83.0.467229070634.issue33048@psf.upfronthosting.co.za>
Message-ID: <1520876929.93.0.467229070634.issue33048@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

I've opened a WIP PR to fix the Travis test config on macOS. Antoine is correct that the recent brew changes related to Python caused the test failure.

I will try to get working on Python3 first and then Python2.

----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33048>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:49:14 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 12 Mar 2018 17:49:14 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520876954.78.0.467229070634.issue33014@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Carol, Yes, I've raised a PR.

Currently, I've updated the docs for `str.isidentifier` clarifying the usage of `keyword.iskeyword`

For updating the docstring of `keyword.iskeyword`, I saw that `Lib/Keyword.py` defines this on line 55: `iskeyword = frozenset(kwlist).__contains__`

The docstring of the file says that it is automatically generated from `graminit.c`. I observed that file and have no clue on how to proceed to have the doc string updated. Can someone provide me a pointer on this please?

----------
keywords:  -patch
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:49:53 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 17:49:53 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520876993.7.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

float.is_integer() was added 6f34109384f3a78d5f4f8bdd418a89caca19631e (unfortunately no issue number for looking at the discussion preceded it). I don't know reasons. The same changeset added implementations of complex.is_finite(), int.is_finite(), long.is_finite(), float.is_inf() and float.is_nan(), but they were disabled by default (they are still a dead code in sources). The same changeset added well known functions math.isinf(), math.isnan(), cmath.isinf() and cmath.isnan().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 13:52:48 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Mar 2018 17:52:48 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520877168.01.0.467229070634.issue26680@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/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 14:16:08 2018
From: report at bugs.python.org (Ewoud Kohl van Wijngaarden)
Date: Mon, 12 Mar 2018 18:16:08 +0000
Subject: [issue30528] ipaddress.IPv{4,6}Network.reverse_pointer is broken
In-Reply-To: <1496250931.44.0.236459920081.issue30528@psf.upfronthosting.co.za>
Message-ID: <1520878568.68.0.467229070634.issue30528@psf.upfronthosting.co.za>


Ewoud Kohl van Wijngaarden <ewoud+python at kohlvanwijngaarden.nl> added the comment:

It's interesting to note that neither IPv4Network[1] nor IPv4Network docs mention reverse_pointer. That means it could also remove them (which essentially also throws an exception) since they don't make sense for networks. It would be useful to have the described functionality under a better name.

[1]: https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Network
[2]: https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Network

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30528>
_______________________________________

From report at bugs.python.org  Mon Mar 12 14:16:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 18:16:25 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520878585.69.0.467229070634.issue33014@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The change that will add a docstring to keyword.iskeyword() inevitable will have a negative performance effect. Is it worth it?

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 14:44:20 2018
From: report at bugs.python.org (Guillaume Carre)
Date: Mon, 12 Mar 2018 18:44:20 +0000
Subject: [issue22102] Zipfile generates Zipfile error in zip with 0 total
 number of disk in Zip64 end of central directory locator
In-Reply-To: <1520870479.23.0.467229070634.issue22102@psf.upfronthosting.co.za>
Message-ID: <CAOZ3DuKvq2DYBXkn9uuCd3pOSkUQXu_f=okDYX1HRfJ6CaHnqw@mail.gmail.com>


Guillaume Carre <gcarre20 at gmail.com> added the comment:

Yes these were pretty large zip 30 to 60Gb with thousands of small files in
them I've fixed locally on our servers and we've been happy even after
accepting similar sized files from linux machine.
I'm also quite surprised about this not being reported by others.

On Mon, Mar 12, 2018 at 9:01 AM, Thomas Kluyver <report at bugs.python.org>
wrote:

>
> Thomas Kluyver <thomas at kluyver.me.uk> added the comment:
>
> If every Windows 7 computer is generating zipfiles which are invalid in
> this way, that would be a pretty strong argument for Python (and other
> tools) to accept it. But if that was the case, I would also expect that
> there would be many more issues about it.
>
> Are the files you're compressing large (multi-GB)? Python only uses the
> zip64 format when the files are too big for the older zip format; maybe
> Windows is doing the same. Even in that case, I'm still surprised that more
> people don't hit it.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue22102>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22102>
_______________________________________

From report at bugs.python.org  Mon Mar 12 14:56:06 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Mar 2018 18:56:06 +0000
Subject: [issue33048] macOS job broken on Travis CI
In-Reply-To: <1520791962.83.0.467229070634.issue33048@psf.upfronthosting.co.za>
Message-ID: <1520880966.84.0.467229070634.issue33048@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks, Carol!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33048>
_______________________________________

From report at bugs.python.org  Mon Mar 12 14:58:09 2018
From: report at bugs.python.org (Ben Feinstein)
Date: Mon, 12 Mar 2018 18:58:09 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <1520881089.67.0.467229070634.issue33057@psf.upfronthosting.co.za>


Change by Ben Feinstein <feinsteinben at gmail.com>:


Removed file: https://bugs.python.org/file47478/issue_logRecordFactory.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:03:17 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 19:03:17 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520881397.15.0.467229070634.issue22674@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 019f5b3e9e4c2a1297580483c3d5a5a10bddb93b by Antoine Pitrou (Antoine Pietri) in branch 'master':
bpo-22674: fix test_strsignal on OSX (GH-6085)
https://github.com/python/cpython/commit/019f5b3e9e4c2a1297580483c3d5a5a10bddb93b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:03:28 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 19:03:28 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1520881408.3.0.467229070634.issue22674@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/issue22674>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:14:27 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Mar 2018 19:14:27 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520882067.75.0.467229070634.issue26680@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ongoing discussion here: https://mail.python.org/pipermail/python-dev/2018-March/152358.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:27:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 19:27:16 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520882836.61.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the use case of float.is_integer() at all? I haven't found its usages in large projects on GitHub. Only in playing examples where it is (mis)used in cases like (x/5).is_integer() (x % 5 == 0 is better) or (x**0.5).is_integer() (wrong for some floats or large integers).

Maybe it should be removed in Python 3.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:30:02 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Mar 2018 19:30:02 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520883002.04.0.467229070634.issue33014@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As I posted above, keywork.iskeyword already has a bizarrely incorrect docstring, so how can there be a performance impact? And why single out such a rarely used function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:31:15 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 19:31:15 +0000
Subject: [issue33058] Enhancing Python
Message-ID: <1520883075.96.0.467229070634.issue33058@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
nosy: elizondo93
priority: normal
severity: normal
status: open
title: Enhancing Python
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:31:45 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 19:31:45 +0000
Subject: [issue33058] [WIP] Enhancing Python's COUNT_ALLOCS
Message-ID: <1520883105.29.0.467229070634.issue33058@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
title: Enhancing Python -> [WIP] Enhancing Python's COUNT_ALLOCS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:33:18 2018
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Mar 2018 19:33:18 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520883198.36.0.467229070634.issue26680@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I agree with Mark's mailing list statements: There is no ambiguity
for decimal, given that the existing predicates ignore the context.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:33:31 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 19:33:31 +0000
Subject: [issue33058] [WIP] Enhance Python's Memory Instrumentation with
 COUNT_ALLCOS
Message-ID: <1520883211.59.0.467229070634.issue33058@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
title: [WIP] Enhancing Python's COUNT_ALLOCS -> [WIP] Enhance Python's Memory Instrumentation with COUNT_ALLCOS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:33:55 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 19:33:55 +0000
Subject: [issue33058] Enhance Python's Memory Instrumentation with COUNT_ALLOCS
Message-ID: <1520883235.44.0.467229070634.issue33058@psf.upfronthosting.co.za>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

[WIP]

----------
title: [WIP] Enhance Python's Memory Instrumentation with COUNT_ALLCOS -> Enhance Python's Memory Instrumentation with COUNT_ALLOCS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:47:08 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 19:47:08 +0000
Subject: [issue33058] Enhance Python's Memory Instrumentation with COUNT_ALLOCS
In-Reply-To: <1520883235.44.0.467229070634.issue33058@psf.upfronthosting.co.za>
Message-ID: <1520884028.33.0.467229070634.issue33058@psf.upfronthosting.co.za>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Currently, Python has very few instrumentation when it comes to the types of allocations that it's doing. For instance, we currently can't identify how many times an object uses free lists vs actual mallocs.

Currently, there's a special build which can be used by compiling with "-DCOUNT_ALLOCS". However, this build is not ABI compatible with extensions. Meaning you have to recompile all the modules that are used. Doing this on a large scale scenario (1000+ modules) is not feasible.

Thus, I propose the following enhancements:
* Make COUNT_ALLOCS ABI compatible

Then:
* Expand the counters to not only track allocs and frees but also distinguish between:
* GC Counts: Allocs/Frees coming from PyObject_GC_Malloc PyObject_GC_Del
* Memory Counts: Allocs/Frees coming from PyMem_Malloc/PyObject_Malloc PyObject_Free (modulo GC objects).
* Free Lists: "Allocs/Frees" coming from specific object's free_lists/caches.
* Misc: Extra kinds of "Allocs/Frees" such as code's zombie frame.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 15:56:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 19:56:07 +0000
Subject: [issue33058] Enhance Python's Memory Instrumentation with COUNT_ALLOCS
In-Reply-To: <1520883235.44.0.467229070634.issue33058@psf.upfronthosting.co.za>
Message-ID: <1520884567.19.0.467229070634.issue33058@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Could tracemalloc help you?

----------
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:00:01 2018
From: report at bugs.python.org (Petter S)
Date: Mon, 12 Mar 2018 20:00:01 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520884801.62.0.467229070634.issue32972@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

John: inspect.iscoroutinefunction(meth) does not work if the method is decorated with e.g. unittest.mock.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:01:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 20:01:50 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520884910.71.0.467229070634.issue33014@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For changing a docstring we have to change the implementation of iskeyword(). It seems to me that the current implementation is the fastest, and any other implementation will be a tiny bit slower.

I just wanted to say that this enhancement has a non-zero cost.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:05:51 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Mar 2018 20:05:51 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520885151.89.0.467229070634.issue26680@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Robert, would you please update you patch and submit it to Github as a pull request.  It is looking like this will likely go forward after all.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:12:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 20:12:37 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520885557.45.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I would rather deprecate float.is_integer() if it looks as a magnet of bad code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:13:53 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 20:13:53 +0000
Subject: [issue33058] Enhance Python's Memory Instrumentation with COUNT_ALLOCS
In-Reply-To: <1520883235.44.0.467229070634.issue33058@psf.upfronthosting.co.za>
Message-ID: <1520885633.41.0.467229070634.issue33058@psf.upfronthosting.co.za>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

@serhiy.storchaka tracemalloc can't distinguish between the usage of gc allocs, normal mallocs, and free list reuse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:22:01 2018
From: report at bugs.python.org (Petter S)
Date: Mon, 12 Mar 2018 20:22:01 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520886121.97.0.467229070634.issue32972@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

Personally, I think John's PR is fine. (but the test class could arguably live in asyncio) I like that setUp, tearDown and test methods all can be async.

But if setUp and tearDown should never be async as Yury commented above, they don't need runners. That is what I went for in my PR.

Introducing three new public methods to TestCase is too much. I originally made the runner private, but Yury told me to make it public and document it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:24:52 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Mon, 12 Mar 2018 20:24:52 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520886292.21.0.467229070634.issue26680@psf.upfronthosting.co.za>


Robert Smallshire <rob at sixty-north.com> added the comment:

Thank you Raymond. I'll work up a PR shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:25:02 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 12 Mar 2018 20:25:02 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520886302.7.0.467229070634.issue33014@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

I've made an additional suggestion on the open PR to add an example to the `.rst` doc that better clarifies the differences and usage of `iskeyword` and `isidentifier`.

Perhaps making that addition and skipping the updates to the C source code would be a reasonable step forward. While perhaps not ideal, it seems a reasonable compromise to provide more helpful documentation without any potential performance impact or regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:27:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Mar 2018 20:27:42 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520886462.85.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

First, John and Peter, let's not have two competing PRs.  I'd prefer to have only one to make things easier to review.  So far it looks like Peter's is slightly more developed.  And this also seems to be a complex issue, so there's plenty of work to be done here and you can work on it jointly if you want.

I think a lot of Andrew's recommendations (see [1]) about doSetUp etc make sense.

The problem is how to marry methods like `asyncSetUpClass`, `asyncSetUp` and `runTest` together: all are async, all should be executed *within* one event loop.  They should also be executed *before* you call the actual test method, so it's *incorrect* to call the test case and decide if async set ups should be called or not.  This is another argument to have a separate AsyncioTestCase base class.

BTW, we can use asyncio.run() to execute only *one* coroutine.  If you have more than one, they will be executed in *different* event loops!  This is why the "coroutine runner" proposal is fundamentally incompatible with having `asyncSetUp` methods.

Speaking of asyncSetUp, let me re-iterate why we can't *just* reuse setUp:

  class B:

    async def setUp(self):
        print('bar')

  class A(B):

    def setUp(self):
        super().setUp()
        print('foo')

If we execute tests in A, 'bar' will never be printed.

So I'm suggesting to try another approach: have a generic ABC `unittets.AsyncTestCase(ABC)` with one abstract method: `makeAsyncExecutor`.  This will be a class intended to be used by framework developers.

We then add a concrete `unittest.AsyncioTestCase(unittest.AsyncTestCase)` implementation class to unittest (or should it be asyncio? I'm fine either way).

So what will `makeAsyncExecutor` do?  It should return an instance of `unittest.AsyncExecutor(ABC)` object which roughly would look like the following (this is just an example design, we need to discuss it further):

  class AsyncExecutor(abc.ABC):

      def init(self)

      def runAsync(self, coro: typing.Coroutine)

      def shutdown(self)

Why do we need a proxy object?  Well, due to some historical reasons, `asyncio.loop.close()` just closes the loop.  The actual correct shutdown protocol for an asyncio program is a little bit more elaborate, you can take a look at how asyncio.run is implemented in Python 3.7: [2].  Correct initialization of an event loop might also require extra work.  And keep in mind, we want to have a more-or-less generic and reusable implementation here so that frameworks like Trio could use this new API too (that's not the main goal, but would be nice to have).

A few open questions: 

- Should we have 'asyncSetUpClass'?

- Should we have an event loop per one test case method, or per one class?  Should this be configurable?  In my experience both things are needed from time to time.

- If we have 'asyncSetUp' should it be called before or after 'setUp'?


[1] https://github.com/python/cpython/pull/6051
[2] https://github.com/python/cpython/blob/master/Lib/asyncio/runners.py#L8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:30:08 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 12 Mar 2018 20:30:08 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520886608.09.0.467229070634.issue32972@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

1. I'm still -1 on a separate subclass, especially since the subclass should still be compatible with the base class.

2. This is only in consideration for 3.8 (even 3.7 is past feature freeze at this point), so the version-dependent behavior is unnecessary.

3. I agree that the `super().setUp()` idiom precludes allowing `setUp` and `tearDown` to be synchronous or asynchronous unless the idiom becomes `self.runMethod(super().setUp)`, but that's longer and harder to remember.  `setUpClass` and `tearDownClass` also need to be considered.

You also still need to add tests.

`addCleanup` is an open question; I think it could handle sync or async on its own but could be convinced otherwise.


Andrew: Judging by your questions in msg313481 I think my description of `coroutine_runner` was not specific enough.  The basic idea is that unittest.case.TestCase is defined with `coroutine_runner = asyncio.run`, and if you need something else then you do:

class MyTest(TestCase):

    # I assume trio has something like this :)
    coroutine_runner = trio.run

    async def test_something_in_trio(self):
        self.assertTrue(1)


asyncio gets the special treatment of having its runner set by default by virtue of being in the standard library.

I'm certainly open to better naming :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:38:13 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 12 Mar 2018 20:38:13 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520887093.53.0.467229070634.issue33014@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Too bad we couldn't do:

iskeyword = frozenset(kwlist).__contains__
iskeyword.__doc__ = 'Test whether a string is a reserved identifier.'

But I'm sure there are reasons for this:
AttributeError: attribute '__doc__' of 'builtin_function_or_method' objects is not writable

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:43:58 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 12 Mar 2018 20:43:58 +0000
Subject: [issue32911] Doc strings no longer stored in body of AST
In-Reply-To: <1519302007.93.0.467229070634.issue32911@psf.upfronthosting.co.za>
Message-ID: <1520887438.38.0.467229070634.issue32911@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Python's AST already doesn't include a lot of syntax that has no runtime effect:
- comments;
- whitespace and punctuation.

The situation is now made "worse" with constant folding.  You won't have full line information on the full expression, you don't even fully *see* expressions as syntactically provided by user code.  The docstring is just a special case of that.

As a counter example, it still includes function-level type annotations which are not evaluated. Clearly we don't have an explicit rule about this.

If you asked *me*, I would say Python provides a "lossy" AST and this is the one it itself uses.  It also provides a "lossless" AST and this one is in lib2to3.  It's unfortunate that the latter is not documented and kind of neglected.  This is something I want to address soonish.

Summing up, I'm in favor of option 3.  The AST preserves the docstring, it simply doesn't have information on where exactly it lives.  In exchange, the tree makes it easier to *find* the docstring and easier to find the first instruction (as Serhiy points out, the first statement is now always code to be executed).

Quoting literally the second sentence of the `ast` documentation:
> The abstract syntax itself might change with each Python release.

I am not against Option 2 since it's already implemented but I feel it's a pretty big change, pretty late in the release process for 3.7.  The amount of work required *just* to preserve the line number of the docstring (which can be reasonably guessed anyway) seems silly to me.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32911>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:45:01 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 12 Mar 2018 20:45:01 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520887501.53.0.467229070634.issue32972@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Ok, Yury clarified a few points before I got my message submitted there, so some of my last message may be a bit misguided.  In particular, the problems with just using `asyncio.run` are clearer to me now.

To give my answers to Yury's open questions:

- We should have an async setUpClass capability, one way or another.

- I would say event loop per class.  If someone really needs event loop per method, they can create separate classes per method.  It's ugly, but effective.

- We should have an async setUp capability.  Maybe we could add a helper method to be called from setUp rather than adding a whole new asyncSetUp into the protocol?  That eliminates the problem of which goes first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 16:52:46 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Mar 2018 20:52:46 +0000
Subject: [issue32972] unittest.TestCase coroutine support
In-Reply-To: <1519843317.02.0.467229070634.issue32972@psf.upfronthosting.co.za>
Message-ID: <1520887966.11.0.467229070634.issue32972@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> - I would say event loop per class.  If someone really needs event loop per method, they can create separate classes per method.  It's ugly, but effective.

+1.

- We should have an async setUp capability.  Maybe we could add a helper method to be called from setUp rather than adding a whole new asyncSetUp into the protocol?  That eliminates the problem of which goes first.

I'd rather have a protocol :)  Protocols are easy to document and it's possible to statically validate them (with linters/metaclasses).  Calling some method from setUp to call asyncSetUp would be a common gotcha IMO.

We can always call synchronous setUp before asyncSetUp, I think it's intuitive enough.

Speaking of addCallback, we should have a distinct addAsyncCallback.  It's OK to have an object with both __call__ and __await__ methods -- in which case it's not clear which one you should call.

In general, while we will be adding a new subclass and a few 'async'-prefixed methods, it should still be relatively straightforward for people to write and, more importantly, read the code that uses them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32972>
_______________________________________

From report at bugs.python.org  Mon Mar 12 17:05:31 2018
From: report at bugs.python.org (=?utf-8?q?Andreas_K=C3=B6ltringer?=)
Date: Mon, 12 Mar 2018 21:05:31 +0000
Subject: [issue33059] netrc module validates file mode only for
 /home/user/.netrc
Message-ID: <1520888731.28.0.467229070634.issue33059@psf.upfronthosting.co.za>


New submission from Andreas K?ltringer <andreas.koeltringer at n-fuse.co>:

On my first try to use the netrc module I got back the error: 

    "~/.netrc access too permissive: access permissions must restrict access to only the owner"

I changed the file permissions and wrapped this up in try-except and went on to write some unit tests (using tempfile), assuming that the file mode checks would be performed on any netrc file I passed into the constructor (yes, I did not read the documentation sufficiently well).

Anyway, I believe that these security checks should be done for any netrc file (they contain sensitive information no matter where they are located on the file system). There was already a discussion on the topic

    https://bugs.python.org/issue14984

where there was concern regarding backwards-compatibility and the idea to re-visit this issue "in the future". That was in 2013, so maybe this "future" is now?

----------
components: Library (Lib)
messages: 313701
nosy: akoeltringer
priority: normal
severity: normal
status: open
title: netrc module validates file mode only for /home/user/.netrc
type: security
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/issue33059>
_______________________________________

From report at bugs.python.org  Mon Mar 12 17:12:20 2018
From: report at bugs.python.org (Bob Klahn)
Date: Mon, 12 Mar 2018 21:12:20 +0000
Subject: [issue33060] Installation hangs at "Publishing product information"
Message-ID: <1520889140.52.0.467229070634.issue33060@psf.upfronthosting.co.za>


New submission from Bob Klahn <bobstones at comcast.net>:

I am unable to install Python 2.7.14 on my Windows 7 PC.  Using python-2.7.14.amd64.msi .  The installation hangs at the "Publishing product information" step.

Subsequent installation attempts result in the message "Python 2.7.14 (64-bit) setup was interrupted.  Your system has not been modified.  To install this program at a later time, please run the installation again.  Click the Finish button to exit the Installer."

I need to be able to make this work! With this version of Windows and this version of Python.

Help!

----------
components: Installation
messages: 313702
nosy: bobstones
priority: normal
severity: normal
status: open
title: Installation hangs at "Publishing product information"
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33060>
_______________________________________

From report at bugs.python.org  Mon Mar 12 17:26:48 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Mon, 12 Mar 2018 21:26:48 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520890008.12.0.467229070634.issue33023@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

> What would those side-effects be?

Christian Heimes suggested that 
> A context contains elements that can't be cloned easily, e.g. session resumption tickets.

My concern then would be potential side-effects from such session resumption tickets and anything else that one connection attempt might save/change within an SSL Context that might have an undesirable side-effect on the follow-on connection attempts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Mon Mar 12 17:30:14 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Mar 2018 21:30:14 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520890214.47.0.467229070634.issue33023@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You won't have any session resumption tickets until a connection succeeds.  And even then, I don't think it would be a problem.  By design, SSL contexts are meant to be re-used accross multiple connections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Mon Mar 12 17:38:22 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 12 Mar 2018 21:38:22 +0000
Subject: [issue33060] Installation hangs at "Publishing product information"
In-Reply-To: <1520889140.52.0.467229070634.issue33060@psf.upfronthosting.co.za>
Message-ID: <1520890702.31.0.467229070634.issue33060@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Hi Bob,

Your best option to get timely help information about installation is to visit one of the support channels for Python:

- python-help mailing list https://www.python.org/community/lists/
- #python IRC channel https://www.python.org/community/irc/

First, make sure that your system is a 64 bit system. The installer that you reference will not work if you are using a 32 bit system.

Double check that you have all Windows updates installed. 

Try the help channels mentioned above or try to install `Windows x86 MSI installer` found at https://www.python.org/downloads/release/python-2714/

You can also try a third party distribution such as Anaconda.

----------
nosy: +willingc
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33060>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:05:43 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 12 Mar 2018 22:05:43 +0000
Subject: [issue33058] Enhance Python's Memory Instrumentation with COUNT_ALLOCS
In-Reply-To: <1520883235.44.0.467229070634.issue33058@psf.upfronthosting.co.za>
Message-ID: <1520892343.29.0.467229070634.issue33058@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch
pull_requests: +5852
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33058>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:11:47 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 12 Mar 2018 22:11:47 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
In-Reply-To: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>
Message-ID: <1520892707.33.0.467229070634.issue33056@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +5854
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:15:08 2018
From: report at bugs.python.org (Allen Tracht)
Date: Mon, 12 Mar 2018 22:15:08 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
Message-ID: <1520892908.5.0.467229070634.issue33061@psf.upfronthosting.co.za>


Change by Allen Tracht <aetracht at gmail.com>:


----------
components: Library (Lib)
nosy: Allen Tracht
priority: normal
severity: normal
status: open
title: NoReturn missing from __all__ in typing.py
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/issue33061>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:26:22 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Mon, 12 Mar 2018 22:26:22 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
Message-ID: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>


New submission from Vitaly Kruglikov <vitaly.krug at gmail.com>:

I need to write a test for my client to make sure it's non-blocking ssl interactions are able to survive SSL renegotiation. However, I can't seem to find anything in our python ssl API that calls `SSL_renegotiate()` in order to force renegotiation.

----------
assignee: christian.heimes
components: SSL
messages: 313706
nosy: christian.heimes, vitaly.krug
priority: normal
severity: normal
status: open
title: ssl_renegotiate() doesn't seem to be exposed
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/issue33062>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:26:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Mar 2018 22:26:51 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1520893611.36.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

As for StackOverflow links provided by Robert, it looks to me that float.is_integer() is always used improperly.

If keep this method it would be worth to warn against improper use of it.

Bad:

    (x/5).is_integer()

Good:

    x % 5 == 0

or

    not x % 5

Bad:

    math.sqrt(x).is_integer()

Good:

    int(math.sqrt(x))**2 == x

Bad:

    while x < y:
        if x.is_integer():
            print(x)
        x += 0.1

Good (if initial x was integer):

    x0 = x
    i = 0
    while x < y:
        x = x0 + i/10
        if not i % 10:
            print(x)
        i += 1

And provide an example of a *proper* use case (if it exists).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:34:02 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 12 Mar 2018 22:34:02 +0000
Subject: [issue21018] [patch] added missing documentation about escaping
 characters for configparser
In-Reply-To: <1395464420.76.0.68706986346.issue21018@psf.upfronthosting.co.za>
Message-ID: <1520894042.94.0.467229070634.issue21018@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

@Arun.Persaud, would you be interested in converting your patch to a Github pull request?

----------
nosy: +csabella
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21018>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:51:24 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 12 Mar 2018 22:51:24 +0000
Subject: [issue32085] [Security] A New Era of SSRF - Exploiting URL Parser in
 Trending Programming Languages!
In-Reply-To: <1511187317.56.0.213398074469.issue32085@psf.upfronthosting.co.za>
Message-ID: <1520895084.67.0.467229070634.issue32085@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Since issue 32185 has been patched, should this one be revisited to see if that solution helped fixed this one?

----------
nosy: +christian.heimes, csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32085>
_______________________________________

From report at bugs.python.org  Mon Mar 12 18:55:08 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 12 Mar 2018 22:55:08 +0000
Subject: [issue24518] json.dumps should accept key function for ``sort_keys``
In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za>
Message-ID: <1520895308.31.0.467229070634.issue24518@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

As there was interest in this patch, @catherinedevlin would you be able to make a Github pull request for it?

Thanks!

----------
nosy: +csabella
stage:  -> needs patch
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24518>
_______________________________________

From report at bugs.python.org  Mon Mar 12 19:00:48 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 12 Mar 2018 23:00:48 +0000
Subject: [issue29719] "Date" of what's new is confusing
In-Reply-To: <1488627745.64.0.63277330553.issue29719@psf.upfronthosting.co.za>
Message-ID: <1520895648.06.0.467229070634.issue29719@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I believe this can be closed as 'fixed'?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 19:24:33 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 12 Mar 2018 23:24:33 +0000
Subject: [issue20917] Idle: Enhance font change notification system
In-Reply-To: <1394741097.69.0.88319958865.issue20917@psf.upfronthosting.co.za>
Message-ID: <1520897073.46.0.467229070634.issue20917@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
dependencies: +IDLE: Add docstrings and tests for codecontext
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20917>
_______________________________________

From report at bugs.python.org  Mon Mar 12 19:30:13 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Mar 2018 23:30:13 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1520897413.28.0.467229070634.issue33014@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Separate PRs for doc and code changes will be needed anyway if the code change is restricted to 3.8.

To me, changing keyword.iskeyword.__doc__ from the irrelevant Python tautology 'x.__contains__(y) <==> y in x.' to something that says what the function does, as docstrings should,  is a bug fix, not an enhancement.  Hence a slight slowdown is not a concern to me.  I see 4 possible types of fixes.

1. Write a python function with docstring.  3.8 only as it changes type(iskeyword).

def iskeyword(s):
    "Return true if s is a Python keyword."
    return s in kwlist

2. Change the aberrant set/frozenset.__contains__.__doc__ so it makes some sense as a docstring for a bound method (as with list and dict).  
  list/tuple.__contains__.__doc__ is 'Return key in self.'
  dict.__contains__.__doc__ is 'True if the dictionary has the specified key, else False.'

I would copy the dict __contains__ docstring, with 'Return' prefixed, to set and frozenset, with the obvious substitution.  I don't know about backporting this.

3. Make bound_method docstrings writable, like with Python function docstrings (3.8 only).  Then we could use Cheryl's suggestion.  Or add a function bounddoc(bound_method, docstring) that can change a bound_method's docsting.

CPython uses 2 types for built-in methods bound to an instance.  The choice is not consistent within a class or across classes for a particular method.
  builtin_function_or_method ([].append, frozenset().__contains__)
  method-wrapper ([].__contains__)
Python classes result in 'bound method'.  All 3 copy the docstring of the instance method.  (For Python classes, one can temporarily change the method docstring before creating a new bound method.)

4. Add makebound(method, instance, docstring) that creates a bound method (of the appropriate type) but with the passed docstring (3.8 only)

3 or 4 would allow any public bound method to have a custom docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Mon Mar 12 21:11:29 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 01:11:29 +0000
Subject: [issue29719] "Date" of what's new is confusing
In-Reply-To: <1488627745.64.0.63277330553.issue29719@psf.upfronthosting.co.za>
Message-ID: <1520903489.77.0.467229070634.issue29719@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +5855
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 21:12:34 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 01:12:34 +0000
Subject: [issue29719] "Date" of what's new is confusing
In-Reply-To: <1488627745.64.0.63277330553.issue29719@psf.upfronthosting.co.za>
Message-ID: <1520903554.75.0.467229070634.issue29719@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +5856

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 21:16:12 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 01:16:12 +0000
Subject: [issue29719] "Date" of what's new is confusing
In-Reply-To: <1488627745.64.0.63277330553.issue29719@psf.upfronthosting.co.za>
Message-ID: <1520903772.08.0.467229070634.issue29719@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset a34510a4c562b4b23c7f9da6ff6e2318484f5f1a by Ned Deily in branch 'master':
bpo-29719: Remove Date and Release field in whatsnew/3.7 and 8 (GH-6093)
https://github.com/python/cpython/commit/a34510a4c562b4b23c7f9da6ff6e2318484f5f1a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 21:16:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 01:16:57 +0000
Subject: [issue29719] "Date" of what's new is confusing
In-Reply-To: <1488627745.64.0.63277330553.issue29719@psf.upfronthosting.co.za>
Message-ID: <1520903817.05.0.467229070634.issue29719@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset d461ed84b57aae0bdccd117dc38109c087444d50 by Ned Deily in branch '3.7':
bpo-29719: Remove Date and Release field in whatsnew/3.7 (GH-6094)
https://github.com/python/cpython/commit/d461ed84b57aae0bdccd117dc38109c087444d50


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 21:23:24 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 01:23:24 +0000
Subject: [issue29719] "Date" of what's new is confusing
In-Reply-To: <1488627745.64.0.63277330553.issue29719@psf.upfronthosting.co.za>
Message-ID: <1520904204.04.0.467229070634.issue29719@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> I believe this can be closed as 'fixed'?

Well, it *was* fixed!  But then I reintroduced the boilerplate when I created the 3.7 and 3.8 whatsnew files - now fixed.  Thanks for the reminder!

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29719>
_______________________________________

From report at bugs.python.org  Mon Mar 12 21:49:31 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 13 Mar 2018 01:49:31 +0000
Subject: [issue33038] GzipFile doesn't always ignore None as filename
In-Reply-To: <1520642770.84.0.467229070634.issue33038@psf.upfronthosting.co.za>
Message-ID: <1520905771.58.0.467229070634.issue33038@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
pull_requests: +5857
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33038>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:31:35 2018
From: report at bugs.python.org (Siming Yuan)
Date: Tue, 13 Mar 2018 02:31:35 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
Message-ID: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>


New submission from Siming Yuan <siming85 at gmail.com>:

compiling Python 3.5.5 under RHEL 6.4, 32-bit:

build/temp.linux-x86_64-3.5/opt/python/Python-3.5.5/Modules/_ctypes/libffi/src/x86/ffi.o: In function `ffi_prep_closure_loc':
/opt/python/Python-3.5.5/Modules/_ctypes/libffi/src/x86/ffi.c:678: undefined reference to `ffi_closure_FASTCALL'
/usr/bin/ld: build/temp.linux-x86_64-3.5/opt/python/Python-3.5.5/Modules/_ctypes/libffi/src/x86/ffi.o: relocation R_386_GOTOFF against undefined hidden symbol `ffi_closure_FASTCALL' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value


related to https://bugs.python.org/issue23042 - but it seems like the patch for x86/ffi.c never made it to release.

----------
components: Build
messages: 313716
nosy: siming85
priority: normal
severity: normal
status: open
title: failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:33:32 2018
From: report at bugs.python.org (Siming Yuan)
Date: Tue, 13 Mar 2018 02:33:32 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
In-Reply-To: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>
Message-ID: <1520908412.29.0.467229070634.issue33063@psf.upfronthosting.co.za>


Siming Yuan <siming85 at gmail.com> added the comment:

attached patch that fixes the build issue.

credit to davin @ https://bugs.python.org/issue23042

----------
keywords: +patch
Added file: https://bugs.python.org/file47479/ffi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:50:30 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 02:50:30 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
Message-ID: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Title says all. I have a patch.

----------
assignee: lukasz.langa
messages: 313718
nosy: lukasz.langa
priority: normal
severity: normal
status: open
title: lib2to3 fails on a trailing comma after **kwargs in a function signature
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:50:58 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 02:50:58 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520909458.27.0.467229070634.issue33064@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Ned, I'd like this to make into 3.6.5 if at all possible.

----------
nosy: +ned.deily
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:53:21 2018
From: report at bugs.python.org (Siming Yuan)
Date: Tue, 13 Mar 2018 02:53:21 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
In-Reply-To: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>
Message-ID: <1520909601.35.0.467229070634.issue33063@psf.upfronthosting.co.za>


Siming Yuan <siming85 at gmail.com> added the comment:

tested again with Python 3.4.8 and the bug is observed. patch & builds fine.

strangely, tested building python 3.6.4 on the same environment without patch, no issues, even though the ffi.c code is exactly the same.

----------
components: +ctypes
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:56:37 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 02:56:37 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520909797.97.0.467229070634.issue33064@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
keywords: +patch
pull_requests: +5858

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Mon Mar 12 22:56:38 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 02:56:38 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520909798.11.0.467229070634.issue33064@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
keywords: +patch, patch
pull_requests: +5858, 5859

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 01:02:16 2018
From: report at bugs.python.org (Joshua De La Rosa)
Date: Tue, 13 Mar 2018 05:02:16 +0000
Subject: [issue33065] debugger issue concerning importing user created modules
 into another program
Message-ID: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>


New submission from Joshua De La Rosa <joshuadelarosa99 at gmail.com>:

Taking my first coding class, so I don't know much about coding or python in general, but I  ran into a problem when using the Debugger function for a homework assignment that neither I nor my professor could make sense of. My program executes successfully without running the Debugger or, in the case that I am running the Debugger, it only raises an error when I "Step" through the imported module that I implemented in another program, rather than just hitting "Go". The error it reports is:
AttributeError: '_ModuleLock' object has no attribute 'name'

Not sure which file to submit, since the I created my own module that is used in the program that raises the error when I step through it with the Debugger mode on.

----------
assignee: terry.reedy
components: IDLE
messages: 313721
nosy: jcdlr, terry.reedy
priority: normal
severity: normal
status: open
title: debugger issue concerning importing user created modules into another program
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:07:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 07:07:38 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520924858.84.0.467229070634.issue33064@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Does it support a trailing comma after *args or name=value?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:26:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 07:26:01 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520925961.51.0.467229070634.issue33064@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not sure that a trailing comma after **kwargs in a function signature should be allowed in Python grammar. Reasons for allowing it after other arguments don't work here since **kwargs is always a last item in a signature.

But this ship perhaps is sailed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:44:53 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 07:44:53 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520927093.7.0.467229070634.issue33064@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset b51f5de71163f096d2d5229ede5379cdb284f651 by ?ukasz Langa in branch 'master':
bpo-33064: lib2to3: support trailing comma after *args and **kwargs (#6096)
https://github.com/python/cpython/commit/b51f5de71163f096d2d5229ede5379cdb284f651


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:44:58 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 13 Mar 2018 07:44:58 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520927098.78.0.467229070634.issue33064@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5860

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:45:58 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 13 Mar 2018 07:45:58 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520927158.24.0.467229070634.issue33064@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5861

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:49:12 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 07:49:12 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520927352.28.0.467229070634.issue33064@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Yes, this ship has sailed with Python 3.6.

I understand your logic and this is indeed why we didn't support this for a long time. However, people tend to grow muscle memory to add trailing commas and that was tripping them over for no real gain on our part. So this was added. The reason I found out about lib2to3 not following suit was that 3.6 users quickly started to put those trailing commas in and tools using lib2to3 were crashing on such files :) This proves it was worth it.

----------
resolution:  -> fixed
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 03:52:19 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 07:52:19 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520927539.96.0.467229070634.issue33064@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Oh, and in terms of *calling* functions, now we can specify multiple unpacks, like:

  >>> f(
  ...   **d,
  ...   **e,
  ... )

so the extra comma for signatures simply makes it symmetrical in terms of appearance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:03:53 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 08:03:53 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1520928233.27.0.467229070634.issue33062@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Since it's a feature request, I have changed the version number to 3.8.

By the way, renegotiation is a problematic and has been replaced by rekeying in TLS 1.3.

----------
type: behavior -> 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/issue33062>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:08:06 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 08:08:06 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520928486.07.0.467229070634.issue33064@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset b4c8871ca43d37be167ef5dbe9fb341922c04a9f by ?ukasz Langa (Miss Islington (bot)) in branch '3.7':
bpo-33064: lib2to3: support trailing comma after *args and **kwargs (GH-6096) (#6097)
https://github.com/python/cpython/commit/b4c8871ca43d37be167ef5dbe9fb341922c04a9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:32:36 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 08:32:36 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520929956.6.0.467229070634.issue33064@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 6a526f673878677032c02f7800ee13d4769f391a by ?ukasz Langa (Miss Islington (bot)) in branch '3.6':
bpo-33064: lib2to3: support trailing comma after *args and **kwargs (GH-6096) (#6098)
https://github.com/python/cpython/commit/6a526f673878677032c02f7800ee13d4769f391a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:50:12 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 08:50:12 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520931012.96.0.467229070634.issue33023@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5862
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:52:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 08:52:38 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520931158.2.0.467229070634.issue17288@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e32bbaf376a09c149fa7c7f2919d7c9ce4e2a055 by Serhiy Storchaka (xdegaye) in branch '3.7':
[3.7] bpo-17288: Prevent jumps from 'return' and 'exception' trace events. (GH-5928)
https://github.com/python/cpython/commit/e32bbaf376a09c149fa7c7f2919d7c9ce4e2a055


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:54:03 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 08:54:03 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1520931243.52.0.467229070634.issue33023@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Antoine is correct. Session resumption is fully transparent for the application layer. The context object is designed to be reused by multiple connections to same or different servers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:54:10 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 13 Mar 2018 08:54:10 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520931250.13.0.467229070634.issue17288@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5863

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:56:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 08:56:31 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520931391.51.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Fix jumping out of "with" block, cannot jump from a 'return' or 'exception' trace event

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Tue Mar 13 04:58:05 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 08:58:05 +0000
Subject: [issue33025] urlencode produces bad output from ssl.CERT_NONE and
 friends that chokes decoders
In-Reply-To: <1520492267.34.0.467229070634.issue33025@psf.upfronthosting.co.za>
Message-ID: <1520931485.89.0.467229070634.issue33025@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Ethan, please take a look.

----------
assignee:  -> ethan.furman
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33025>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:05:58 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 09:05:58 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520931958.96.0.467229070634.issue33064@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
pull_requests: +5864
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:11:00 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Mar 2018 09:11:00 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
In-Reply-To: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>
Message-ID: <1520932260.13.0.467229070634.issue33056@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset f216cbf9ab704da98146a25d57ff0e85aecb49da by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
bpo-33056 FIX leaking fd in concurrent.futures.ProcessPoolExecutor (GH-6084) (#6092)
https://github.com/python/cpython/commit/f216cbf9ab704da98146a25d57ff0e85aecb49da


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:12:21 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Mar 2018 09:12:21 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
In-Reply-To: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>
Message-ID: <1520932341.36.0.467229070634.issue33056@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Andrew: where there are multiprocessing issues, could you please nosy me so that I get a chance to review?

Thomas: thanks for spotting this and thanks for the fix!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:13:53 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 09:13:53 +0000
Subject: [issue11594] 2to3 does not preserve line endings
In-Reply-To: <1300465648.02.0.83291128633.issue11594@psf.upfronthosting.co.za>
Message-ID: <1520932433.97.0.467229070634.issue11594@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
keywords: +easy -patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11594>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:19:08 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Mar 2018 09:19:08 +0000
Subject: [issue8947] as_integer_ratio Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1520932748.52.0.467229070634.issue8947@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
title: Provide  as_integer_ratio() method to Decimal -> as_integer_ratio Decimal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:19:24 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Mar 2018 09:19:24 +0000
Subject: [issue8947] Provide as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1520932764.61.0.467229070634.issue8947@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
title: as_integer_ratio Decimal -> Provide as_integer_ratio() method to Decimal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:19:42 2018
From: report at bugs.python.org (hubo)
Date: Tue, 13 Mar 2018 09:19:42 +0000
Subject: [issue33066] raise an exception from multiple positions break the
 traceback frames
Message-ID: <1520932782.62.0.467229070634.issue33066@psf.upfronthosting.co.za>


New submission from hubo <hubo1016 at 126.com>:

The attachment is a script that demonstrates the behavior. The simple unittest script should exit very quickly, but in fact, it runs indefinitely.

It uses asyncio to reproduce the result, but other concurrent technologies are also affected.

In Python 3, traceback of an exception is mutable. When the exception is re-raised, current frames are appended to the traceback. But when the same exception object is raised in multiple position (e.g. passed to different coroutines with futures), the frames are appended in the same list, so the tracebacks are mixed together.

assertRaises in unittest calls traceback.clear_frames internally. When the tracebacks are mixed, it may clear a running frame (in a generator), producing strange behaviors.

----------
files: test1.py
messages: 313735
nosy: hubo1016
priority: normal
severity: normal
status: open
title: raise an exception from multiple positions break the traceback frames
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47480/test1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33066>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:34:07 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 09:34:07 +0000
Subject: [issue30622] Fix NPN guard for OpenSSL 1.1
In-Reply-To: <1497107294.71.0.653300932954.issue30622@psf.upfronthosting.co.za>
Message-ID: <1520933647.25.0.467229070634.issue30622@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5865

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30622>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:56:45 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 09:56:45 +0000
Subject: [issue32885] Tools/scripts/pathfix.py leaves bunch of ~ suffixed
 files around with no opt-out
In-Reply-To: <1519124808.65.0.467229070634.issue32885@psf.upfronthosting.co.za>
Message-ID: <1520935005.96.0.467229070634.issue32885@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 5affd5c29eb1493cb31ef3cfdde15538ac134689 by Christian Heimes (Miro Hron?ok) in branch 'master':
bpo-32885: Tools/scripts/pathfix.py: Add -n option for no backup~ (#5772)
https://github.com/python/cpython/commit/5affd5c29eb1493cb31ef3cfdde15538ac134689


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32885>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:58:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 13 Mar 2018 09:58:03 +0000
Subject: [issue32885] Tools/scripts/pathfix.py leaves bunch of ~ suffixed
 files around with no opt-out
In-Reply-To: <1519124808.65.0.467229070634.issue32885@psf.upfronthosting.co.za>
Message-ID: <1520935083.5.0.467229070634.issue32885@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5866

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32885>
_______________________________________

From report at bugs.python.org  Tue Mar 13 05:58:53 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 13 Mar 2018 09:58:53 +0000
Subject: [issue32885] Tools/scripts/pathfix.py leaves bunch of ~ suffixed
 files around with no opt-out
In-Reply-To: <1519124808.65.0.467229070634.issue32885@psf.upfronthosting.co.za>
Message-ID: <1520935133.23.0.467229070634.issue32885@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5867

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32885>
_______________________________________

From report at bugs.python.org  Tue Mar 13 06:12:19 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 13 Mar 2018 10:12:19 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520935939.08.0.467229070634.issue17288@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cf61a81f1d600064be6dd43896afcf5f976de9b0 by Miss Islington (bot) in branch '3.6':
[3.7] bpo-17288: Prevent jumps from 'return' and 'exception' trace events. (GH-5928)
https://github.com/python/cpython/commit/cf61a81f1d600064be6dd43896afcf5f976de9b0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 06:16:18 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 13 Mar 2018 10:16:18 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
In-Reply-To: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>
Message-ID: <1520936178.54.0.467229070634.issue33056@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Antoine sorry, will do next time

----------
components: +Windows, XML -Library (Lib)
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Tue Mar 13 06:35:47 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Tue, 13 Mar 2018 10:35:47 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1520937347.17.0.467229070634.issue33062@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

> By the way, renegotiation is a problematic and has been replaced by rekeying in TLS 1.3

How can I trigger rekeying via python ssl? Many thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Tue Mar 13 07:14:03 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 11:14:03 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1520939643.69.0.467229070634.issue33062@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

You can't.

Rekeying is not available yet. SSL_key_update() is only available with OpenSSL 1.1.1 and TLS 1.3. Both are still in beta phase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Tue Mar 13 07:14:31 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Mar 2018 11:14:31 +0000
Subject: [issue28716] Fractions instantiation revisited
In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za>
Message-ID: <1520939671.61.0.467229070634.issue28716@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Eric Wieser]

> This would allow the numpy `np.floating` types to take part in `Fraction` conversion as well, which would be great.

I'm confused: as far as I can tell, the NumPy floating-point types don't implement `as_integer_ratio`. (Except for `np.float64`, which subclasses `float` and so inherits `is_integer_ratio` from it.) Or are you suggesting that _if_ they were to implement `as_integer_ratio` at some point in the future, then they'd become compatible with `Fraction`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28716>
_______________________________________

From report at bugs.python.org  Tue Mar 13 08:01:47 2018
From: report at bugs.python.org (Arran McCutcheon)
Date: Tue, 13 Mar 2018 12:01:47 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1520942507.04.0.467229070634.issue25345@psf.upfronthosting.co.za>


Arran McCutcheon <arran-m at hotmail.com> added the comment:

I'm also having this problem on Windows 10 with Python 3.6.4, and previous versions of Python. Every time I try to install Python, I get error 0x80070652. Rebooting doesn't help. I've attached my log file in case that helps as I don't know how to interpret it. Was a solution found?

----------
nosy: +ArranM
Added file: https://bugs.python.org/file47481/Python 3.6.4 (64-bit)_20180313115253.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Tue Mar 13 08:06:44 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 12:06:44 +0000
Subject: [issue33067] http.client no longer sends HTTP request in one TCP
 package
Message-ID: <1520942803.97.0.467229070634.issue33067@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

https://bugs.python.org/issue23302 changed how http.client sends request. endheaders() no longer sends header and message body in one TCP package if the total payload is smaller than TCP max segment size. https://github.com/python/cpython/blob/3.5/Lib/http/client.py#L934-L936 uses two send calls to send header and body. This causes very simple HTTP servers in embedded devices to fail.

Matthew Garrett noticed the bug, see https://twitter.com/mjg59/status/972985566387032064 / https://twitter.com/mjg59/status/973000950439817217

We should try to send requests as one TCP package again. TCP_CORK may do the trick. Or we should fix our custom implementation of send. It has multiple issues, e.g. a fixed buffer. The buffer size is suboptimal for small MTU and jumbo frames.

----------
components: Library (Lib)
keywords: 3.5regression
messages: 313743
nosy: benjamin.peterson, christian.heimes
priority: normal
severity: normal
status: open
title: http.client no longer sends HTTP request in one TCP package
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33067>
_______________________________________

From report at bugs.python.org  Tue Mar 13 08:26:02 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Mar 2018 12:26:02 +0000
Subject: [issue33065] IDLE debugger: problem importing user created module
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1520943962.19.0.467229070634.issue33065@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I cannot do anything from this bare description, as I cannot think of any reason why stepping should introduce an error.  It sounds like there are two files involved.  Try to reduce them to the minimum needed to reproduce the issue and then upload.

----------
stage:  -> test needed
title: debugger issue concerning importing user created modules into another program -> IDLE debugger: problem importing user created module
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Tue Mar 13 08:50:49 2018
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Tue, 13 Mar 2018 12:50:49 +0000
Subject: [issue33068] Inconsistencies in parsing (evaluating?) longstrings
Message-ID: <1520945449.38.0.467229070634.issue33068@psf.upfronthosting.co.za>


New submission from David Luke? <dafydd.lukes at gmail.com>:

""" \""" """ evaluates to ' """ ' (as expected), but without the surrounding spaces, """\"""""" evaluates to '"' instead of '"""'.

Is this expected behavior? If I'm reading the definition of string syntax in https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals correctly, it shouldn't be.

----------
components: Interpreter Core
messages: 313745
nosy: David Luke?
priority: normal
severity: normal
status: open
title: Inconsistencies in parsing (evaluating?) longstrings
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33068>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:07:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 13:07:05 +0000
Subject: [issue33068] Inconsistencies in parsing (evaluating?) longstrings
In-Reply-To: <1520945449.38.0.467229070634.issue33068@psf.upfronthosting.co.za>
Message-ID: <1520946425.59.0.467229070634.issue33068@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

"""\"""""" is parsed as """\"""" "": a triple-quoted string containing an escaped '"', followed by an empty single-quoted string.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33068>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:43:49 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 13 Mar 2018 13:43:49 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
Message-ID: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

This is basically the same as issue 962772, as there seems to have been a regression. The current version of distutils discards author= metadata if maintainer= is present, even though PEP 345 has added the Maintainer: and Maintainer-Email: metadata fields.

I think that the way forward is to have write_pkg_info generate separate Maintainer: and Maintainer-Email: fields.

----------
components: Distutils
messages: 313747
nosy: dstufft, eric.araujo, p-ganssle
priority: normal
severity: normal
status: open
title: Maintainer information discarded when writing PKG-INFO
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:47:33 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 13 Mar 2018 13:47:33 +0000
Subject: [issue30528] ipaddress.IPv{4,6}Network.reverse_pointer is broken
In-Reply-To: <1496250931.44.0.236459920081.issue30528@psf.upfronthosting.co.za>
Message-ID: <1520948853.09.0.467229070634.issue30528@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30528>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:48:51 2018
From: report at bugs.python.org (Andreas Schwab)
Date: Tue, 13 Mar 2018 13:48:51 +0000
Subject: [issue33070] Add platform triplet for RISC-V
Message-ID: <1520948931.79.0.467229070634.issue33070@psf.upfronthosting.co.za>


Change by Andreas Schwab <schwab at linux-m68k.org>:


----------
components: Build
nosy: schwab
priority: normal
severity: normal
status: open
title: Add platform triplet for RISC-V
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33070>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:49:17 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 13 Mar 2018 13:49:17 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1520948957.48.0.467229070634.issue33069@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:50:44 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Mar 2018 13:50:44 +0000
Subject: [issue33070] Add platform triplet for RISC-V
Message-ID: <1520949044.95.0.467229070634.issue33070@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5868
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33070>
_______________________________________

From report at bugs.python.org  Tue Mar 13 09:52:10 2018
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Tue, 13 Mar 2018 13:52:10 +0000
Subject: [issue33068] Inconsistencies in parsing (evaluating?) longstrings
In-Reply-To: <1520945449.38.0.467229070634.issue33068@psf.upfronthosting.co.za>
Message-ID: <1520949130.49.0.467229070634.issue33068@psf.upfronthosting.co.za>


David Luke? <dafydd.lukes at gmail.com> added the comment:

Oh, right, of course! Sorry and thanks for taking the time to clarify that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33068>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:21:06 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 14:21:06 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1520950866.19.0.467229070634.issue33069@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:21:27 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 13 Mar 2018 14:21:27 +0000
Subject: [issue33071] Document that PyPI no longer requires 'register'
Message-ID: <1520950887.05.0.467229070634.issue33071@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

I've been asked to post this by @brainwave (who is having some trouble getting an account on bpo due to technical difficulties).

Per twine's github issue 311 ( https://github.com/pypa/twine/issues/311 ), it seems that distutil's docs Update setuptools and distutils docs, e.g., https://docs.python.org/3.6/distutils/packageindex.html#the-upload-command should be clarified to indicate that PyPI does not require register anymore, although other package indexes might.

----------
assignee: docs at python
components: Distutils, Documentation
messages: 313749
nosy: docs at python, dstufft, eric.araujo, p-ganssle
priority: normal
severity: normal
status: open
title: Document that PyPI no longer requires 'register'
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33071>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:25:06 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 13 Mar 2018 14:25:06 +0000
Subject: [issue30528] ipaddress.IPv{4,6}Network.reverse_pointer is broken
In-Reply-To: <1496250931.44.0.236459920081.issue30528@psf.upfronthosting.co.za>
Message-ID: <1520951106.45.0.467229070634.issue30528@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The "reverse_pointers" attribute is implicitly documented by this phrase in the introduction of network objects:

--
All attributes implemented by address objects are implemented by network objects as well.
--

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30528>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:27:59 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 14:27:59 +0000
Subject: [issue33071] Document that PyPI no longer requires 'register'
In-Reply-To: <1520950887.05.0.467229070634.issue33071@psf.upfronthosting.co.za>
Message-ID: <1520951279.11.0.467229070634.issue33071@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
components:  -Distutils
keywords: +easy
versions: +Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33071>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:33:55 2018
From: report at bugs.python.org (Jon Janzen)
Date: Tue, 13 Mar 2018 14:33:55 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520951635.83.0.467229070634.issue26707@psf.upfronthosting.co.za>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

Ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26707>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:39:35 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 13 Mar 2018 14:39:35 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520951975.14.0.467229070634.issue26707@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm still not too happy about supporting UIDs in plistlib, especially because I'm not sure it that's all that's needed. AFAIK I removed more types that the underlying encoder supported from plistlib because those are never used in plist files. 

The swift encoder for keyed archives is probably not the code that's actually used on the OS, AFAIK that still is Objective-C code.

P.S. I changed the version selection to 3.8, adding support for UIDs would be a feature change and not suited for back ports.

----------
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26707>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:44:28 2018
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 13 Mar 2018 14:44:28 +0000
Subject: [issue28716] Fractions instantiation revisited
In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za>
Message-ID: <1520952268.9.0.467229070634.issue28716@psf.upfronthosting.co.za>


Eric Wieser <wieser.eric+pybug at gmail.com> added the comment:

> Are you suggesting that _if_ they were to implement `as_integer_ratio` at some point in the future, then they'd become compatible with `Fraction`

Yes, exactly. Conversely, there's little gain in implementing it _until_ `Fraction` supports calling it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28716>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:46:17 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Mar 2018 14:46:17 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1520952377.36.0.467229070634.issue25345@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Arran - I think yours is a different issue. There should be some other log files near the one you shared that I'll need to see to find what's going wrong. Can you zip up all the Python ones and attach them here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:48:36 2018
From: report at bugs.python.org (Siming Yuan)
Date: Tue, 13 Mar 2018 14:48:36 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
In-Reply-To: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>
Message-ID: <1520952516.55.0.467229070634.issue33063@psf.upfronthosting.co.za>


Siming Yuan <siming85 at gmail.com> added the comment:

edit - I do see this in python 3.6.4 on a different server when building 32-bit 

Red Hat Enterprise Linux Workstation release 6.7 (Santiago)

gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:49:02 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Mar 2018 14:49:02 +0000
Subject: [issue33056] LEaking files in concurrent.futures.process
In-Reply-To: <1520867355.07.0.467229070634.issue33056@psf.upfronthosting.co.za>
Message-ID: <1520952542.21.0.467229070634.issue33056@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Andrew - you can search for some module names in the nosy list to add the designated people for them. The components list doesn't include all of them (perhaps it should?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33056>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:52:43 2018
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 13 Mar 2018 14:52:43 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1520952763.23.0.467229070634.issue24925@psf.upfronthosting.co.za>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

I always use the following piece of code that can be trivially used to patch the source.
It basically looks for a using line in the test string and finds it in the source file. If there is a match, we know where we are. Otherwise it falls back to the "normal" way.

----------
Added file: https://bugs.python.org/file47482/doctestfix.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:52:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 14:52:52 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520952772.86.0.467229070634.issue26707@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26707>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:54:03 2018
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 13 Mar 2018 14:54:03 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1520952843.51.0.467229070634.issue24925@psf.upfronthosting.co.za>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

Oh wait, I already posted that so long ago I forgot about it.
Oops.
Sorry about the repetition, folks.
- Jurjen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Mar 13 10:56:40 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Mar 2018 14:56:40 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
In-Reply-To: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>
Message-ID: <1520953000.73.0.467229070634.issue33063@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

3.4 and 3.5 are in security release-only mode.

----------
nosy: +christian.heimes
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Tue Mar 13 11:25:33 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 13 Mar 2018 15:25:33 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
In-Reply-To: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>
Message-ID: <1520954733.36.0.467229070634.issue33063@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Your better option is to install libffi-devel (or whatever the correct name is ) on your system and use `./configure --with-system-ffi`.  This is the default in 3.6 and the only option in 3.7 (on any platform but Windows and macOS).

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Tue Mar 13 11:27:02 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 13 Mar 2018 15:27:02 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1520954822.53.0.467229070634.issue33069@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
keywords: +patch
pull_requests: +5869
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Tue Mar 13 11:28:02 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Mar 2018 15:28:02 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520954882.01.0.467229070634.issue17288@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

In PR 5928 Serhiy Storchaka wrote:
> Great! Could you please create a backport to master?

Yes.
I prefer to answer in the issue as I am still not getting any mail from github.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 12:01:27 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 13 Mar 2018 16:01:27 +0000
Subject: [issue23599] single and double quotes stripped upon paste with
 MacPorts libedit
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1520956887.0.0.467229070634.issue23599@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Ned,

Do you think this issue still needs follow up?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23599>
_______________________________________

From report at bugs.python.org  Tue Mar 13 12:33:47 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Mar 2018 16:33:47 +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: <1520958827.73.0.467229070634.issue32174@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

We should probably prefer to force ASCII with explicit escapes (ideally named escapes, rather than codepoints). I'm not sure how to make Sphinx/docutils do that, but presumably it could be our own extension that handles the problematic characters people add to our docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32174>
_______________________________________

From report at bugs.python.org  Tue Mar 13 12:36:54 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Mar 2018 16:36:54 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520959014.88.0.467229070634.issue17288@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +5870

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 13:29:20 2018
From: report at bugs.python.org (Jon Janzen)
Date: Tue, 13 Mar 2018 17:29:20 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1520962160.84.0.467229070634.issue26707@psf.upfronthosting.co.za>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

Support for KeyedArchives are not limited to the Swift implementation I linked to. They have been supported since Mac OS X since 10.2 (long before Swift came around). The documentation (https://developer.apple.com/documentation/foundation/nskeyedarchiver?language=objc) shows that NSKeyedArchive can only output in plist format since outputFormat is of type NSPropertyListFormat (allowing to output in either XML or binary).

The other unimplemented binary token types (URL, UUID, set, ordset) are not used under NSKeyedArchive (see the "Encoding Data and Objects" section of the documentation mentioned above) so there's no concern that supporting 0x80 (UID) will suddenly necessitate implementing the other unimplemented types. If you feel that it would be necessary to implement them in order to accept the patch I would be happy to try and implement them.

I know I certainly have an use case (reading to-do list data from the 2Do app) and the creator of this bug wanted to read SnapChat data files.

Currently, I am using a hot-patched plistlib._BinaryPlistParser to read the data I need (see attached for a snippet) and I would rather not do that, but if you think my use case scope does not warrant inclusion in the standard library then I'll just have to deal with that.

----------
Added file: https://bugs.python.org/file47483/plist_hack.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26707>
_______________________________________

From report at bugs.python.org  Tue Mar 13 13:31:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 17:31:35 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520962295.73.0.467229070634.issue17288@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b8e9d6c5cd44ebc9c462fea9ad1bc5d0b970e28a by Serhiy Storchaka (xdegaye) in branch 'master':
bpo-17288: Prevent jumps from 'return' and 'exception' trace events. (GH-6107)
https://github.com/python/cpython/commit/b8e9d6c5cd44ebc9c462fea9ad1bc5d0b970e28a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 13:32:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 17:32:57 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520962377.38.0.467229070634.issue17288@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you! Do you mind to make a backport to 2.7 (if this makes a sense)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 13:40:23 2018
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 13 Mar 2018 17:40:23 +0000
Subject: [issue33067] http.client no longer sends HTTP request in one TCP
 package
In-Reply-To: <1520942803.97.0.467229070634.issue33067@psf.upfronthosting.co.za>
Message-ID: <1520962823.21.0.467229070634.issue33067@psf.upfronthosting.co.za>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33067>
_______________________________________

From report at bugs.python.org  Tue Mar 13 14:56:54 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Mar 2018 18:56:54 +0000
Subject: [issue8947] Provide as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1520967414.53.0.467229070634.issue8947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Apologies: the title change was accidental. Reverted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Mar 13 15:04:17 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Mar 2018 19:04:17 +0000
Subject: [issue8947] Provide as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1520967857.71.0.467229070634.issue8947@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

This issue has been superseded by #25928.

----------
resolution: rejected -> duplicate
stage: patch review -> resolved
superseder:  -> Add Decimal.as_integer_ratio()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Mar 13 15:14:24 2018
From: report at bugs.python.org (Siming Yuan)
Date: Tue, 13 Mar 2018 19:14:24 +0000
Subject: [issue33063] failed to build _ctypes: undefined reference to
 `ffi_closure_FASTCALL'
In-Reply-To: <1520908295.51.0.467229070634.issue33063@psf.upfronthosting.co.za>
Message-ID: <1520968464.54.0.467229070634.issue33063@psf.upfronthosting.co.za>


Siming Yuan <siming85 at gmail.com> added the comment:

interesting, didn't know that option existed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33063>
_______________________________________

From report at bugs.python.org  Tue Mar 13 15:43:03 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 13 Mar 2018 19:43:03 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1520970183.71.0.467229070634.issue27984@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

@xiang.zhang, would you be able to make a PR for your patch?  Thanks!

----------
nosy: +csabella
stage:  -> patch review
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Tue Mar 13 15:59:22 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 13 Mar 2018 19:59:22 +0000
Subject: [issue33072] The interpreter bytecodes for with statements are overly
 complex.
Message-ID: <1520971162.63.0.467229070634.issue33072@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The bytecodes WITH_CLEANUP_START and WITH_CLEANUP_FINISH are complex and implement entirely different behavior depending on what is on the stack.

This is unnecessary as the same semantics can be implemented with much simpler bytecodes and using the compiler do much of the work now done at runtime.

----------
components: Interpreter Core
messages: 313771
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: The interpreter bytecodes for with statements are overly complex.
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33072>
_______________________________________

From report at bugs.python.org  Tue Mar 13 15:59:37 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 13 Mar 2018 19:59:37 +0000
Subject: [issue33072] The interpreter bytecodes for with statements are overly
 complex.
In-Reply-To: <1520971162.63.0.467229070634.issue33072@psf.upfronthosting.co.za>
Message-ID: <1520971177.4.0.467229070634.issue33072@psf.upfronthosting.co.za>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +5871
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33072>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:13:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 20:13:16 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520971996.54.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5872

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:16:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 20:16:00 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1520972160.02.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 6110 adds tests for jumping in/out of 'async with' blocks. It isn't directly related to 'async for', but it adds helpers that will be used also in tests for 'async for'.

I'm not sure this is a correct and good way of writing such tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:22:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 20:22:55 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1520972575.15.0.467229070634.issue32949@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5873

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:27:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 20:27:13 +0000
Subject: [issue33072] The interpreter bytecodes for with statements are overly
 complex.
In-Reply-To: <1520971162.63.0.467229070634.issue33072@psf.upfronthosting.co.za>
Message-ID: <1520972833.91.0.467229070634.issue33072@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I already opened issue32949 for this.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Simplify "with"-related opcodes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33072>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:28:25 2018
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 13 Mar 2018 20:28:25 +0000
Subject: [issue33072] The interpreter bytecodes for with statements are overly
 complex.
In-Reply-To: <1520971162.63.0.467229070634.issue33072@psf.upfronthosting.co.za>
Message-ID: <1520972905.12.0.467229070634.issue33072@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

So you did.
Sorry for the duplication

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33072>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:46:04 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Mar 2018 20:46:04 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520973964.41.0.467229070634.issue17288@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +5874

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:50:06 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Mar 2018 20:50:06 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520974206.73.0.467229070634.issue17288@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The conditions used for the fix are still the same in 2.7: f->f_trace == NULL on a call event, f->f_lasti == -1 in a new frame and f->f_stacktop == NULL in a trace function with a non-line event except for yield statements.
There are minor differences: the YIELD_FROM opcode does not exist and function.__code__ is written as function.func_code.

Added a PR for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 16:53:59 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Mar 2018 20:53:59 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520974439.39.0.467229070634.issue17288@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

FWIW I now get github notifications, the problem was some bad configuration of my github profile (my fault).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:01:43 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Mar 2018 21:01:43 +0000
Subject: [issue23599] single and double quotes stripped upon paste with
 MacPorts libedit
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1520974903.77.0.467229070634.issue23599@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Cheryl, as far as I know this is still an unresolved issue for at least some versions of Python and some versions of libedit.  I'd like to keep it open as a reminder.  If someone else wants to dig into it before I get around to it, feel free to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23599>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:04:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 21:04:13 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520975053.53.0.467229070634.issue17288@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:06:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 21:06:17 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520975177.22.0.467229070634.issue17288@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset baca85fcc7cdf70af4a76ea0966d4842c173de1a by Serhiy Storchaka (xdegaye) in branch '2.7':
[2.7] bpo-17288: Prevent jumps from 'return' and 'exception' trace events. (GH-6111)
https://github.com/python/cpython/commit/baca85fcc7cdf70af4a76ea0966d4842c173de1a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:11:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 21:11:32 +0000
Subject: [issue17288] cannot jump from a 'return' or 'exception' trace event
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1520975492.85.0.467229070634.issue17288@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Xavier!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:25:05 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Mar 2018 21:25:05 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
Message-ID: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Goal:  make int() more interoperable with float by making a float/Decimal method also available on ints.  This will let mypy treat ints as a subtype of floats.

See: https://mail.python.org/pipermail/python-dev/2018-March/152384.html

Open question:  Is this also desired for fractions.Fraction and numbers.Rational?

----------
assignee: Nofar Schnider
components: Library (Lib)
messages: 313780
nosy: Nofar Schnider, gvanrossum, rhettinger
priority: normal
severity: normal
status: open
title: Add as_integer_ratio() to int() objects
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:36:37 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 13 Mar 2018 21:36:37 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520976997.15.0.467229070634.issue33073@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

> Is this also desired for fractions.Fraction and numbers.Rational?

I think so.  The idea, e.g., that "it's obvious" for Fraction is no more compelling than that it's even more obvious for ints ;-)  Given that it's spreading to ints anyway, there's an opportunity to make it possible for clients to write utterly uniform code for every type whose values can be represented as integer ratios.

I'd also say it's desirable to extend the Fraction constructor, to accept argument(s) of any type(s) that implement as_integer_ratio().  But that should probably be a different issue.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:37:35 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Mar 2018 21:37:35 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520977055.21.0.467229070634.issue33073@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/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:39:13 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Mar 2018 21:39:13 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520977153.33.0.467229070634.issue33073@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On the Fraction constructor, it looks like there's some overlap with the goals of issue #28716 here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:45:02 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Mar 2018 21:45:02 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520977502.68.0.467229070634.issue33073@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> it looks like there's some overlap with the goals of issue #28716

Okay, let's focus this issue on just int.as_integer_ratio() so that Nofar can have something small and self contained to work on :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:46:15 2018
From: report at bugs.python.org (Nofar Schnider)
Date: Tue, 13 Mar 2018 21:46:15 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520977575.07.0.467229070634.issue33073@psf.upfronthosting.co.za>


Nofar Schnider <nofarsch at gmail.com> added the comment:

I'm working on it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:52:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Mar 2018 21:52:44 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520977964.33.0.467229070634.issue33073@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Wouldn't be better to add the function as_integer_ration() in the math module (or in more appropriate place)?

def as_integer_ration(x):
    if hasattr(x, 'as_integer_ration'):
        return x.as_integer_ration()
    else:
        return (x.numerator, x.denominator)

The advantage over adding the int method is that it will automatically support other rational numbers like NumPy integers.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:54:21 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Mar 2018 21:54:21 +0000
Subject: [issue28716] Fractions instantiation revisited
In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za>
Message-ID: <1520978061.37.0.467229070634.issue28716@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FYI, adding int.as_integer_ratio() is being taken care in a separate issue:  https://bugs.python.org/issue33073 . I've set it aside for a beginning core-dev mentee to work on because it is simple and self-contained.  Pretty much all the related work can be done here.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28716>
_______________________________________

From report at bugs.python.org  Tue Mar 13 17:54:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Mar 2018 21:54:59 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520978099.55.0.467229070634.issue33073@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +easy (C)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:06:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Mar 2018 22:06:33 +0000
Subject: [issue33054] unittest blocks when testing function using
 multiprocessing.Pool with state spawn
In-Reply-To: <1520860375.4.0.467229070634.issue33054@psf.upfronthosting.co.za>
Message-ID: <1520978793.16.0.467229070634.issue33054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please, can you post a self-contained script to reproduce the issue?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33054>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:19:55 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Mar 2018 22:19:55 +0000
Subject: [issue33064] lib2to3 fails on a trailing comma after **kwargs in a
 function signature
In-Reply-To: <1520909430.12.0.467229070634.issue33064@psf.upfronthosting.co.za>
Message-ID: <1520979595.12.0.467229070634.issue33064@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33064>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:24:22 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 13 Mar 2018 22:24:22 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520979862.26.0.467229070634.issue33073@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Serhiy, we already went down the path of implementing this as a method.   Of course `numbers.Rational` could define the method as `return (self.numerator, self.denominator)` for itself and its subclasses.  Unless I'm confused, that would "magically" define the method for (at least) ints and Fractions too - but I didn't try it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:29:15 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Mar 2018 22:29:15 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
In-Reply-To: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>
Message-ID: <1520980155.6.0.467229070634.issue33047@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I cannot reproduce this on Ubuntu 16.04.

----------
nosy: +belopolsky, paul.moore, pitrou, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33047>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:31:13 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Mar 2018 22:31:13 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1520980273.74.0.467229070634.issue22872@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The expected behaviour here would be to raise ValueError, as on other closed objects:

>>> s = io.StringIO()
>>> s.close()
>>> s.write("")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

----------
nosy: +pitrou
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:31:22 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Mar 2018 22:31:22 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1520980282.3.0.467229070634.issue22872@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib) -ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:31:40 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 13 Mar 2018 22:31:40 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520980300.17.0.467229070634.issue33073@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Actually numbers.Rational is a virtual base class for int, so it won't automagically appear there.

Adding it to the math module is inferior because for non-rational types (e.g. alternative float implementations) the math module won't have the knowledge about internals to implement it -- and casting to float() would defeat the purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 18:57:54 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 13 Mar 2018 22:57:54 +0000
Subject: [issue32987] tokenize.py parses unicode identifiers incorrectly
In-Reply-To: <1520033569.84.0.467229070634.issue32987@psf.upfronthosting.co.za>
Message-ID: <1520981874.54.0.467229070634.issue32987@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I believe this may be a duplicate of issue 12486.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32987>
_______________________________________

From report at bugs.python.org  Tue Mar 13 19:02:02 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 13 Mar 2018 23:02:02 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1520982122.53.0.467229070634.issue27910@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Tomas,

Would you be willing to make a Github pull request with your patch?  Thanks.

----------
nosy: +csabella
stage: commit review -> needs patch
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Tue Mar 13 19:09:41 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 13 Mar 2018 23:09:41 +0000
Subject: [issue27902] pstats.Stats: strip_dirs() method cannot handle file
 paths from different OS
In-Reply-To: <1472590175.77.0.992836532809.issue27902@psf.upfronthosting.co.za>
Message-ID: <1520982581.62.0.467229070634.issue27902@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27902>
_______________________________________

From report at bugs.python.org  Tue Mar 13 19:26:20 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 13 Mar 2018 23:26:20 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1520983580.57.0.467229070634.issue33073@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Thanks, Guido!  I figured I was missing something :-)

It looks like `numbers.Rational` _is_ a "for real" base class of `fractions.Fraction`, though, so I'm in favor of supplying a default implementation of `.as_integer_ratio()` in `numbers.Rational` anyway.  That would make a clear statement of intent, and would do the right thing for `Fraction` instances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 19:43:24 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 13 Mar 2018 23:43:24 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520983580.57.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLwKV0BCDuNWF9HAvfLiBLgxJSy5vgsgVnWTSYkTUUNcg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

+1.

On Tue, Mar 13, 2018, 16:26 Tim Peters <report at bugs.python.org> wrote:

>
> Tim Peters <tim at python.org> added the comment:
>
> Thanks, Guido!  I figured I was missing something :-)
>
> It looks like `numbers.Rational` _is_ a "for real" base class of
> `fractions.Fraction`, though, so I'm in favor of supplying a default
> implementation of `.as_integer_ratio()` in `numbers.Rational` anyway.  That
> would make a clear statement of intent, and would do the right thing for
> `Fraction` instances.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33073>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Tue Mar 13 19:47:12 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 13 Mar 2018 23:47:12 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1520984832.08.0.467229070634.issue28612@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

IDLE just added similar functionality to pyparse (issue 32940) using:

    class ParseMap(dict):
        def __missing__(self, key):
            return 120 # ord('x')

    # Map all ascii to 120 to avoid __missing__ call, then replace some.
    trans = ParseMap.fromkeys(range(128), 120)
    trans.update((ord(c), ord('(')) for c in "({[")  # open brackets => '(';
    trans.update((ord(c), ord(')')) for c in ")}]")  # close brackets => ')'.
    trans.update((ord(c), ord(c)) for c in "\"'\\\n#") # Keep these.

    code = code.translate(trans)

Of course, all that is probably too much for a docs example, but it uses a mapping without the side effect of defaultdict.  I wonder if defining the dict subclass with __missing__ and then the example of keeping only lowercase letters would work for the docs?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Tue Mar 13 20:40:12 2018
From: report at bugs.python.org (Sumana Harihareswara)
Date: Wed, 14 Mar 2018 00:40:12 +0000
Subject: [issue33071] Document that PyPI no longer requires 'register'
In-Reply-To: <1520950887.05.0.467229070634.issue33071@psf.upfronthosting.co.za>
Message-ID: <1520988012.1.0.467229070634.issue33071@psf.upfronthosting.co.za>


Change by Sumana Harihareswara <sh at changeset.nyc>:


----------
nosy: +sumanah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33071>
_______________________________________

From report at bugs.python.org  Tue Mar 13 21:08:58 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Mar 2018 01:08:58 +0000
Subject: [issue32987] tokenize.py parses unicode identifiers incorrectly
In-Reply-To: <1520033569.84.0.467229070634.issue32987@psf.upfronthosting.co.za>
Message-ID: <1520989738.02.0.467229070634.issue32987@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think the issues are slightly different.  #12486 is about the awkwardness of the API.  This is about a false error after jumping through the hoops, which I think Steve B did correctly.

Following the link, the Other_ID_Continue chars are

00B7          ; Other_ID_Continue # Po       MIDDLE DOT
0387          ; Other_ID_Continue # Po       GREEK ANO TELEIA
1369..1371    ; Other_ID_Continue # No   [9] ETHIOPIC DIGIT ONE..ETHIOPIC DIGIT NINE
19DA          ; Other_ID_Continue # No       NEW TAI LUE THAM DIGIT ONE

# Total code points: 12

The 2 Po chars fail, the 2 No chars work.  After looking at the tokenize module, I believe the problem is the re for Name is r'\w+' and the Po chars are not seen as \w word characters.

>>> r = re.compile(r'\w+', re.U)  
>>> re.match(r, 'ab\u0387cd')
<re.Match object; span=(0, 2), match='ab'>

I don't know if the bug is a too narrow definition of \w in the re module("most characters that can be part of a word in any language, as well as numbers and the underscore") or of Name in the tokenize module.

Before patching anything, I would like to know if the 2 Po Other chars are the only 2 not matched by \w.  Unless someone has done so already, at least a sample of chars from each category included in the definition of 'identifier' should be tested.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32987>
_______________________________________

From report at bugs.python.org  Tue Mar 13 22:12:47 2018
From: report at bugs.python.org (Martin Panter)
Date: Wed, 14 Mar 2018 02:12:47 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1520993567.3.0.467229070634.issue33062@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I have also wanted to force renegotation for testing with Python.

As a workaround, I have used the "openssl s_server" program, which I described at <https://bugs.python.org/issue25919#msg257508> (use the lower-case "r" command). More recently I did a similar thing with "s_client", where you have to use capital "R".

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Tue Mar 13 23:08:31 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 14 Mar 2018 03:08:31 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1520996911.82.0.467229070634.issue33062@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

PyOpenSSL supports renegotiation, and I've used it for writing exactly this kind of test. Might be easier than wrapping a test harness around the 'openssl' command.

For extra fun, openssl itself doesn't fully support renegotiation on duplex connections, even if your code works correctly: http://openssl.6102.n7.nabble.com/TLS-renegotiation-failure-on-receiving-application-data-during-handshake-td48127.html

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Tue Mar 13 23:34:01 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Mar 2018 03:34:01 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1520998441.78.0.467229070634.issue27984@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Thanks for the reminding, I already forget this. I'll do it night.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Tue Mar 13 23:40:28 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 03:40:28 +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: <1520998828.07.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 94552448d7bcc1eebc53b608e89d96e235054f2f by Ned Deily in branch '3.6':
bpo-32726: macOS installer changes for 3.6.5
https://github.com/python/cpython/commit/94552448d7bcc1eebc53b608e89d96e235054f2f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 14 01:12:56 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 05:12:56 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1521004376.32.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Backport the new 10.9+ installer variant from 3.7 to 3.6 for 3.6.5:

The rationale is that, while the 10.6 variant is still upwards compatible on current systems, it is showing its age.  Apple has started deprecating 32-bit support on macOS and apparently plans to drop it entirely in an upcoming release.  Also this gives a way to finally provide batteries-included Tcl/Tk support (the single most-requested feature for the macOS installers) and move to Tcl/Tk 8.6.x which is not well supported on older macOS releases (ActiveState currently only supplies 8.6.x binaries for macOS 10.9+, for example).  For 3.6.5, the 10.9+ variant will be offered as an additional alternative to the traditional 10.6+ variant in earlier 3.6.x releases.  I expect that most Binary extension modules (including wheels) built for earlier versions of 3.6.x with the 10.6 variant should continue to work with either 3.6.5 variant without recompilation.  This perhaps will also make it easier to transition to the 10.9+ variant as the default for 3.7.0.

In addition, both installer variants have updated 3rd-party libraries:
OpenSSL 1.0.2m -> 1.0.2n
XZ 5.2.2 -> 5.2.3
SQLite 3.21.0 -> 3.22.0

The 10.6 variant now sets CC=gcc instead of CC=gcc-4.2 and does not search for the outdated 10.6 SDK.  The variant is built with the same compiler as before.  If necessary for extension module builds, the CC value can be overridden with the CC env variable and an SDK can be specified with the SDKROOT env variable (see man xcrun).  These minor changes should be transparent to nearly all users.

----------
stage: patch review -> backport needed
title: macOS installer and framework enhancements and changes for 3.7.0 -> macOS installer and framework enhancements and changes for 3.7.0 and 3.6.5
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 14 01:23:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 05:23:09 +0000
Subject: [issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and
 difflib (CVE-2018-1061)
In-Reply-To: <1519950979.87.0.467229070634.issue32981@psf.upfronthosting.co.za>
Message-ID: <1521004989.74.0.467229070634.issue32981@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> Is this ready to close?

The fixes are now available from the cpython repo for all current security and maintenance branches (3.4 to 3.7 plus 2.7).  They are now released in 3.6.5rc1 and will be available in the next releases of other branches: 3.7.0, 3.5.6, 3.4.9, and 2.7.15.

Thanks again for reporting the issues, James, and helping to resolve them!

----------
nosy: +ned.deily
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32981>
_______________________________________

From report at bugs.python.org  Wed Mar 14 01:39:44 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 05:39:44 +0000
Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does
 not validate strings
In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za>
Message-ID: <1521005984.03.0.467229070634.issue32367@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

And Red Hat has already closed their version of this as NOTABUG:
 
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-17522

It seems nearly everyone is agreement that this is not a security issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32367>
_______________________________________

From report at bugs.python.org  Wed Mar 14 01:41:18 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Wed, 14 Mar 2018 05:41:18 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1521006078.9.0.467229070634.issue33062@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

> For extra fun, openssl itself doesn't fully support renegotiation on duplex connections ...

The necessitated modification to the application protocol on that thread sounds like an OpenSSL cop-out. There is no good reason that OpenSSL shouldn't be able to cache incoming application data during the client-initiated handshake just as it does at other times. It should be able to cache the incoming pre-negotiation records, decoding them. The pending() check would inform the client that they need to reap the incoming data during the handshake too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Wed Mar 14 01:54:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 05:54:57 +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: <1521006897.93.0.467229070634.issue32686@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

A followup: a fix for the hang in test_asyncio has been released in 3.6.5rc1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:04:11 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 14 Mar 2018 06:04:11 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1521007451.46.0.467229070634.issue33062@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> an OpenSSL cop-out

Perhaps, but they've been doing it this way for a decade+, and we're living in a time when other libraries like BoringSSL are flat-out removing renegotiation support, so good luck convincing them to fix things. Anyway, it's nothing to do with Python, just a friendly heads-up; I ran into this when trying to do renegotiation tests on my non-blocking code using the 'ssl' module and was *very* confused for a while until I realized it wasn't my code's fault at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:07:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 06:07:50 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1521007670.63.0.467229070634.issue30697@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

It's been three months since Anthony raised the question about whether this was an acceptable ABI change in 3.6.4.  Since then, I am not aware of any reports of problems this has caused and there has been no agreement that it is a critical problem.  Since 3.6.5rc1 has now been released without this being resolved, I'm going to close this issue and hope for the best.  Thanks, everyone!  Feel free to reopen if a real life problem can be demonstrated.

----------
priority: deferred blocker -> 
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:34:12 2018
From: report at bugs.python.org (Robert Xiao)
Date: Wed, 14 Mar 2018 06:34:12 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
Message-ID: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

Environment: Python 3.6.4, macOS 10.12.6

Python 3's dbm appears to corrupt the key index on macOS if objects >4KB are inserted.

Code:

<<<<<<<<<<<
import dbm
import contextlib

with contextlib.closing(dbm.open('test', 'n')) as db:
    for k in range(128):
        db[('%04d' % k).encode()] = b'\0' * (k * 128)

with contextlib.closing(dbm.open('test', 'r')) as db:
    print(len(db))
    print(len(list(db.keys())))
>>>>>>>>>>>

On my machine, I get the following:

<<<<<<<<<<<
94
Traceback (most recent call last):
  File "test.py", line 10, in <module>
    print(len(list(db.keys())))
SystemError: Negative size passed to PyBytes_FromStringAndSize
>>>>>>>>>>>

(The error says PyString_FromStringAndSize on Python 2.x but is otherwise the same). The expected output, which I see on Linux (using gdbm), is

128
128

I get this error with the following Pythons on my system:

/usr/bin/python2.6 - Apple-supplied Python 2.6.9
/usr/bin/python - Apple-supplied Python 2.7.13
/opt/local/bin/python2.7 - MacPorts Python 2.7.14
/usr/local/bin/python - Python.org Python 2.7.13
/usr/local/bin/python3.5 - Python.org Python 3.5.1
/usr/local/bin/python3.6 - Python.org Python 3.6.4

This seems like a very big problem - silent data corruption with no warning. It appears related to issue30388, but in that case they were seeing sporadic failures. The deterministic script above causes failures in every case.

This was discovered after running some code which used shelve (which uses dbm under the hood) in Python 3, but the bug clearly applies to Python 2 as well.

----------
files: test.db
messages: 313809
nosy: nneonneo
priority: normal
severity: normal
status: open
title: dbm corrupts index on macOS (_dbm module)
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47484/test.db

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:35:02 2018
From: report at bugs.python.org (Robert Xiao)
Date: Wed, 14 Mar 2018 06:35:02 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1521009302.86.0.467229070634.issue33074@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

(Note: the contextlib stuff is just for Python 2 compatibility, it's not necessary on Python 3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:36:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 06:36:51 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1521009411.2.0.467229070634.issue33074@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:40:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Mar 2018 06:40:28 +0000
Subject: [issue30622] Fix NPN guard for OpenSSL 1.1
In-Reply-To: <1497107294.71.0.653300932954.issue30622@psf.upfronthosting.co.za>
Message-ID: <1521009628.67.0.467229070634.issue30622@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 0ec0290a075ad3ac7d9990efd701c81da16293c0 by Christian Heimes in branch '3.6':
bpo-30622: Fix backport of NPN fix (#6102)
https://github.com/python/cpython/commit/0ec0290a075ad3ac7d9990efd701c81da16293c0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30622>
_______________________________________

From report at bugs.python.org  Wed Mar 14 02:49:35 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 06:49:35 +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: <1521010175.87.0.467229070634.issue32517@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +5875

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Wed Mar 14 03:07:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 07:07:38 +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: <1521011258.57.0.467229070634.issue32517@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +5876

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Wed Mar 14 03:13:36 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 07:13: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: <1521011616.16.0.467229070634.issue32517@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the fix, Nathan.  Yury has already committed the fix for 3.6.5 and for 3.7.0.  I've just pushed PR 6112 and PR 6113 to forward port to the master branch (for 3.8) and to re-enable the failing tests on 3.7 and master.  Once they are merged, I think we can close this.

----------
priority: release blocker -> 
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Wed Mar 14 03:24:12 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Wed, 14 Mar 2018 07:24:12 +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: <1521012252.67.0.467229070634.issue32517@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

Awesome, I'm really excited to have contributed something, no matter how small.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Wed Mar 14 04:02:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Mar 2018 08:02:11 +0000
Subject: [issue32987] tokenize.py parses unicode identifiers incorrectly
In-Reply-To: <1520033569.84.0.467229070634.issue32987@psf.upfronthosting.co.za>
Message-ID: <1521014531.52.0.467229070634.issue32987@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This issue and issue12486 doesn't have any common except that both are related to the tokenize module.

There are two bugs: a too narrow definition of \w in the re module (see  issue12731 and issue1693050) and a too narrow definition of Name in the tokenize module.


>>> allchars = list(map(chr, range(0x110000)))
>>> start = [c for c in allchars if c.isidentifier()]
>>> cont = [c for c in allchars if ('a'+c).isidentifier()]
>>> import re, regex, unicodedata

>>> for c in regex.findall(r'\W', ''.join(start)): print('%r  U+%04X  %s' % (c, ord(c), unicodedata.name(c, '?')))
... 
'?'  U+2118  SCRIPT CAPITAL P
'?'  U+212E  ESTIMATED SYMBOL
>>> for c in regex.findall(r'\W', ''.join(cont)): print('%r  U+%04X  %s' % (c, ord(c), unicodedata.name(c, '?')))
... 
'?'  U+00B7  MIDDLE DOT
'?'  U+0387  GREEK ANO TELEIA
'?'  U+1369  ETHIOPIC DIGIT ONE
'?'  U+136A  ETHIOPIC DIGIT TWO
'?'  U+136B  ETHIOPIC DIGIT THREE
'?'  U+136C  ETHIOPIC DIGIT FOUR
'?'  U+136D  ETHIOPIC DIGIT FIVE
'?'  U+136E  ETHIOPIC DIGIT SIX
'?'  U+136F  ETHIOPIC DIGIT SEVEN
'?'  U+1370  ETHIOPIC DIGIT EIGHT
'?'  U+1371  ETHIOPIC DIGIT NINE
'?'  U+19DA  NEW TAI LUE THAM DIGIT ONE
'?'  U+2118  SCRIPT CAPITAL P
'?'  U+212E  ESTIMATED SYMBOL
>>> for c in re.findall(r'\W', ''.join(start)): print('%r  U+%04X  %s' % (c, ord(c), unicodedata.name(c, '?')))
... 
'?'  U+1885  MONGOLIAN LETTER ALI GALI BALUDA
'?'  U+1886  MONGOLIAN LETTER ALI GALI THREE BALUDA
'?'  U+2118  SCRIPT CAPITAL P
'?'  U+212E  ESTIMATED SYMBOL
>>> for c in re.findall(r'\W', ''.join(cont)): print('%r  U+%04X  %s' % (c, ord(c), unicodedata.name(c, '?')))
... 
'?'  U+00B7  MIDDLE DOT
'?'  U+0300  COMBINING GRAVE ACCENT
'?'  U+0301  COMBINING ACUTE ACCENT
'?'  U+0302  COMBINING CIRCUMFLEX ACCENT
'?'  U+0303  COMBINING TILDE
...
[total 2177 characters]

The second bug can be solved by adding 14 more characters in the pattern for Name.

    Name = r'[\w\xb7\u0387\u1369-\u1371\u19da\u2118\u212e]+'

or

    Name = r'[\w\u2118\u212e][\w\xb7\u0387\u1369-\u1371\u19da\u2118\u212e]*'

But first the issue with \w should be resolved (if we don't want to add 2177 characters).

The other solution is implementing property support in re (issue12734).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32987>
_______________________________________

From report at bugs.python.org  Wed Mar 14 06:35:40 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Mar 2018 10:35:40 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521023740.9.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

https://github.com/python/cpython/commit/b4d1e1f7c1af6ae33f0e371576c8bcafedb099db (the first attempted fix for bpo-20891) is the last commit where the draft test case patch applies cleanly.

That still segfaults, so I'll jump all the way back to 3.7.0a1, rework the patch to apply there, and see if pre-init use of these APIs were still working back then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Wed Mar 14 07:45:18 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Mar 2018 11:45:18 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521027918.5.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After reworking the patch to backport the pre-initialization embedding tests to 3.7.0a1, they *both* failed, as that was before Victor fixed Py_DecodeLocale to work prior to initialization again.

As a result, I tried https://github.com/python/cpython/commit/43605e6bfa8d49612df4a38460d063d6ba781906 in November, after the initial merge of the PEP 432 working branch, but just before the start of Victor's follow on refactoring to really take advantage of the new internal structures: double failure there as well.

https://github.com/python/cpython/commit/f5ea83f4864232fecc042ff0d1c2401807b19280 is the next point I checked (just before Eric's September changes to global state management), and it looks like we have a new chief suspect, as applying the attached "earlier-tree" version of the patch at this point in the history gives two passing test cases :)

Next I'll work out a git bisect run based on those two start and end commits and the "earlier-tree" patch, and attempt to narrow the failure down to a specific commit (probably tomorrow).


(Even without that bisect run though, the warnoptions changes in https://github.com/python/cpython/commit/2ebc5ce42a8a9e047e790aefbf9a94811569b2b6#diff-f38879f4833a6b6847e556b9a07bf4ed are now looking *very* suspicious)

----------
Added file: https://bugs.python.org/file47485/bpo-33042-earlier-tree-test-case.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Wed Mar 14 07:47:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Mar 2018 11:47:16 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521028036.43.0.467229070634.issue33042@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I suggest to revert my changes on PySys_AddWarnOption*() and "just" re-use the code from Python 3.6.

Previously, I made the code more complex since I had to expose a private function to add manually warning options. But later, the code changed again, so the private function is gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Wed Mar 14 08:27:53 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Mar 2018 12:27:53 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521030473.86.0.467229070634.issue27984@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Revising the patch, register() is fixed by feature in #32227. So I will only fix dispatch() in 3.7 and 3.8, the whole patch to 3.6.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Wed Mar 14 09:02:59 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Mar 2018 13:02:59 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521032579.44.0.467229070634.issue27984@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5877

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Wed Mar 14 09:11:00 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Mar 2018 13:11:00 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521033060.47.0.467229070634.issue27984@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5878

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Wed Mar 14 09:25:09 2018
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 14 Mar 2018 13:25:09 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
Message-ID: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>


New submission from Vlad Shcherbina <vlad.shcherbina at gmail.com>:

from typing import *

def f(arg: str = None):
    pass
print(get_type_hints(f))

# {'arg': typing.Union[str, NoneType]}
# as expected


class T(NamedTuple):
    field: str = None
print(get_type_hints(T))

# {'field': <class 'str'>}
# but it should be
# {'field': typing.Union[str, NoneType]}
# for consistency

----------
components: Library (Lib)
messages: 313819
nosy: vlad
priority: normal
severity: normal
status: open
title: typing.NamedTuple does not deduce Optional[] from using None as default field value
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 09:28:34 2018
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 14 Mar 2018 13:28:34 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
In-Reply-To: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>
Message-ID: <1521034114.86.0.467229070634.issue33075@psf.upfronthosting.co.za>


Vlad Shcherbina <vlad.shcherbina at gmail.com> added the comment:

If the maintainers agree that it's desirable to automatically deduce optionality, I'll implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 10:17:09 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Mar 2018 14:17:09 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521037029.78.0.467229070634.issue33069@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the report and pull request. Do you happen to know if setuptools is also affected?

If yes, the problem will need to be reported & fixed there as well (otherwise the maintainer metadata will still be missing for many publishers), if no, then using it instead of plain distutils is a potential workaround in advance of the distutils fix rolling it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Wed Mar 14 10:18:58 2018
From: report at bugs.python.org (Jeremy Metz)
Date: Wed, 14 Mar 2018 14:18:58 +0000
Subject: [issue5441] Convenience API for timeit.main
In-Reply-To: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za>
Message-ID: <1521037138.66.0.467229070634.issue5441@psf.upfronthosting.co.za>


Jeremy Metz <metz.jp at gmail.com> added the comment:

Don't understand how #6422 addresses this - would also like to see a more convenient API for timing; at present CLI gives a nice formatted output, and timeit.timeit gives just the raw timing in seconds. 

Would be easy to implement by simply refactoring main() in to the command line parsing component (first ~ 50 lines from https://github.com/python/cpython/blob/master/Lib/timeit.py#L256 to ~https://github.com/python/cpython/blob/master/Lib/timeit.py#L312 ) and actual timing and printing component, which could then be called via API. 

Am happy to work this up if this can be reopened...?

----------
nosy: +Jeremy Metz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5441>
_______________________________________

From report at bugs.python.org  Wed Mar 14 10:22:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Mar 2018 14:22:32 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521037352.76.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While I haven't definitely narrowed it down yet, I suspect it isn't your changes that are the problem: since the reported crash relates to attempting to access a not-yet-created thread state, `warnoptions` and `_xoptions` likely need to become C level globals again for 3.7 (along with anything needed to create list and Unicode objects).

We can then transfer them from there into Eric's new runtime state objects in _PyRuntime_Initialize (or potentially _Py_InitializeCore).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Wed Mar 14 10:39:49 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 14 Mar 2018 14:39:49 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521038389.42.0.467229070634.issue33069@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

@ncoghlan Yes, setuptools is affected. I've reported it there as well: https://github.com/pypa/setuptools/issues/1288

I have patches for both distutils and setuptools prepared. The distutils patch is more controversial because this is apparently the documented behavior of PEP 314's Metadata Version 1.1, and distutils doesn't really have support for any of the *other* features of Version 1.2. You can see the concern (mostly on my side, frankly) on the PR, GH PR #6106.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Wed Mar 14 11:02:20 2018
From: report at bugs.python.org (Jeremy Metz)
Date: Wed, 14 Mar 2018 15:02:20 +0000
Subject: [issue5441] Convenience API for timeit.main
In-Reply-To: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za>
Message-ID: <1521039740.96.0.467229070634.issue5441@psf.upfronthosting.co.za>


Jeremy Metz <metz.jp at gmail.com> added the comment:

More specifically, #6422 also mentions at least in part this functionality, but the main focus there seems to be the autorange function. 

Propose splitting these two by reopening this use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5441>
_______________________________________

From report at bugs.python.org  Wed Mar 14 11:08:06 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 14 Mar 2018 15:08:06 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521040086.94.0.467229070634.issue33069@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think that the proposed change is a good thing in itself, but if distutils only supports metadata 1.1 then it should comply with that spec.

I expect most projects to be using setuptools these days (to support wheels for one thing), so keeping distutils unchanged and fixing setuptools may be the best path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Wed Mar 14 11:16:06 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 14 Mar 2018 15:16:06 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521040566.51.0.467229070634.issue33069@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

One thing that's unclear to me is whether PKG-INFO metadata spec should be considered exhaustive or whether you can add additional fields and still be considered compliant with the spec. If the latter is true, I think there's some case to be made for populating Maintainer: and Maintainer-Email: even in a purely Metadata-Version: 1.1 PKG-INFO file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Wed Mar 14 11:43:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 15:43:58 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
In-Reply-To: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>
Message-ID: <1521042238.94.0.467229070634.issue33075@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 12:13:14 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 14 Mar 2018 16:13:14 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
In-Reply-To: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>
Message-ID: <1521043994.32.0.467229070634.issue33075@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This is actually an intended behaviour. Moreover, the implicit optionality of arguments that default to `None` is deprecated and will be removed in one of the future versions. (Note that since typing module is still provisional, this will likely happen without any additional notice.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 13:16:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Mar 2018 17:16:23 +0000
Subject: [issue25054] Capturing start of line '^'
In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za>
Message-ID: <1521047783.53.0.467229070634.issue25054@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/issue25054>
_______________________________________

From report at bugs.python.org  Wed Mar 14 13:17:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Mar 2018 17:17:12 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1521047832.35.0.467229070634.issue1647489@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/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Mar 14 13:52:25 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Mar 2018 17:52:25 +0000
Subject: [issue32885] Tools/scripts/pathfix.py leaves bunch of ~ suffixed
 files around with no opt-out
In-Reply-To: <1519124808.65.0.467229070634.issue32885@psf.upfronthosting.co.za>
Message-ID: <1521049945.44.0.467229070634.issue32885@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset a954919788f2130076e4f9dd91e9eccf69540f7a by Christian Heimes (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-32885: Tools/scripts/pathfix.py: Add -n option for no backup~ (GH-5772) (#6104)
https://github.com/python/cpython/commit/a954919788f2130076e4f9dd91e9eccf69540f7a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32885>
_______________________________________

From report at bugs.python.org  Wed Mar 14 13:52:31 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Mar 2018 17:52:31 +0000
Subject: [issue32885] Tools/scripts/pathfix.py leaves bunch of ~ suffixed
 files around with no opt-out
In-Reply-To: <1519124808.65.0.467229070634.issue32885@psf.upfronthosting.co.za>
Message-ID: <1521049951.85.0.467229070634.issue32885@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 6e65e4462692cbf4461c307a411af7cf40a1ca4a by Christian Heimes (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-32885: Tools/scripts/pathfix.py: Add -n option for no backup~ (GH-5772) (#6103)
https://github.com/python/cpython/commit/6e65e4462692cbf4461c307a411af7cf40a1ca4a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32885>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:03:00 2018
From: report at bugs.python.org (Tomas Orsava)
Date: Wed, 14 Mar 2018 18:03:00 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1521050580.71.0.467229070634.issue27910@psf.upfronthosting.co.za>


Change by Tomas Orsava <tomas.n at orsava.cz>:


----------
pull_requests: +5879
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:03:55 2018
From: report at bugs.python.org (Tomas Orsava)
Date: Wed, 14 Mar 2018 18:03:55 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1521050635.46.0.467229070634.issue27910@psf.upfronthosting.co.za>


Tomas Orsava <tomas.n at orsava.cz> added the comment:

Hey Cheryl,
here is the pull request: https://github.com/python/cpython/pull/6116

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:10:03 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 14 Mar 2018 18:10:03 +0000
Subject: [issue26450] make html fails on OSX
In-Reply-To: <1456626666.41.0.889799405397.issue26450@psf.upfronthosting.co.za>
Message-ID: <1521051003.71.0.467229070634.issue26450@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

With the new instructions for building the docs via `make venv` and then `make html`, I believe this issue can be closed.

----------
nosy: +csabella
resolution: not a bug -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26450>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:14:57 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Mar 2018 18:14:57 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1521051297.82.0.467229070634.issue32968@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the PR (and apologies for being slow to look at it). I think we want to use the operator_fallbacks approach for both __rfloordiv__ and __floordiv__ (and similarly for __rmod__ and __mod__), else we'll get inconsistent results:

>>> Fraction(3) // 5.0  # get float, as expected
0.0
>>> 3.0 // Fraction(5)  # expect a float, get an integer
0

Please could you make that change and add a couple more tests that cover this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:18:57 2018
From: report at bugs.python.org (Ben Feinstein)
Date: Wed, 14 Mar 2018 18:18:57 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <1521051537.16.0.467229070634.issue33057@psf.upfronthosting.co.za>


Ben Feinstein <feinsteinben at gmail.com> added the comment:

Here is a code that demonstrate the bug:

```python
import logging

class LogRecordTypeFilter(logging.Filter):
    def __init__(self, cls):
        self.cls = cls

    def filter(self, record):
        t = type(record)
        if t is not self.cls:
            msg = 'Unexpected LogRecord type %s, expected %s' % (t, self.cls)
            raise TypeError(msg)
        return True

class MyLogRecord(logging.LogRecord):
    pass

manager = logging.Manager(None)
manager.setLogRecordFactory(MyLogRecord)
logger = manager.getLogger('some_logger')
logger.addFilter(LogRecordTypeFilter(MyLogRecord))

try:
    logger.error('bpo-33057')
except TypeError as e:
    print(e)  # output: Unexpected LogRecord type <class 'logging.LogRecord'>, expected <class '__main__.MyLogRecord'>
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:46:11 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 14 Mar 2018 18:46:11 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
In-Reply-To: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>
Message-ID: <1521053171.93.0.467229070634.issue33075@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This bug report can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 14:48:30 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 14 Mar 2018 18:48:30 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
In-Reply-To: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>
Message-ID: <1521053310.38.0.467229070634.issue33075@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 15:03:02 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 14 Mar 2018 19:03:02 +0000
Subject: [issue33075] typing.NamedTuple does not deduce Optional[] from using
 None as default field value
In-Reply-To: <1521033909.39.0.467229070634.issue33075@psf.upfronthosting.co.za>
Message-ID: <1521054182.24.0.467229070634.issue33075@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33075>
_______________________________________

From report at bugs.python.org  Wed Mar 14 15:07:24 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 14 Mar 2018 19:07:24 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521054444.43.0.467229070634.issue33021@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +5880

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Wed Mar 14 15:09:47 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 14 Mar 2018 19:09:47 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521054587.15.0.467229070634.issue33021@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

Commit 4484f9dca9149da135bbae035f10a50d20d1cbbb causes GCC 7.2.0 to emit a warning.

cpython/Modules/mmapmodule.c: In function ?new_mmap_object?:
cpython/Modules/mmapmodule.c:1126:18: warning: ?fstat_result? may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (fd != -1 && fstat_result == 0 && S_ISREG(status.st_mode)) {

A PR is attached.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Wed Mar 14 16:08:10 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Mar 2018 20:08:10 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521058090.25.0.467229070634.issue33021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset d6e140466142018ddbb7541185348be2b833a2ce by Antoine Pitrou (Zackery Spytz) in branch 'master':
bpo-33021: Fix GCC 7 warning (-Wmaybe-uninitialized) in mmapmodule.c (#6117)
https://github.com/python/cpython/commit/d6e140466142018ddbb7541185348be2b833a2ce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Wed Mar 14 16:09:00 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 20:09:00 +0000
Subject: [issue31974] Cursor misbahavior with Tkinter 3.6.1/tk 8.5 Text on Mac
 Sierra
In-Reply-To: <1510106215.52.0.213398074469.issue31974@psf.upfronthosting.co.za>
Message-ID: <1521058140.19.0.467229070634.issue31974@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Update: for Python 3.6.5 and 3.7.0, there are new python.org 10.9+ installer variants that come with a built-in Tcl/Tk 8.6.8.  They are currently both available in testing pre-releases (3.6.5rc1 and 3.7.0b2):

https://www.python.org/download/pre-releases/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31974>
_______________________________________

From report at bugs.python.org  Wed Mar 14 16:10:30 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Mar 2018 20:10:30 +0000
Subject: [issue25750] tp_descr_get(self, obj,
 type) is called without owning a reference to "self"
In-Reply-To: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za>
Message-ID: <1521058230.11.0.467229070634.issue25750@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5881

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25750>
_______________________________________

From report at bugs.python.org  Wed Mar 14 16:10:30 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Mar 2018 20:10:30 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521058230.8.0.467229070634.issue33021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With Benjamin we've decided that this wouldn't happen in 2.7.  Performance improvements don't warrant a backport.

Thank you Nir for reporting and posting the patches!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Wed Mar 14 16:50:54 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Wed, 14 Mar 2018 20:50:54 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1521060654.87.0.467229070634.issue33036@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

Hmmm, still failing for me. I wonder if it's something specific to my machine.

```
git reset --hard 3.6 && make clean && git pull && ./configure --with-pydebug && make -j && ./python.exe -m unittest -v test.test_selectors.PollSelectorTestCase.test_above_fd_setsize
```

Related:

- https://bugs.python.org/issue18963
- https://bugs.python.org/issue21901

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Wed Mar 14 17:14:36 2018
From: report at bugs.python.org (Adrien)
Date: Wed, 14 Mar 2018 21:14:36 +0000
Subject: [issue33076] Trying to cleanly terminate a threaded Queue at exit of
 program raises an "EOFError"
Message-ID: <1521062076.69.0.467229070634.issue33076@psf.upfronthosting.co.za>


New submission from Adrien <delgan.py at gmail.com>:

Hi.

I use a worker Thread to which I communicate trough a multiprocessing Queue. I would like to properly close this daemon thread when my program terminates, so I registered a "stop()" function using "atexit.register()".

However, this raises an "EOFError" because the multiprocessing module uses "atexit.register()" too and closes the Queue internal pipe connections before that my thread ends.

After scratching inside the multiprocessing module, I tried to summarize my understanding of the problem here: https://stackoverflow.com/a/49244528/2291710

I joined a demonstration script that triggers the bug with (at least) Python 3.5/3.6 on both Windows and Linux.

The issue is fixable by forcing multiprocessing "atexit.register()" before mine with "import multiprocessing.queues", but this means I would rely on an implementation detail, and others dynamic calls made to "atexit.register()" (like one I saw in multiprocessing "get_logger()" for example) could break it again.
I first thought that "atexit.register()" could accept an optional "priority" argument, but every developers would probably want to be first. Could a subtle change be made however to guarantee that registered functions are executed before Python internal ones? As for now, the atexit statement "The assumption is that lower level modules will normally be imported before higher level modules and thus must be cleaned up later" is not quite true.

I do not know what to do with it, from what I know there is no way to achieve an automatic yet clean closure of such worker, so I would like to know if some kind of fix is possible for a future version of Python.

Thanks for your time.

----------
components: Library (Lib)
files: bug.py
messages: 313841
nosy: Delgan
priority: normal
severity: normal
status: open
title: Trying to cleanly terminate a threaded Queue at exit of program raises an "EOFError"
type: behavior
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47486/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33076>
_______________________________________

From report at bugs.python.org  Wed Mar 14 18:23:48 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 14 Mar 2018 22:23:48 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521066228.25.0.467229070634.issue27984@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I'm sorry that you wasted your time on those pull requests, Xiang but:
- we cannot accept any new features for 3.6 and 3.7 anymore;
- the problem described in this issue is fixed, as you noticed yourself, by #32227.

The wrapper returned by the `@register` decorator is calling `dispatch()` with the first argument's `__class__`. It can only ever be invalid if somebody deliberately wrote something invalid to the object's `__class__`. It's extremely unlikely.

We should not slow down *calling* of all generic functions on the basis that somebody might pass a non-type straigh to `dispatch()`.

Cheryl, thanks for your help triaging the bug tracker! It might be a good idea to confirm with people on old issues whether moving the patch to a pull request is indeed the missing part of it getting merged. In this case it wasn't, I hope Xiang won't feel bad about me rejecting his pull requests after you pinged him for them.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> singledispatch support for type annotations

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Wed Mar 14 18:24:42 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Mar 2018 22:24:42 +0000
Subject: [issue32227] singledispatch support for type annotations
In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za>
Message-ID: <1521066282.0.0.467229070634.issue32227@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +5882
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32227>
_______________________________________

From report at bugs.python.org  Wed Mar 14 18:24:50 2018
From: report at bugs.python.org (=?utf-8?b?0JXQstCz0LXQvdC40Lkg0JzQsNGF0LzRg9C00L7Qsg==?=)
Date: Wed, 14 Mar 2018 22:24:50 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
Message-ID: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>


New submission from ??????? ???????? <makhmudov.evgeniy at gmail.com>:

Overwriting of default values not working, and used default value of base class. Unittest file if attachment described a problem.

----------
components: Library (Lib)
files: python_test.py
messages: 313843
nosy: ??????? ????????
priority: normal
severity: normal
status: open
title: typing: Unexpected result with value of instance of class inherited from typing.NamedTuple
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47487/python_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Wed Mar 14 19:20:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 23:20:58 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1521069658.56.0.467229070634.issue33036@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I'm not sure what to suggest other than taking a close look at and instrumenting that part of test_selectors.  One thing you could try is seeing what the call to resource.getrlimit(resource.RLIMIT_NOFILE) is returning.  You can also look at the values for your system's kernel by using the sysctl utility; see man sysctl.  For example, on my system:

>>> resource.getrlimit(resource.RLIMIT_NOFILE)
(7168, 9223372036854775807)

$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 36864

That may or may not be relevant.

Long shot: are you running under an account that does not have administrator privs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Wed Mar 14 19:23:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Mar 2018 23:23:40 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521069820.33.0.467229070634.issue33077@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Wed Mar 14 19:34:12 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 14 Mar 2018 23:34:12 +0000
Subject: [issue32227] singledispatch support for type annotations
In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za>
Message-ID: <1521070452.09.0.467229070634.issue32227@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32227>
_______________________________________

From report at bugs.python.org  Wed Mar 14 19:37:21 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Mar 2018 23:37:21 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521070641.6.0.467229070634.issue27984@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

It's all right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:12:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 00:12:21 +0000
Subject: [issue9712] tokenize yield an ERRORTOKEN if the identifier starts
 with a non-ascii char
In-Reply-To: <1283154177.7.0.16014867671.issue9712@psf.upfronthosting.co.za>
Message-ID: <1521072741.92.0.467229070634.issue9712@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Joshua opened #24194 as a duplicate of this because he could not reopen this.  I am leaving it open as the superseder for this as Serhiy has already added two dependencies there, and because this seems to be a duplicate in turn of #1693050 (which I will close along with #32987).

----------
nosy: +terry.reedy
superseder:  -> tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9712>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:18:48 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 00:18:48 +0000
Subject: [issue9712] tokenize yield an ERRORTOKEN if the identifier starts
 with a non-ascii char
In-Reply-To: <1283154177.7.0.16014867671.issue9712@psf.upfronthosting.co.za>
Message-ID: <1521073128.26.0.467229070634.issue9712@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Actually, #1693050 and #12731, about \w, are duplicates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9712>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:32:16 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 15 Mar 2018 00:32:16 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521073936.68.0.467229070634.issue33077@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks ??????? ???????? for the report!

The crux is this:

class A(NamedTuple):
    value: bool = True

class B(A):
    value: bool = False

B(True).value  # Expected True, but is False
B(True)[0]  # True as expected

If we add NamedTuple to B's bases or make its metaclass NamedTupleMeta, it works as expected.

Introspecting the classes a bit more suggests a cause: the class variable A.value is a <property ...>, but B.value is just False, and adding the extra base class or metaclass corrects this.

Ivan, you can probably tell what's wrong from this.  Maybe it's hard to fix, because NamedTuple doesn't appear in A.__mro__?  (IIRC there was a question about that somewhere recently too?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:32:39 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 00:32:39 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1521073959.39.0.467229070634.issue1693050@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whatever I may have said before, I favor supporting the Unicode standard for \w, which is related to the standard for identifiers.

This is one of 2 issues about \w being defined too narrowly.  I am somewhat arbitrarily closing this as a duplicate of #12731 (fewer digits ;-).

There are 3 issues about tokenize.tokenize failing on valid identifiers, defined as \w sequences whose first char is an identifier itself (and therefore a start char).  In msg313814 of #32987, Serhiy indicates which start and continue identifier characters are matched by \W for re and regex.  I am leaving #24194 open as the tokenizer name issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:33:15 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 00:33:15 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
 violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1521073995.86.0.467229070634.issue12731@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whatever I may have said before, I favor supporting the Unicode standard for \w, which is related to the standard for identifiers.

This is one of 2 issues about \w being defined too narrowly.  I am somewhat arbitrarily closing #1693050 as a duplicate of this (fewer digits ;-).

There are 3 issues about tokenize.tokenize failing on valid identifiers, defined as \w sequences whose first char is an identifier itself (and therefore a start char).  In msg313814 of #32987, Serhiy indicates which start and continue identifier characters are matched by \W for re and regex.  I am leaving #24194 open as the tokenizer name issue.

----------
stage: needs patch -> test needed
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:55:40 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 00:55:40 +0000
Subject: [issue24194] tokenize fails on some Other_ID_Start or
 Other_ID_Continue
In-Reply-To: <1431608427.75.0.966529056278.issue24194@psf.upfronthosting.co.za>
Message-ID: <1521075340.94.0.467229070634.issue24194@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I closed #1693050 as a duplicate of #12731 (the /w issue).  I left #9712 closed and closed #32987 and marked both as duplicates of this.

In msg313814 of the latter, Serhiy indicates which start and continue identifier characters are currently matched by \W for re and regex.  He gives there a fix for this that he says requires the /w issue to be fixed. It is similar to the posted patch.  He says that without \w fixed, another 2000+ chars need to be added.  Perhaps the v0 patch needs more tests (I don't know.)

He also says that re support for properties, #12734,  would make things even better.

Three of the characters in the patch are too obscure for Firefox on Window2 and print as boxes.  Some others I do not recognize.  And I could not type any of them.  I thought we had a policy of using \u or \U escapes even in tests to avoid such problems.  (I notice that there are already non-ascii chars in the context.)

----------
nosy: +terry.reedy
title: tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue -> tokenize fails on some Other_ID_Start or Other_ID_Continue
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24194>
_______________________________________

From report at bugs.python.org  Wed Mar 14 20:58:29 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 00:58:29 +0000
Subject: [issue32987] tokenize.py parses unicode identifiers incorrectly
In-Reply-To: <1520033569.84.0.467229070634.issue32987@psf.upfronthosting.co.za>
Message-ID: <1521075509.95.0.467229070634.issue32987@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#24194 is about tokenize failing, including on middle dot.  There is another tokenize name issue, already closed.  I referenced Serhiy's analysis there and on the two \w issues, and closed one of them.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> tokenize fails on some Other_ID_Start or Other_ID_Continue

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32987>
_______________________________________

From report at bugs.python.org  Wed Mar 14 21:21:59 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 15 Mar 2018 01:21:59 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521076919.56.0.467229070634.issue33077@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/issue33077>
_______________________________________

From report at bugs.python.org  Thu Mar 15 01:25:28 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 15 Mar 2018 05:25:28 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <1521091528.75.0.467229070634.issue33057@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The logRecordFactory attribute was added but never used and is part of an internal API (the Manager isn't documented, on purpose). Why do you need a manager-specific factory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Thu Mar 15 01:38:37 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Thu, 15 Mar 2018 05:38:37 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1521092317.53.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Mark, what you described (operator_fallbacks for both __rfloordiv__ and __floordiv__, and for both __rmod__ and __mod__) was my initial approach. But that broke one test (which floor-divides 1.0 by 1/10 and expects the result to be an integer). I thought about fixing it, to make the behavior more consistent, but I thought that was a bit risky.

Just now, I tried the change again, as you suggested, but I fixed the test to expect a result of 10.0 (a float) instead of 10 (an integer). I got a strange result from that test, saying the result was 9.0.

It seems like this is caused by rounding error, since operator_fallbacks converts both numbers to floats if one of them is a float, and 1/10 can't be represented exactly as a float, so it gets rounded to slightly more than 1/10:

>>> float(Fraction(1, 10)).as_integer_ratio()
(3602879701896397, 36028797018963968)
>>> Decimal.from_float(float(Fraction(1, 10)))
Decimal('0.1000000000000000055511151231257827021181583404541015625')

So yes, I can make that change, but I'm not sure if it would be a good idea. Do you have any thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Thu Mar 15 02:36:54 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Thu, 15 Mar 2018 06:36:54 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
Message-ID: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>


New submission from Thomas Moreau <thomas.moreau.2010 at gmail.com>:

The fix for the Queue._feeder does not properly handle the size of the Queue. This can lead to a situation where the Queue is considered as Full when it is empty. Here is a reproducing script:

```
import multiprocessing as mp

q = mp.Queue(1)


class FailPickle():
    def __reduce__(self):
        raise ValueError()

q.put(FailPickle())
print("Queue is full:", q.full())
q.put(0)
print(f"Got result: {q.get()}")
```

----------
components: Library (Lib)
messages: 313855
nosy: davin, pitrou, tomMoral
priority: normal
severity: normal
status: open
title: Queue with maxsize can lead to deadlocks
type: behavior
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/issue33078>
_______________________________________

From report at bugs.python.org  Thu Mar 15 02:42:27 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Thu, 15 Mar 2018 06:42:27 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521096147.17.0.467229070634.issue33078@psf.upfronthosting.co.za>


Change by Thomas Moreau <thomas.moreau.2010 at gmail.com>:


----------
keywords: +patch
pull_requests: +5883
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Thu Mar 15 03:36:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 07:36:21 +0000
Subject: [issue33031] Questionable code in OrderedDict definition
In-Reply-To: <1520534349.37.0.467229070634.issue33031@psf.upfronthosting.co.za>
Message-ID: <1521099381.56.0.467229070634.issue33031@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5884
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33031>
_______________________________________

From report at bugs.python.org  Thu Mar 15 03:36:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 07:36:47 +0000
Subject: [issue33031] Questionable code in OrderedDict definition
In-Reply-To: <1520534349.37.0.467229070634.issue33031@psf.upfronthosting.co.za>
Message-ID: <1521099407.66.0.467229070634.issue33031@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: patch review -> 
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33031>
_______________________________________

From report at bugs.python.org  Thu Mar 15 03:37:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 07:37:18 +0000
Subject: [issue33031] Questionable code in OrderedDict definition
In-Reply-To: <1520534349.37.0.467229070634.issue33031@psf.upfronthosting.co.za>
Message-ID: <1521099438.12.0.467229070634.issue33031@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33031>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:09:31 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Thu, 15 Mar 2018 08:09:31 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1521069658.56.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <CAOMt5FAH4rMAa0w03Lp2v69Xp565=pGRHYdnkY5b4kvdYr8pPA@mail.gmail.com>


Nathan Henrie <n8henrie at gmail.com> added the comment:

Thanks for the response -- I'll keep looking, feel free to close since it's
not being reproduced.

```
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 64000
$ ./python.exe -c 'import resource;
print(resource.getrlimit(resource.RLIMIT_NOFILE))'
(64000, 524288)
```

Nope, admin access.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:21:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 08:21:20 +0000
Subject: [issue32757] Python 2.7 : Buffer Overflow vulnerability in exec()
 function
In-Reply-To: <1517677752.38.0.467229070634.issue32757@psf.upfronthosting.co.za>
Message-ID: <1521102080.45.0.467229070634.issue32757@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32757>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:21:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 08:21:54 +0000
Subject: [issue32757] Python 2.7 : Buffer Overflow vulnerability in exec()
 function
In-Reply-To: <1517677752.38.0.467229070634.issue32757@psf.upfronthosting.co.za>
Message-ID: <1521102114.61.0.467229070634.issue32757@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type: security -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32757>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:31:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 08:31:18 +0000
Subject: [issue32805] Possible integer overflow when call PyDTrace_GC_DONE()
In-Reply-To: <1518168459.08.0.467229070634.issue32805@psf.upfronthosting.co.za>
Message-ID: <1521102678.57.0.467229070634.issue32805@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

DTrace support was implemented in issue21590 (changeset a785c87d6eacbed81543a8afe3cb098fabb9610a).

----------
nosy: +jcea
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32805>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:42:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 08:42:13 +0000
Subject: [issue32822] finally block doesn't re-raise exception if return
 statement exists inside
In-Reply-To: <1518387497.4.0.467229070634.issue32822@psf.upfronthosting.co.za>
Message-ID: <1521103333.94.0.467229070634.issue32822@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not sure that the tutorial should contain such details. But if you provide a pull request with a short and clear documenting of this behavior, it will be reviewed and may be accepted (not by me, I'm not native English and not tech writer). Otherwise this issue will be closed.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32822>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:42:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 08:42:38 +0000
Subject: [issue32822] finally block doesn't re-raise exception if return
 statement exists inside
In-Reply-To: <1518387497.4.0.467229070634.issue32822@psf.upfronthosting.co.za>
Message-ID: <1521103358.37.0.467229070634.issue32822@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
status: pending -> open
type: behavior -> enhancement
versions: +Python 2.7, Python 3.6, Python 3.7, Python 3.8 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32822>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:44:48 2018
From: report at bugs.python.org (Ben Feinstein)
Date: Thu, 15 Mar 2018 08:44:48 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1521091528.75.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <CA+U30-AySWMvGTtTRTiTW-n6DjYedd3k06qpP7DewPzK2czW=w@mail.gmail.com>


Ben Feinstein <feinsteinben at gmail.com> added the comment:

I use the logging module to log records of lab experiments. I have two
types of loggers, one for experiment results ("data") and another for
general information. I think that having a different managers for data
loggers is the easiest way to do it.

On Thu, Mar 15, 2018, 07:25 Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> The logRecordFactory attribute was added but never used and is part of an
> internal API (the Manager isn't documented, on purpose). Why do you need a
> manager-specific factory?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33057>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Thu Mar 15 04:45:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 08:45:48 +0000
Subject: [issue32825] warn user of creation of multiple Tk instances
In-Reply-To: <1518430442.75.0.467229070634.issue32825@psf.upfronthosting.co.za>
Message-ID: <1521103548.05.0.467229070634.issue32825@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

A warning will harm users that create multiple Tk instances intentionally. If it would be always bad, it should raise an error instead of a warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32825>
_______________________________________

From report at bugs.python.org  Thu Mar 15 05:04:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 09:04:25 +0000
Subject: [issue32799] <class 'contextlib._GeneratorContextManager'> returned a
 result with an error set
In-Reply-To: <1518103707.85.0.467229070634.issue32799@psf.upfronthosting.co.za>
Message-ID: <1521104665.78.0.467229070634.issue32799@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the full version of Python you used? If this is not 3.6.3 does upgrading to 3.6.3 help? Try also with 3.6.4rc1 and the beta of 3.7.

Do you use threads, forking, signal handlers? Is it synchronous or asynchronous code? Could you show the code of the function decorated with the contextmanager (or asynccontextmanager) decorator and the code that uses this context manager?

With such little information we can fix a bug only by accident, when fixing other bugs or during refactoring. And there is a chance that it is already fixed in 3.6.3, 3.6.4rc1 or 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32799>
_______________________________________

From report at bugs.python.org  Thu Mar 15 05:41:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 09:41:01 +0000
Subject: [issue32421] Keeping an exception in cache can segfault the
 interpreter
In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za>
Message-ID: <1521106861.79.0.467229070634.issue32421@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

>     for _ ? range(5):

What version of Python are you using?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32421>
_______________________________________

From report at bugs.python.org  Thu Mar 15 05:50:28 2018
From: report at bugs.python.org (Julien Palard)
Date: Thu, 15 Mar 2018 09:50:28 +0000
Subject: [issue32421] Keeping an exception in cache can segfault the
 interpreter
In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za>
Message-ID: <1521107428.11.0.467229070634.issue32421@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Serhiy: Sorry the ? comes from emacs' pretty-mode, I should copy from outside emacs. Version tested are listed in my previous message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32421>
_______________________________________

From report at bugs.python.org  Thu Mar 15 05:52:58 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Mar 2018 09:52:58 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1521107578.48.0.467229070634.issue32968@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, that sort of thing is going to happen as soon as floating-point enters the mix. There will be surprises from Fraction % float as well as float % Fraction:

>>> from fractions import Fraction
>>> Fraction(10**23) // 1e22
9.0

And that's again surprising, because 1e22 is exactly equal to 10**22:

>>> 1e22 == 10**22
True

This isn't special to Fractions: the same is true for mixed-type int-float arithmetic:

>>> 10**23 // 1e22
9.0


As you say, this is the result of rounding error.

There's not much we can do about that except for make sure that people are aware that precision can be lost when a Fraction is converted to a float. (One could conceivably outlawed mixed-type Fraction-float operations altogether, but rightly or wrongly that's not the decision that was made when the Fraction type was introduced, and changing that now would amount to gratuitous breakage.)

So yes, modifying both __floordiv__ and __rfloordiv__ together (and similarly for __mod__) is the right thing to do: we definitely don't want Fraction % float and float % Fraction to return different types.

On the testing front, testing the result value of something like 1.0 // Fraction(1, 10) is a little bit dodgy, because the result is only predictable under assumptions that we're using IEEE 754 arithmetic, and that's (at the moment) not an assumption that the Python core makes. I'd suggest using a safer case like 1.0 // Fraction(3, 10).

> I thought about fixing it, to make the behavior more consistent, but I thought that was a bit risky.

I think you have excellent instincts here. :-) But in this case, I do think it's better to be consistent, and to have a easy-to-learn and simple-to-remember rule (mixed-type Fraction-float arithmetic operations convert the Fraction to a float, regardless of the operation or the ordering of the operands). The floating-point surprises are a fact of life anyway, regardless of what Fraction does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:01:38 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 15 Mar 2018 10:01:38 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521108098.43.0.467229070634.issue27984@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

?ukasz,

Sorry about that.  Since Xiang is a core developer, I thought he would be in the position to make the decision about moving forward with the patch.  I apologize for causing unnecessary work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:02:39 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Mar 2018 10:02:39 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521108159.39.0.467229070634.issue33069@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We allowed semi-standardised additional fields for an extended period with 1.2 (for Provides-Extra and Description-Content-Type), but folks mostly found it confusingly ambiguous, so Dustin created PEP 566 to define them officially as Metadata 1.3.

Given that, I agree with ?ric that if distutils is still setting "Metadata-Version: 1.1", we should stick with the old PEP 314 behaviour and advise folks to migrate to setuptools if they'd prefer the updated behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:07:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 10:07:59 +0000
Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes
 followed by "; " instead of space
In-Reply-To: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za>
Message-ID: <1521108479.74.0.467229070634.issue32328@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

According to the documentation (https://www.tcl.tk/man/tcl/TkCmd/ttk_treeview.htm) the item option "values" is "The list of values associated with the item.", and the item option "tags" is "A list of tags associated with this item." Tcl's list corresponds Python's tuple (lists are also accepted in Python 3).

Change your example to:

    kw = {'values': ('" ";',), 'tags': ()}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32328>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:20:38 2018
From: report at bugs.python.org (Simon Lipp)
Date: Thu, 15 Mar 2018 10:20:38 +0000
Subject: [issue33079] subprocess: document the interaction between
 subprocess.Popen and os.set_inheritable
Message-ID: <1521109238.05.0.467229070634.issue33079@psf.upfronthosting.co.za>


New submission from Simon Lipp <keejaisi at hwold.net>:

>From current `os` documentation:

> A file descriptor has an ?inheritable? flag which indicates if the file descriptor can be inherited by child processes

from current `subprocess` documentation:

> If close_fds is true, all file descriptors except 0, 1 and 2 will be closed before the child process is executed

It would be helpful to explicitly specify that subprocess.Popen does not takes into account the inheritable flag ; thas is, that inheritable fds will still be closed with open_fds = False, and that non-inheritable fds will still be kept with open_fds = True.

----------
assignee: docs at python
components: Documentation
messages: 313868
nosy: docs at python, sloonz
priority: normal
severity: normal
status: open
title: subprocess: document the interaction between subprocess.Popen and os.set_inheritable
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33079>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:33:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 15 Mar 2018 10:33:30 +0000
Subject: [issue27984] singledispatch register should typecheck its argument
In-Reply-To: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>
Message-ID: <1521110010.91.0.467229070634.issue27984@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Cheryl, It's a good remind for me. I totally forget about this issue.

> Since Xiang is a core developer, I thought he would be in the position to make the decision about moving forward with the patch.

Yes, I made the decision. But seems not a wise one, sorry. :-( But fortunately ?ukasz noticed it. :-)

I am happy to see finally this issue is solved, instead of hanging with no reply. :-) Thanks for ?ukasz and Cheryl.

I am sorry for the PRs making noise here. Again, it's quite all right for me to close them. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27984>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:39:21 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Thu, 15 Mar 2018 10:39:21 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521110361.88.0.467229070634.issue26680@psf.upfronthosting.co.za>


Change by Robert Smallshire <rob at sixty-north.com>:


----------
pull_requests: +5885
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 06:57:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 10:57:48 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521111468.54.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The use case of is_integer() still is not clear. Could you give examples of the correct use of this method in real projects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:01:09 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Mar 2018 11:01:09 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521111669.82.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Patched test_capi results for 2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 (the global state consolidation commit): both pre-initialization tests fail

Patched test_capi results for bab21faded31c70b142776b9a6075a4cda055d7f (the immediately preceding commit): both pre-initialization tests pass

Ding, ding, ding, we have a winner :)

Rather than reverting the options-related aspects of that change though, I think a nicer way to handle it will be to add a "pre-init fallback" path to those functions that stores the raw wchar_t data, and postpones converting those values to Py_Unicode objects until we need them in _PyInitialize_Core.

I'm not sure what to do about PySys_AddWarnOptionUnicode though: I think that's just outright incoherent as an API, since you need to call it before Py_Initialize for it to do anything useful, but we don't support calling any of the Unicode creation APIs until *after* Py_Initialize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:04:06 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Thu, 15 Mar 2018 11:04:06 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521111846.07.0.467229070634.issue26680@psf.upfronthosting.co.za>


Robert Smallshire <rob at sixty-north.com> added the comment:

Python in effect contains an example itself. The math.factorial(x) function contains what is in-effect an is_integer() check as a guard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:14:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 11:14:46 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521112486.36.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

math.factorial() doesn't use float.is_integer().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:33:09 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Mar 2018 11:33:09 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521113589.64.0.467229070634.issue26680@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

In effect:

   "!(Py_IS_FINITE(dx) && dx == floor(dx))"


I don't understand why Robert is questioned so much. mpd_as_integer() (or rather the optimized version _mpd_isint() is used all over the place inside libmpdec's own numeric code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:33:22 2018
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 15 Mar 2018 11:33:22 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1521113602.82.0.467229070634.issue33012@psf.upfronthosting.co.za>


Antti Haapala <antti at haapala.name> added the comment:

I don't have GCC 8 so I cannot verify this bug, but *function pointer casts* are fine - any function pointer can be cast to any other function pointer - it is only that they must *not* be called unless cast back again to be compatible with the function definition. Any fix to the contrary might well *cause* undefined behaviour!

Could you provide a sample of the *actual warnings* so that they could be studied?

----------
nosy: +ztane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:45:58 2018
From: report at bugs.python.org (Michael Durso)
Date: Thu, 15 Mar 2018 11:45:58 +0000
Subject: [issue32608] Incompatibilities with the socketserver and
 multiprocessing packages
In-Reply-To: <1516539327.3.0.467229070634.issue32608@psf.upfronthosting.co.za>
Message-ID: <1521114358.46.0.467229070634.issue32608@psf.upfronthosting.co.za>


Michael Durso <rbprogrammer at gmail.com> added the comment:

Hi Antoine, no worries for the delay.

I've been looking into why the AppVeyor check is failing.  I believe it to be an issue with the test harness in that it changes the environment during the tests, but only in the Windows case.  I have been thinking about ignoring the failing tests in Windows and create new tests just for the Windows case.  But I'm not sure that's the best approach.  Ideally the test harness should be able to either not modify the environment of the process or revert the changes it has made.

I'm not a strong Windows developer, so with my crude Windows development environment I'm struggling to see why the tests work in my Linux dev environment but not my Windows VM one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32608>
_______________________________________

From report at bugs.python.org  Thu Mar 15 07:51:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 11:51:28 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521114688.98.0.467229070634.issue33073@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Adding as_integer_ratio() to numbers.Rational is a breaking change. It breaks the interface. Currently all numbers.Rational subclasses implement all public methods and properties of the abstract class, but with adding as_integer_ratio() this will be no longer true.

>>> issubclass(numpy.int64, numbers.Rational)
True
>>> numpy.int64.as_integer_ratio
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'numpy.int64' has no attribute 'as_integer_ratio'

I suggest to make as_integer_ratio() creating an implicit interface (as write() creates an implicit interface for writable file-like objects), and add a convenient function (in the numbers or the math module) which calls this method if it exists and falls back to the (nominator, denominator) pair otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Thu Mar 15 08:06:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 12:06:34 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521115594.22.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

mpd_as_integer() is used internally in the Decimal class. Do you have use cases for it outside of the Decimal class?

And the question was about using float.is_integer(). I have not found *any* sane example on GitHub. The most harmless is just a demo

    >>> x = 3.0
    >>> print(x.is_integer())
    True

Other examples are so bad that make me angry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 08:07:38 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Thu, 15 Mar 2018 12:07:38 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1521115658.42.0.467229070634.issue33012@psf.upfronthosting.co.za>


Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com> added the comment:

> I don't have GCC 8 so I cannot verify this bug, but *function pointer casts* are fine - any function pointer can be cast to any other function pointer - it is only that they must *not* be called unless cast back again to be compatible with the function definition. Any fix to the contrary might well *cause* undefined behaviour!

Please see the attached PR; METH_NOARGS callbacks are inconsistent in their signature and many have just one argument while they're called with two arguments, the second being NULL.  The patch fixes these to consistently take and call with two arguments.

> Could you provide a sample of the *actual warnings* so that they could be studied?

Here's one of a few hundred.

Objects/bytesobject.c:3085:25: warning: cast between incompatible function types from ?PyObject * (*)(striterobject *)? {aka ?struct _object * (*)(struct <anonymous> *)?} to ?PyObject * (*)(PyObject *, PyObject *)? {aka ?struct _object * (*)(struct _object *, struct _object *)?} [-Wcast-function-type]
     {"__reduce__",      (PyCFunction)striter_reduce, METH_NOARGS,
                         ^
This is a new warning in gcc8, so you'll likely not find much reference, but here's a gcc bug report that might give you more context:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Thu Mar 15 08:10:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 12:10:16 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1521115816.01.0.467229070634.issue33012@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Questionable code in OrderedDict definition

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Thu Mar 15 08:22:47 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Mar 2018 12:22:47 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521116567.7.0.467229070634.issue26680@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

libmpdec is an example of numerical code.  I don't think anyone but you has argued that is_integer() is useless in numerical code.  Whether it is float or decimal doesn't matter.

I get the API-bloat argument, but I'm completely surprised that anyone would assert the above.


I think searching GitHub or the Internet for robust numerical code is not conclusive.  80% of open source stuff is probably derived from netlib anyway. :-)



I'll avoid giving examples outside of libmpdec because I don't have time for a nitpicking war. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 08:32:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 12:32:35 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521117155.56.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If float.is_integer() is useful in numerical code please give me few examples.

I don't take your argument about mpd_as_integer() in the Decimal class. Decimal has a lot of methods which makes sense for Decimal.

>>> len(set(dir(decimal.Decimal)) - set(dir(numbers.Rational)))
55

Do you suggests to add all of them into the numeric tower?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 08:36:36 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Mar 2018 12:36:36 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521117396.41.0.467229070634.issue26680@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/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 09:17:43 2018
From: report at bugs.python.org (Robert Smallshire)
Date: Thu, 15 Mar 2018 13:17:43 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521119863.92.0.467229070634.issue26680@psf.upfronthosting.co.za>


Robert Smallshire <rob at sixty-north.com> added the comment:

Serhiy, you asked for use cases, not uses. The former can exist without the latter.  Use cases for is_integer() include all existing uses of x == int(x), or other less obvious means of detecting integer values.

Folks try to use x.is_integer(), discover it fails if x is an int, and go in search of a replacement, which may well be x == int(x), which goes on to fail in more complex and awkward to handle ways with NaN or Inf.

I've seen is_integer() used in guard clauses for functions which accept numbers which require an integral value (Recall that explicit type checking is usually called out as unPythonic, and rightly so). The Python factorial is example of such a function which makes an equivalent check. StackOverflow is awash with folks using isinstance(x, int) where that is not what they actually mean. Many of these are the same use-case, but don't use is_integer().

I've also seen it used in cases where different algorithms are more optimal depending on whether the arguments are integral or not (imagine some combination of factorial() and gamma()).

I've seen it used in conversion from float to custom number types used to simulate the unusual number types in embedded hardware.

I'm not going to engage with this discussion further. It's already consumed too much of my time, left me with a somewhat negative view of how Python development proceeds, and a confused view of the values that are most important to the Python language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 09:23:59 2018
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 15 Mar 2018 13:23:59 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521120239.39.0.467229070634.issue26680@psf.upfronthosting.co.za>


Change by Facundo Batista <facundo at taniquetil.com.ar>:


----------
nosy:  -facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 10:13:03 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 15 Mar 2018 14:13:03 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1521123183.1.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

I'm having issues with my local changes for my PR, I'm unsure why my local machine takes a seemingly infinite amount of time on test_poplib, so again I think something to do with my local environment is causing issues again, any help would be appreciated...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Thu Mar 15 10:21:54 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 15 Mar 2018 14:21:54 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <1521123714.68.0.467229070634.issue33057@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

>  I have two types of loggers, one for experiment results ("data") and another for general information

In what way is the behaviour of the two types of logger different? I'm concerned that this might be an XY problem ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Thu Mar 15 10:29:54 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 15 Mar 2018 14:29:54 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1521124194.65.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

https://pastebin.com/q4FKnPZH

the trace for the test_poplib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Thu Mar 15 11:27:14 2018
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 15 Mar 2018 15:27:14 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1521127634.83.0.467229070634.issue33012@psf.upfronthosting.co.za>


Antti Haapala <antti at haapala.name> added the comment:

Yea, I looked into `ceval.c` and the function is *called incorrectly*, so there is undefined behaviour there - it has been wrong all along, in 3.5 all the way down to 2-something

        if (flags & (METH_NOARGS | METH_O)) {
            PyCFunction meth = PyCFunction_GET_FUNCTION(func);
            PyObject *self = PyCFunction_GET_SELF(func);
            if (flags & METH_NOARGS && na == 0) {
                C_TRACE(x, (*meth)(self,NULL));

                x = _Py_CheckFunctionResult(func, x, NULL);
            }

The warning in GCC shouldn't probably have been enabled at all in `-Wall -Wextra` because the cast is explicit. However, it is somewhat true.

However, the correct way to fix would be to have the METH_NOARGS case cast the function to the right prototype. There exists lots of existing code that *is* going to break too. 

Perhaps PyCFunction should declare no prototype, i.e. empty parentheses, for backwards compatibility:

    typedef PyObject *(*PyCFunction)();

and deprecate it; start using a new typedef for it - and then add proper casts in every place that call a function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Thu Mar 15 11:32:45 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 15 Mar 2018 15:32:45 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1521127965.54.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

it seems to me like the issue in my tests is that some SSL thing is failing?, anyone have any experience with this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Thu Mar 15 11:45:29 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 15:45:29 +0000
Subject: [issue32421] Keeping an exception in cache can segfault the
 interpreter
In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za>
Message-ID: <1521128729.76.0.467229070634.issue32421@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I repeated Julian's test with installed 3.7.0b2 on Windows 10 and there is no crash when running either from a command line or from an IDLE editor.  So either the issue has been fixed since 3.6.2, or it is specific to some undisclosed system or class of systems, or the specific claim in the title is a misinterpretation of behavior.  In any case, there is currently no possibility of action on our part.

Yonatan, if you have the promised minimal reproducible test case, for current python, please post it, with version and OS.  If not, we should close this ('not a bug' fits best) until there is one.

----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32421>
_______________________________________

From report at bugs.python.org  Thu Mar 15 11:54:03 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Thu, 15 Mar 2018 15:54:03 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1521129243.73.0.467229070634.issue33012@psf.upfronthosting.co.za>


Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com> added the comment:

> The warning in GCC shouldn't probably have been enabled at all in `-Wall -Wextra` because the cast is explicit. However, it is somewhat true.

The explicit cast is precisely what enables the more nuanced function cast warning where it checks the function for type compatibility.  That is, it will check the types of the return and arguments and then warn in case of mismatch.

> However, the correct way to fix would be to have the METH_NOARGS case cast the function to the right prototype. There exists lots of existing code that *is* going to break too. 

AFAICT, there is no right prototype for the METH_NOARGS function; there used to be a PyCFunctionWithNoArguments but that seems to have fallen out of favour some time back.  The prototype that seems to be commonly in use (and in clinic as well, which is what I based my patches on) is the PyCFunction, which seems like a safe way to do things.

> Perhaps PyCFunction should declare no prototype, i.e. empty parentheses, for backwards compatibility:
> 
>     typedef PyObject *(*PyCFunction)();
> 
> and deprecate it; start using a new typedef for it - and then add proper casts in every place that call a function.

I have a patch in the works that makes it PyObject *(*)(PyObject *, PyObject *, ...)

which allows for two compulsory arguments (fits in with most cases, provided the METH_NOARGS patch is accepted) and then the rest depending on the type of the cast function.  The rest of the PyMethodDef functions are much simpler fixes this way.  It also seems like a more intuitive description of the callbacks.

Then there are getter and setter and other function pointers that need similar fixes to METH_NOARGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Thu Mar 15 11:55:27 2018
From: report at bugs.python.org (Siddhesh Poyarekar)
Date: Thu, 15 Mar 2018 15:55:27 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1521129327.97.0.467229070634.issue33012@psf.upfronthosting.co.za>


Siddhesh Poyarekar <siddhesh.poyarekar at gmail.com> added the comment:

I forgot to clarify that the function cast warning allows for variable argument casts as a wildcard, which is my basis for the PyObject *(*)(PyObject *, PyObject *, ...) fix proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Thu Mar 15 12:00:19 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 15 Mar 2018 16:00:19 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521129619.64.0.467229070634.issue33073@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Serhiy, I don't understand.  If `numbers.Rational` is in fact a superclass of `numpy.int64`, then the latter will inherit an implementation added to the former.  The idea here isn't to add an abstract method to the Rational interface, but a concrete default implementation:

class Rational(Real):
    ...
    def as_integer_ratio(self):
        return (self.numerator, self.denominator)

Or, as for Python ints, is Rational a "make believe" (virtual) superclass of numpy.int64?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Thu Mar 15 12:11:57 2018
From: report at bugs.python.org (Jonathan Springer)
Date: Thu, 15 Mar 2018 16:11:57 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521130317.11.0.467229070634.issue33042@psf.upfronthosting.co.za>


Change by Jonathan Springer <springermac at gmail.com>:


----------
nosy: +springermac

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Thu Mar 15 12:16:58 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Mar 2018 16:16:58 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521130618.47.0.467229070634.issue33073@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's a "virtual" subclass. The numpy.integer parent class is registered here:

https://github.com/numpy/numpy/blob/10ccfe747a68d974ff16a5c0765054b816d5486f/numpy/core/numerictypes.py#L944

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Thu Mar 15 12:31:11 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Mar 2018 16:31:11 +0000
Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes
 followed by "; " instead of space
In-Reply-To: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za>
Message-ID: <1521131470.99.0.467229070634.issue32328@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Our ttk doc, https://docs.python.org/3/library/tkinter.ttk.html#item-options, here copies the tk doc: "The list of values associated with the item."  It should say 'tuple or list', but that is a generic (and separate) issue of our ttk doc not translating '(tcl) list' to '(python) sequence' or '(python) tuple or list'.

The NMT doc, http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Treeview.html, is unnecessarily vague ('data items') about what needs to be passed for values.  It correctly notes that a single string is accepted for tags, but I don't know that this is guaranteed.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32328>
_______________________________________

From report at bugs.python.org  Thu Mar 15 12:46:10 2018
From: report at bugs.python.org (Alexander Kanavin)
Date: Thu, 15 Mar 2018 16:46:10 +0000
Subject: [issue33080] regen-importlib is causing build races against other
 regen-all targets in Makefile.pre.in
Message-ID: <1521132370.51.0.467229070634.issue33080@psf.upfronthosting.co.za>


New submission from Alexander Kanavin <alex.kanavin at gmail.com>:

You can see here:

https://github.com/python/cpython/blob/master/Makefile.pre.in#L708

that regen-importlib is building a binary from .o files which are built from .c and .h files, which are, at the same time, regenerated by other regen- targets.

This does cause build errors in heavily parallelized builds, we've been seeing it regularly in Yocto Project lately:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12596

I tried to see if I can easily correct target dependencies in the makefile, but couldn't figure it out. So, a workaround, for us, would be to issue 'make regen-importlib' ahead of other things:

    make regen-importlib
    make regen-all

----------
components: Build
messages: 313894
nosy: Alexander Kanavin
priority: normal
severity: normal
status: open
title: regen-importlib is causing build races against other regen-all targets in Makefile.pre.in
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33080>
_______________________________________

From report at bugs.python.org  Thu Mar 15 12:57:56 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 15 Mar 2018 16:57:56 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521133076.35.0.467229070634.issue26680@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

[Raymond]
> The OPs notion of "absurd" behavior implies a rule that
> all float methods should be available for ints.  That
> would suggest the is_integer, hex, fromhex, and
> as_integer_ratio would all need to propagate to the
> other types as well.  I don't think we should start
> sliding down that slope.

Given that Guido recently said it was absurd that int.hex() doesn't exist, and that another PR to add int.as_integer_ratio() is in progress, we'll soon be halfway down that slope looking up ;-)

The OP is right that in a world where you _can't tell_ from staring at the code whether you'll get back an int or a float, sometimes not even when you know the input types (like `int**int`), it can be jarring when degenerate cases (like int.is_integer()) refuse to do the obvious thing.

So I'm in favor given that float.is_integer() already exists.

While I have no feel for how generally useful is_integer() may be, there are many use cases when _implementing_ math functions.  For example,

>>> (-1.0) ** 3.1
(-0.9510565162951536-0.30901699437494706j)
>>> (-1.0) ** 3.0
-1.0

Here not only the value, but the _type_ of the result depends on whether the power is an exact integer.  The only way to know the latter is to spell is_integer() in _some_ way.  Given that x is a finite double, `x == int(x)` may be used in Python, or `x == floor(x)` in C or even `fmod(fabs(x), 1.0) == 0.0`.

As Mark pointed out, those kinds of ways can be woefully inefficient for Decimals, so adding is_integer() to Decimal too supplies a uniform way for users to spell the functionality that types can implement in a way best for them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 13:12:13 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 15 Mar 2018 17:12:13 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521133933.46.0.467229070634.issue33073@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Thanks, Mark!  So if int.as_integer_ratio is added to the core, numpy.int64 won't magically have it too, regardless of whether we do or don't add an implementation to numbers.Rational.

As an end user, I'd be surprised if numpy.int64 didn't support the same stuff as core ints.  I doubt I'd care at all what numbers.Rational said in cases where it didn't.

But rather than argue about that, what would _you_ like to see done here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Thu Mar 15 13:50:06 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 15 Mar 2018 17:50:06 +0000
Subject: [issue28677] difficult to parse sentence structure in "When an
 instance attribute is referenced that isn't a data attribute"
In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>
Message-ID: <1521136206.04.0.467229070634.issue28677@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28677>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:01:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 18:01:15 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521136875.3.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not see a point in adding a function that will never be used correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:02:39 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Mar 2018 18:02:39 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521136959.53.0.467229070634.issue33073@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]

> [...] what would _you_ like to see done here?

Given that float.as_integer_ratio and Decimal.as_integer_ratio already exist, and that I don't have a working time machine right now, I'm in favour of adding int.as_integer_ratio purely for duck-typing reasons: I want to be able to use an int where a float is expected, and I _have_ encountered code in the past where I have to think too hard about what precise types are being used, and where that thinking seems as though it shouldn't be necessary. For the same reason, I'd support as_integer_ratio on the Fraction type. I don't really care whether it gets there via the Rational ABC or not. Adding as_integer_ratio to Rational as an @abstractmethod _does_ seem a step too far (because now anyone who registers a type with numbers.Integral or numbers.Rational has to implement as_integer_ratio), but my understanding is that that's not what's being proposed.

It doesn't bother me that the NumPy integer types won't support as_integer_ratio immediately (or possibly ever). The floating-point types don't either (except np.float64, which only has it because it inherits directly from Python's float), and it's hard to see how as_integer_ratio could be useful for a NumPy float32 array (for example), given that the returned numerator and denominator could exceed the bounds of any of the fixed-width NumPy integer types. I write a lot of NumPy-using code, but the world in which I do so rarely meets the world where I care about correct rounding, fractions, counting ulps error, etc. I haven't missed float32.as_integer_ratio or float16.as_integer_ratio yet.

If we're worried about NumPy compatibility, it might be interesting to get Nathaniel Smith's opinion.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:05:17 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Thu, 15 Mar 2018 18:05:17 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
Message-ID: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>


New submission from Henrique Andrade <hcma at unscrambl.com>:

A simple example like such demonstrates that one of the file descriptors associated with the underlying pipe will be leaked:

>>> from multiprocessing.queues import Queue
>>> x = Queue()
>>> x.close()

Right after the queue is created we get (assuming the Python interpreter is associated with pid 8096 below):

> ll /proc/8096/fd
total 0
dr-x------ 2 hcma hcma  0 2018-03-15 14:03:23.210089578 -0400 .
dr-xr-xr-x 9 hcma hcma  0 2018-03-15 14:03:23.190089760 -0400 ..
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 0 -> /dev/pts/25
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 1 -> /dev/pts/25
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:23.210089578 -0400 2 -> /dev/pts/25
lr-x------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 3 -> pipe:[44076946]
l-wx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 4 -> pipe:[44076946]
lr-x------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 5 -> /dev/urandom

After close():

> ll /proc/8096/fd
total 0
dr-x------ 2 hcma hcma  0 2018-03-15 14:03:23.210089578 -0400 .
dr-xr-xr-x 9 hcma hcma  0 2018-03-15 14:03:23.190089760 -0400 ..
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 0 -> /dev/pts/25
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 1 -> /dev/pts/25
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:23.210089578 -0400 2 -> /dev/pts/25
lr-x------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 3 -> pipe:[44076946]
l-wx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 4 -> pipe:[44076946]
lr-x------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 5 -> /dev/urandom

----------
components: Library (Lib)
messages: 313899
nosy: Henrique Andrade
priority: normal
severity: normal
status: open
title: multiprocessing Queue leaks a file descriptor associated with the pipe writer
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:08:51 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Thu, 15 Mar 2018 18:08:51 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521137331.26.0.467229070634.issue33081@psf.upfronthosting.co.za>


Henrique Andrade <hcma at unscrambl.com> added the comment:

Correcting my original - after close():

> ll /proc/8096/fd
total 0
dr-x------ 2 hcma hcma  0 2018-03-15 14:03:23.210089578 -0400 .
dr-xr-xr-x 9 hcma hcma  0 2018-03-15 14:03:23.190089760 -0400 ..
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 0 -> /dev/pts/25
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 1 -> /dev/pts/25
lrwx------ 1 hcma hcma 64 2018-03-15 14:03:23.210089578 -0400 2 -> /dev/pts/25
l-wx------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 4 -> pipe:[44076946]
lr-x------ 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 5 -> /dev/urandom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:14:57 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 15 Mar 2018 18:14:57 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521137697.85.0.467229070634.issue26680@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Serhiy, nobody is proposing to add float.as_integer().  It already exists:

>>> (3.1).is_integer()
False

I already allowed I don't have a feel for how _generally_ useful it is, but you have at least my and Stefan's word for that the functionality (however spelled) _is_ necessary in implementing various math libraries.

If we outlawed float functions that the numerically naive may misuse, we'd have to remove floats entirely.

Given that it's _already in the language_, the only question here is whether to make it play nice with types beyond just `float`.  I expect you'd have a hard time constructing an example where int.is_integer() returned a misleading result ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:33:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 18:33:32 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521138812.16.0.467229070634.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am proposing to deprecate float.is_integer() and remove it in 3.10. After deprecating float.as_integer() we shouldn't bother about adding int.is_integer().

If this method is necessary in implementing various math libraries please show me the code of these libraries that call float.is_integer() or which will get a benefit from adding is_integer() in int and Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:38:56 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Mar 2018 18:38:56 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521139136.24.0.467229070634.issue33042@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Nick, what's your assessment of this issue's priority?  Is it a release blocker for 3.7.0b3 (proposed ABI freeze)?  For 3.7.0rc1 (code freeze)?  None of the above?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:45:50 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 15 Mar 2018 18:45:50 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521139550.12.0.467229070634.issue26680@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

If you want to deprecate the method, bring that up on python-dev or python-ideas.  It's inappropriate on the issue tracker (unless, e.g., you open a new issue with a patch to rip it out of the language).  It's also inappropriate to keep on demanding in _this_ issue that people justify a method that already exists.  For that reason, I'm not responding again to more repetitions of that here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:50:50 2018
From: report at bugs.python.org (Chad)
Date: Thu, 15 Mar 2018 18:50:50 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
Message-ID: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>


New submission from Chad <millchad at amazon.com>:

Callbacks are really important in multiprocessing. Doc writer almost ignores them.

----------
assignee: docs at python
components: Documentation
messages: 313905
nosy: chadmiller-amzn, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing docs bury very important 'callback=' args
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/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:51:31 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Mar 2018 18:51:31 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521139891.09.0.467229070634.issue33082@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:55:08 2018
From: report at bugs.python.org (Chad)
Date: Thu, 15 Mar 2018 18:55:08 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521140108.5.0.467229070634.issue33082@psf.upfronthosting.co.za>


Chad <millchad at amazon.com> added the comment:

https://github.com/chadmiller-amzn/cpython/pull/1

(Putting that in "GitHub PR" field says "Edit Error: Unknown PR format, acceptable formats are: full github URL, #pr_number, pr_number")

----------
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 15 14:57:46 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 15 Mar 2018 18:57:46 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1521140266.24.0.467229070634.issue27657@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Thu Mar 15 15:05:36 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Mar 2018 19:05:36 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1521140736.85.0.467229070634.issue26680@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

/me bets his money on Stefan and Tim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________

From report at bugs.python.org  Thu Mar 15 15:14:01 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 15 Mar 2018 19:14:01 +0000
Subject: [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1521141241.44.0.467229070634.issue21611@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Is this superseded by issue 26701?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21611>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:23:14 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 15 Mar 2018 20:23:14 +0000
Subject: [issue25735] math.factorial doc should mention integer return type
In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>
Message-ID: <1521145394.11.0.467229070634.issue25735@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Should the documentation patch for this be converted to a PR or does this need to change to a bug issue to address Mark's concerns?

Thanks!

----------
nosy: +csabella
stage:  -> needs patch
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:27:04 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Mar 2018 20:27:04 +0000
Subject: [issue25735] math.factorial doc should mention integer return type
In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>
Message-ID: <1521145624.54.0.467229070634.issue25735@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Should the documentation patch for this be converted to a PR

I think so, yes. How about we open a new issue for the factorial(Decimal(...)) behaviour, and keep this one focused on the original reported issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:34:02 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 15 Mar 2018 20:34:02 +0000
Subject: [issue25735] math.factorial doc should mention integer return type
In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>
Message-ID: <1521146042.66.0.467229070634.issue25735@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Sounds good.  Thanks, Mark.

@mine0901, would you like to open a Github pull request for your patch?  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:38:33 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Mar 2018 20:38:33 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
Message-ID: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Observed by Terry Reedy in the issue #25735 discussion (msg255479):

>>> factorial(decimal.Decimal(5.2))
120

This should be either raising an exception (either ValueError or TypeError, depending on whether we want to accept only integral Decimal values, or prohibit Decimal values altogether), or possibly returning an approximation to Gamma(6.2) (=169.406099461722999629...)

I'd prefer that we prohibit a Decimal input altogether, but accepting integral Decimal instances would parallel the current behaviour with floats:

>>> factorial(5.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: factorial() only accepts integral values
>>> factorial(5.0)
120


Terry also observed:

>>> factorial(Fraction(5))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required (got type Fraction)

----------
messages: 313912
nosy: facundobatista, mark.dickinson, rhettinger, skrah, terry.reedy
priority: normal
severity: normal
status: open
title: math.factorial accepts non-integral Decimal instances
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:39:08 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Mar 2018 20:39:08 +0000
Subject: [issue25735] math.factorial doc should mention integer return type
In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za>
Message-ID: <1521146348.85.0.467229070634.issue25735@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I opened #33083, and copied the nosy list from this issue across.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25735>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:44:23 2018
From: report at bugs.python.org (Eli Ribble)
Date: Thu, 15 Mar 2018 20:44:23 +0000
Subject: [issue32799] <class 'contextlib._GeneratorContextManager'> returned a
 result with an error set
In-Reply-To: <1518103707.85.0.467229070634.issue32799@psf.upfronthosting.co.za>
Message-ID: <1521146663.61.0.467229070634.issue32799@psf.upfronthosting.co.za>


Eli Ribble <junk at theribbles.org> added the comment:

You can feel free to close the bug - I no longer work for the company that had this problem and I was only reporting the bug because the documentation specifically requested I do so. I don't have the ability now to try upgrading the version of Python to see if it resolves the problem. I also no longer have access to the stack traces.

The code in question did not use threading, forking or signal handlers and I no longer have the rights to provide the wrapped code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32799>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:46:10 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Mar 2018 20:46:10 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521146770.25.0.467229070634.issue33082@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Can you make your PR in python/cpython GitHub repo, instead of your own fork?

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 15 16:46:42 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Mar 2018 20:46:42 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521146802.37.0.467229070634.issue33082@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 15 17:10:27 2018
From: report at bugs.python.org (Chad)
Date: Thu, 15 Mar 2018 21:10:27 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521148227.1.0.467229070634.issue33082@psf.upfronthosting.co.za>


Change by Chad <millchad at amazon.com>:


----------
keywords: +patch
pull_requests: +5886
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 15 17:14:25 2018
From: report at bugs.python.org (John Yeung)
Date: Thu, 15 Mar 2018 21:14:25 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521148465.92.0.467229070634.issue33083@psf.upfronthosting.co.za>


Change by John Yeung <gallium.arsenide at gmail.com>:


----------
nosy: +John.Yeung

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Thu Mar 15 18:36:53 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 15 Mar 2018 22:36:53 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521153413.95.0.467229070634.issue33077@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Yes, this is because subclassing `typing.NamedTuple` is not an actual subclassing, but is just a syntactic sugar for calling `collections.namedtuple`. A discussion about allowing subclassing/extending named tuples previously appeared in https://github.com/python/typing/issues/427 but was subsequently closed as wontfix. In short, the argument was that we should keep feature set and implementation of named tuples simple/minimalistic, and instead recommend dataclasses for all more complex use cases. Note however, that this decision was never added to the `typing.NamedTuple` documentation. I think it totally makes sense to clarify this in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:00:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Mar 2018 23:00:55 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521154855.8.0.467229070634.issue33083@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Many functions implemented in C accept Decimal instances.

>>> chr(decimal.Decimal(65.2))
'A'

This is because PyLong_AsLong() and similar functions call __int__().

Floats are specially prohibited when convert arguments with PyArg_Parse() with the "i" format unit.

>>> chr(65.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: integer argument expected, got float

The specific of factorial() is that it accepts integral floats and raises ValueError instead of TypeError for non-integral floats. Maybe it was planned to extend factorial() to non-integral floats by using a gamma function. All other functions in the math module worked with floats at the time of adding factorial() in issue2138. math.gamma() was added 1.5 years later in issue3366.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:03:19 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 15 Mar 2018 23:03:19 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521153413.95.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+tHZUmRooydCvSSGMKDFQm3O+vS1hfuCNU=HBB7X_6ag@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I wonder if it's too late to conclude that NamedTuple in this context
should have been a class decorator rather than a base class. With a class
decorator it's more understandable that the effect doesn't automatically
apply to subclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:09:35 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 15 Mar 2018 23:09:35 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521155375.6.0.467229070634.issue33077@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I once thought of building NamedTuple functionality into dataclasses, either as a parameter to @dataclass or as a new decorator. But it didn't get very far.

It would have to return a different class, like NamedTuple does, and this didn't fit in well with the original "keep @dataclass simple" mantra.

It would also be especially confusing with frozen already existing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:16:59 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 15 Mar 2018 23:16:59 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521155819.24.0.467229070634.issue33077@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I would say it is too late. `typing.NamedTuple` is out there for more than a year and is quite actively used. A search on GitHub shows thousands of files that import `typing.NamedTuple` and a macroscopic fraction of those use it with the class syntax. I think the damage from breaking working code outweighs the potential bugs here. A clear example in the docs that explains how it works would be sufficient I think.

(Also a camel case decorator would look weird.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:26:14 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 15 Mar 2018 23:26:14 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521156374.87.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Is not leaked as the object is still alive. Only one side is closed when you call "closed". If you destroy the object:

>>> del x

You will see that there are no more file descriptors in /proc/PID/fd associated with that queue.

Also, notice that closed() is called when the queue is destroyed.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:26:21 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Mar 2018 23:26:21 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521156381.64.0.467229070634.issue33083@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/issue33083>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:46:47 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Thu, 15 Mar 2018 23:46:47 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521157607.96.0.467229070634.issue33081@psf.upfronthosting.co.za>


Henrique Andrade <hcma at unscrambl.com> added the comment:

Pablo, but there is no way to close the other side.

Indeed, if you look in the implementation, you will see that the writer file descriptor can't be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:51:48 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 15 Mar 2018 23:51:48 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1521157908.72.0.467229070634.issue32642@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Please open a separate issue for the test_poplib issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Thu Mar 15 19:56:09 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 15 Mar 2018 23:56:09 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521158169.01.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The way is to delete the object. IMHO I would not say is "leaked" as the object is still alive and holds resources and these resources are properly handled on destruction.

I cannot think of an immediate use case of closing both file descriptors but not deleting the object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 20:00:01 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 16 Mar 2018 00:00:01 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521155819.24.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ8vDS_EtExQuzrBz3SgrPMbXkgNe3dobh5MZEnbOceJw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Apart from the fact that it's too late, if you had to do it over again,
could it be done as a class decorator?

Anyway, let's keep this issue open but reclassify it as a docs issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Thu Mar 15 20:06:49 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 16 Mar 2018 00:06:49 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521158809.28.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Notice that the writer gets closed when it receives a sentinel value (which how the queue knows when to close as part of the design):

>>> x.put(multiprocessing.queues._sentinel)

If you call close after this line there will not be any fd associated with the queue open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 21:29:15 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Fri, 16 Mar 2018 01:29:15 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521163755.4.0.467229070634.issue33081@psf.upfronthosting.co.za>


Henrique Andrade <hcma at unscrambl.com> added the comment:

Unfortunately this is not the case.

I will shrink my repro down to a more manageable size and post it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 21:29:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Mar 2018 01:29:22 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521163762.03.0.467229070634.issue33034@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Wouldn't we be better off to catch this error at parse time, instead of just improve the error message when .port is called?

I'm not sure why port is a property and not just computed. Maybe the least intrusive way of doing this would be to just evaluate self.port after the parsing is completed?

----------
nosy: +berker.peksag, eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Thu Mar 15 21:30:16 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Mar 2018 01:30:16 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521163816.33.0.467229070634.issue33034@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Although having said that, we probably can't make that change for 2.7. And maybe it's even too big a change for 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Thu Mar 15 21:56:05 2018
From: report at bugs.python.org (Matt Eaton)
Date: Fri, 16 Mar 2018 01:56:05 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521165365.28.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

"Wouldn't we be better off to catch this error at parse time, instead of just improve the error message when .port is called?"

I think there could be a case to be made about catching and dealing with this error in urlparse() / urlsplit() instead of displaying an error when port property is used.  I think that approaching it this way would cut right to the problem and alleviate carrying around a potentially bad port value.  However, if the port error was caught during parsing but the url, scheme, etc.. values were still valid, are we taking away something from the user by raising the error too soon?  Just a thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:10:29 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 02:10:29 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521166229.56.0.467229070634.issue33081@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:15:19 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 02:15:19 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1521166519.04.0.467229070634.issue33036@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:18:16 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 02:18:16 +0000
Subject: [issue33079] subprocess: document the interaction between
 subprocess.Popen and os.set_inheritable
In-Reply-To: <1521109238.05.0.467229070634.issue33079@psf.upfronthosting.co.za>
Message-ID: <1521166696.48.0.467229070634.issue33079@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33079>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:23:07 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 02:23:07 +0000
Subject: [issue33080] regen-importlib is causing build races against other
 regen-all targets in Makefile.pre.in
In-Reply-To: <1521132370.51.0.467229070634.issue33080@psf.upfronthosting.co.za>
Message-ID: <1521166987.9.0.467229070634.issue33080@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33080>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:27:43 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 02:27:43 +0000
Subject: [issue32799] <class 'contextlib._GeneratorContextManager'> returned a
 result with an error set
In-Reply-To: <1518103707.85.0.467229070634.issue32799@psf.upfronthosting.co.za>
Message-ID: <1521167263.28.0.467229070634.issue32799@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32799>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:40:47 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Mar 2018 02:40:47 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521168047.53.0.467229070634.issue33034@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Yes, you're right, it can't be changed. And .port is documented as raising ValueError, so it's all working correctly. I think improving the ValueError message, as the PR does, is as good as we can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Thu Mar 15 22:51:10 2018
From: report at bugs.python.org (pmpp)
Date: Fri, 16 Mar 2018 02:51:10 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521168670.22.0.467229070634.issue33042@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/issue33042>
_______________________________________

From report at bugs.python.org  Fri Mar 16 00:12:13 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Fri, 16 Mar 2018 04:12:13 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1521173533.67.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Mark, I tried `Fraction(10**23) // 1e22`, and I got 10.

Your `10**23 // 1e22` example was strange, but then `int(1e23)` and got 99999999999999991611392. That is kind of unexpected but I think it is rare for anyone to do something like that with numbers that big.

I think the fact that floating-point rounding error sometimes causes strange results is not a reason to do really unexpected things like making 1.0 // 1/10 equal 9.0, if that can be reasonably avoided.

I updated my pull request with my change, which you suggested, to make __rfloordiv__ and __rmod__ return a float, but with a small change to _operator_fallbacks to avoid the rounding error, so 1.0 // 1/10 is 10.0. You can see it at https://github.com/python/cpython/pull/5956/commits/1020bb219c1a4fad575ee2309c930ce82a4777fb#diff-14d03bfb59581367725b00781e6f802fL391. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Fri Mar 16 01:58:02 2018
From: report at bugs.python.org (Luc)
Date: Fri, 16 Mar 2018 05:58:02 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
Message-ID: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>


New submission from Luc <ouaganet at gmail.com>:

When a list or dataframe serie contains NaN(s), the median, median_low and median_high are computed in Python 3.6.4 statistics library, however, the results are wrong.
Either, it should return a NaN just like when we try to compute a mean or point the user to drop the NaNs before computing those statistics.
Example:
import numpy as np
import statistics as stats

data = [75, 90,85, 92, 95, 80, np.nan]
Median  = stats.median(data)
Median_low = stats.median_low(data)
Median_high = stats.median_high(data)
The results from above return ALL 90 which are incorrect.

Correct answers should be:
Median = 87.5
Median_low  = 85
Median_high = 92
Thanks,
Luc

----------
components: Library (Lib)
messages: 313933
nosy: dcasmr
priority: normal
severity: normal
status: open
title: Computing median, median_high an median_low in statistics library
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 02:59:50 2018
From: report at bugs.python.org (chenkai)
Date: Fri, 16 Mar 2018 06:59:50 +0000
Subject: [issue33085] *** Error in `python': double free or corruption (out):
 0x00007ff5254d50d0 ***
Message-ID: <1521183590.06.0.467229070634.issue33085@psf.upfronthosting.co.za>


New submission from chenkai <13016135670 at 163.com>:

When I finished the installation of readline (6.2.4.1? and then run python, it's crashed?
*** Error in `python': double free or corruption (out): 0x00007ff5254d50d0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7c503)[0x7ff52416e503]
/lib/libpython3.6m.so.1.0(PyOS_Readline+0xec)[0x7ff524e3ff3c]
/lib/libpython3.6m.so.1.0(+0x694d6)[0x7ff524e414d6]
/lib/libpython3.6m.so.1.0(+0x6ae78)[0x7ff524e42e78]
/lib/libpython3.6m.so.1.0(PyTokenizer_Get+0x9)[0x7ff524e43cb9]
/lib/libpython3.6m.so.1.0(+0x6811e)[0x7ff524e4011e]
/lib/libpython3.6m.so.1.0(PyParser_ASTFromFileObject+0x8b)[0x7ff524f76ecb]
/lib/libpython3.6m.so.1.0(+0x19f0ea)[0x7ff524f770ea]
/lib/libpython3.6m.so.1.0(PyRun_InteractiveLoopFlags+0x76)[0x7ff524f77416]
/lib/libpython3.6m.so.1.0(PyRun_AnyFileExFlags+0x3e)[0x7ff524f77c7e]
/lib/libpython3.6m.so.1.0(Py_Main+0xd97)[0x7ff524f93827]
python(main+0x16c)[0x400b1c]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff524113b35]
python[0x400bda]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:03 52652831                           /root/python36/bin/python3
00601000-00602000 r--p 00001000 08:03 52652831                           /root/python36/bin/python3
00602000-00603000 rw-p 00002000 08:03 52652831                           /root/python36/bin/python3
01bb5000-01c92000 rw-p 00000000 00:00 0                                  [heap]
7ff518000000-7ff518021000 rw-p 00000000 00:00 0 
7ff518021000-7ff51c000000 ---p 00000000 00:00 0 
7ff51d0c4000-7ff51d0d9000 r-xp 00000000 08:03 84                         /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7ff51d0d9000-7ff51d2d8000 ---p 00015000 08:03 84                         /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7ff51d2d8000-7ff51d2d9000 r--p 00014000 08:03 84                         /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7ff51d2d9000-7ff51d2da000 rw-p 00015000 08:03 84                         /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7ff51d2da000-7ff51d2ff000 r-xp 00000000 08:03 106273                     /usr/lib64/libtinfo.so.5.9
7ff51d2ff000-7ff51d4ff000 ---p 00025000 08:03 106273                     /usr/lib64/libtinfo.so.5.9
7ff51d4ff000-7ff51d503000 r--p 00025000 08:03 106273                     /usr/lib64/libtinfo.so.5.9
7ff51d503000-7ff51d504000 rw-p 00029000 08:03 106273                     /usr/lib64/libtinfo.so.5.9
7ff51d504000-7ff51d52a000 r-xp 00000000 08:03 90038                      /usr/lib64/libncurses.so.5.9
7ff51d52a000-7ff51d729000 ---p 00026000 08:03 90038                      /usr/lib64/libncurses.so.5.9
7ff51d729000-7ff51d72a000 r--p 00025000 08:03 90038                      /usr/lib64/libncurses.so.5.9
7ff51d72a000-7ff51d72b000 rw-p 00026000 08:03 90038                      /usr/lib64/libncurses.so.5.9
7ff51d73e000-7ff51d779000 r-xp 00000000 08:03 18819792                   /root/python36/lib/python3.6/site-packages/readline.cpython-36m-x86_64-linux-gnu.so
7ff51d779000-7ff51d979000 ---p 0003b000 08:03 18819792                   /root/python36/lib/python3.6/site-packages/readline.cpython-36m-x86_64-linux-gnu.so
7ff51d979000-7ff51d97b000 r--p 0003b000 08:03 18819792                   /root/python36/lib/python3.6/site-packages/readline.cpython-36m-x86_64-linux-gnu.so
7ff51d97b000-7ff51d982000 rw-p 0003d000 08:03 18819792                   /root/python36/lib/python3.6/site-packages/readline.cpython-36m-x86_64-linux-gnu.so
7ff51d982000-7ff51d9c4000 rw-p 00000000 00:00 0 
7ff51d9c4000-7ff51d9c6000 r-xp 00000000 08:03 35550108                   /usr/lib/python3.6/lib-dynload/_heapq.cpython-36m-x86_64-linux-gnu.so
7ff51d9c6000-7ff51dbc6000 ---p 00002000 08:03 35550108                   /usr/lib/python3.6/lib-dynload/_heapq.cpython-36m-x86_64-linux-gnu.so
7ff51dbc6000-7ff51dbc7000 r--p 00002000 08:03 35550108                   /usr/lib/python3.6/lib-dynload/_heapq.cpython-36m-x86_64-linux-gnu.so
7ff51dbc7000-7ff51dbc9000 rw-p 00003000 08:03 35550108                   /usr/lib/python3.6/lib-dynload/_heapq.cpython-36m-x86_64-linux-gnu.so
7ff51dbc9000-7ff5240f2000 r--p 00000000 08:03 16882256                   /usr/lib/locale/locale-archive
7ff5240f2000-7ff5242a8000 r-xp 00000000 08:03 65201                      /usr/lib64/libc-2.17.so
7ff5242a8000-7ff5244a8000 ---p 001b6000 08:03 65201                      /usr/lib64/libc-2.17.so
7ff5244a8000-7ff5244ac000 r--p 001b6000 08:03 65201                      /usr/lib64/libc-2.17.so
7ff5244ac000-7ff5244ae000 rw-p 001ba000 08:03 65201                      /usr/lib64/libc-2.17.so
7ff5244ae000-7ff5244b3000 rw-p 00000000 00:00 0 
7ff5244b3000-7ff5245b3000 r-xp 00000000 08:03 65209                      /usr/lib64/libm-2.17.so
7ff5245b3000-7ff5247b3000 ---p 00100000 08:03 65209                      /usr/lib64/libm-2.17.so
7ff5247b3000-7ff5247b4000 r--p 00100000 08:03 65209                      /usr/lib64/libm-2.17.so
7ff5247b4000-7ff5247b5000 rw-p 00101000 08:03 65209                      /usr/lib64/libm-2.17.so
7ff5247b5000-7ff5247b7000 r-xp 00000000 08:03 90003                      /usr/lib64/libutil-2.17.so
7ff5247b7000-7ff5249b6000 ---p 00002000 08:03 90003                      /usr/lib64/libutil-2.17.so
7ff5249b6000-7ff5249b7000 r--p 00001000 08:03 90003                      /usr/lib64/libutil-2.17.so
7ff5249b7000-7ff5249b8000 rw-p 00002000 08:03 90003                      /usr/lib64/libutil-2.17.so
7ff5249b8000-7ff5249ba000 r-xp 00000000 08:03 65207                      /usr/lib64/libdl-2.17.so
7ff5249ba000-7ff524bba000 ---p 00002000 08:03 65207                      /usr/lib64/libdl-2.17.so
7ff524bba000-7ff524bbb000 r--p 00002000 08:03 65207                      /usr/lib64/libdl-2.17.so
7ff524bbb000-7ff524bbc000 rw-p 00003000 08:03 65207                      /usr/lib64/libdl-2.17.so
7ff524bbc000-7ff524bd3000 r-xp 00000000 08:03 89995                      /usr/lib64/libpthread-2.17.so
7ff524bd3000-7ff524dd2000 ---p 00017000 08:03 89995                      /usr/lib64/libpthread-2.17.so
7ff524dd2000-7ff524dd3000 r--p 00016000 08:03 89995                      /usr/lib64/libpthread-2.17.so
7ff524dd3000-7ff524dd4000 rw-p 00017000 08:03 89995                      /usr/lib64/libpthread-2.17.so
7ff524dd4000-7ff524dd8000 rw-p 00000000 00:00 0 
???(??)

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 313934
nosy: chenkai
priority: normal
severity: normal
status: open
title: *** Error in `python': double free or corruption (out): 0x00007ff5254d50d0 ***
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33085>
_______________________________________

From report at bugs.python.org  Fri Mar 16 03:37:03 2018
From: report at bugs.python.org (Joshua Kinard)
Date: Fri, 16 Mar 2018 07:37:03 +0000
Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes
 followed by "; " instead of space
In-Reply-To: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za>
Message-ID: <1521185823.6.0.467229070634.issue32328@psf.upfronthosting.co.za>


Joshua Kinard <kumba at gentoo.org> added the comment:

I have to disagree rather strongly with closing this as "not a bug".  If the issue really boils down to incorrectly passing a single string when there is only one item in 'values', and a single-item tuple should be used instead, then shouldn't the better solution be for Python to handle this automatically and re-cast the errant string into a tuple?

My example indicates a case of where I got the Tcl interpreter itself to choke on invalid user input.  Even though the tkinter binding module catches the exception from the Tcl interpreter, I think it's Python's job as the wrapping language to catch any user stupidity done in Python and try to work around it if it's simple to do so.  A user coding against Tkinter/Ttk should not be required to have or need knowledge of Tcl/Tk itself to code a GUI.  That knowledge certainly helps, but not having it is one of Python's selling points for using Tkinter in the first place.

I have a coding project where I initially tripped up the semi-colon issue while parsing data from a text file into a Treeview widget (in listbox mode), that has a single-column.  The data being parsed included quoted regular expression syntax.  The function doing the parsing passed the parsed data to another function that populated the Treeview using **kwargs to send "values" and "tags" to Treeview's "insert" method.  It was a backslash character in the quoted regular expression string, at a point before the semi-colon, that eventually goofed the Tcl interpreter up, but //only// when passed in via **kwargs syntax.

The original code was too complex to replicate for the bug, so I reduced things down to a smaller testcase.  During this, I inadvertently tripped up the other bug with the unmatched open quote error, so I reported both.

My current workaround involves scanning the input for a backslash character or a whitespace character (which also trips things up), and if found, wrap the string in curly braces, which disables Tcl's substitution mechanism for that string, then calling Treeview's "insert" method.  It's more complicated this way, but safe for dealing with regular expression strings as possible input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32328>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:15:05 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Mar 2018 08:15:05 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521188105.95.0.467229070634.issue33083@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd suggest that in the not-float branch of math_factorial, we use PyNumber_Index to catch integer-like things. (That would also be consistent with what we do in math_gcd.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:20:52 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 16 Mar 2018 08:20:52 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521188452.55.0.467229070634.issue33073@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Eric Wieser (added to CC) actually just opened a PR for this against NumPy: https://github.com/numpy/numpy/pull/10741

I have weak and mixed feelings about the whole thing: https://github.com/numpy/numpy/pull/10741#issuecomment-373637440

----------
nosy: +Eric.Wieser

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:21:28 2018
From: report at bugs.python.org (Maheshwar Kumar)
Date: Fri, 16 Mar 2018 08:21:28 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521188488.01.0.467229070634.issue33084@psf.upfronthosting.co.za>


Maheshwar Kumar <mahesh3309 at gmail.com> added the comment:

Will just removing all np.nan values do the job? Btw the values will be:
median = 88.5
median_low = 85
median_high = 90
I can correct it and send a pull request.

----------
nosy: +maheshwark97

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:21:35 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 16 Mar 2018 08:21:35 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1521188495.72.0.467229070634.issue33073@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Sorry, I misspoke -- I meant he opened a related PR. The PR is to add as_integer_ratio to np.float16, np.float32, np.longdouble, not to add it to the numpy integer types. There are similar issues though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:43:08 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Mar 2018 08:43:08 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521189788.6.0.467229070634.issue33084@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Will just removing all np.nan values do the job?

Unfortunately, I don't think it's that simple. You want consistency across the various library calls, so if the various `median` functions are changed to treat NaNs as missing data, then the other functions should be, too.

----------
nosy: +mark.dickinson, steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:51:59 2018
From: report at bugs.python.org (Dmitry Andreychuk)
Date: Fri, 16 Mar 2018 08:51:59 +0000
Subject: [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1521190319.8.0.467229070634.issue21611@psf.upfronthosting.co.za>


Dmitry Andreychuk <and.dmitry at gmail.com> added the comment:

I created this issue almost 4 years ago. Looking at it now, I think that I was asking too much of that docstring. I believe it's current version quite sufficient.

I would close the issue, but I'm not sure if it's up to me to decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21611>
_______________________________________

From report at bugs.python.org  Fri Mar 16 04:55:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Mar 2018 08:55:49 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521190549.63.0.467229070634.issue33083@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I agree. And I suggest also to deprecate accepting integral float instances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Fri Mar 16 05:24:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Mar 2018 09:24:26 +0000
Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes
 followed by "; " instead of space
In-Reply-To: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za>
Message-ID: <1521192266.17.0.467229070634.issue32328@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> If the issue really boils down to incorrectly passing a single string when there is only one item in 'values', and a single-item tuple should be used instead, then shouldn't the better solution be for Python to handle this automatically and re-cast the errant string into a tuple?

Tkinter is rather a thin wrapper around Tcl/Tk. I just passes values to Tcl. Tcl is a weak typed language. Internally it can use different types for performance, but semantically all are strings. "a b" is a string and a 2-element list, and a 1-element dict at the same time. It is Tcl try to re-cast the errant string into a Tcl list, and fails because it has incorrect syntax. Python can't know your intention. It supposes that you know what you do. If under re-casting you meant passing a string to a tuple constructor, `tuple(values)`, this will be obviously wrong. If your meant parsing a string to a tuple at Python side -- it will file as well as parsing it at Tcl side. If you meant wrapping a string into a one-element tuple, `(values,)`, this can break working code when a user intentionally passes a space separated list of words:

    tv.insert("", END, values=(foo, bar), tags="foo bar")

Additionally, any special cases will complicate the code of Tkinter (currently it is rather a thin wrapper) and complicate the mental model.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32328>
_______________________________________

From report at bugs.python.org  Fri Mar 16 06:34:50 2018
From: report at bugs.python.org (Jonathan)
Date: Fri, 16 Mar 2018 10:34:50 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521196490.12.0.467229070634.issue33034@psf.upfronthosting.co.za>


Jonathan <bugreports at lightpear.com> added the comment:

Interesting conversation

As I see it, there are two ways to solve this, both discussed above:
A) Python can compute and ValueError at parse-time
B) Python can ValueError at property-call time. (Current method)

But both have Advantages/Disadvantages.
A - Pros) - The function is more consistent with all the other Python builtins (well, the one's I've dealt with).
A - Pros) - Not carrying around a "bad" port.
A - Cons) - As Matt suggests, we could be "taking something from the user" because they may want the other values. (although in that case, the current semi-related behaviour: "Unmatched square brackets in the netloc attribute will raise a ValueError" is also potentially taking something from the user).

B - Pros) - User gets the other values even if they don't get the port.
B - Cons) - User needs to have more Try/Excepts in the code (whereever you may access the property), or to write their own wrapper function.


Given the above, of the those options I still think option (A) is better. The other values may have a reduced worth if the port is invalid (depending on the user's goal).

May I suggest a third option:
C) A flag for urlsplit/urlparse to indicate we don't want to do port validation, and to just return whatever it thinks is there. (example.com:3293849038 would return 3293849038. example.com:gibberish would return "gibberish" etc). 

This way the user can choose what behaviour they want with the bad port and test the value of the port themselves if they care (something I was going to do anyway before I discovered it was included in the builtin). Some of the url quoting functions have a similar flag ("errors") for handling bad data transparently or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Fri Mar 16 06:56:45 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 16 Mar 2018 10:56:45 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521197805.56.0.467229070634.issue33077@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Apart from the fact that it's too late, if you had to do it over again,
could it be done as a class decorator?

Yes, this could be done as a decorator which would replace the original class with a named tuple after inspecting `__annotations__` and `__dict__`. (But again, the name would be different, since `@NamedTuple` looks weird to me.)

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Fri Mar 16 07:10:26 2018
From: report at bugs.python.org (Ben Feinstein)
Date: Fri, 16 Mar 2018 11:10:26 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1521123714.68.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <CA+U30-D8jO-pcrT7ikRo0Mgm_CyZDhpSbqDKaxV7hyvUL5dHoA@mail.gmail.com>


Ben Feinstein <feinsteinben at gmail.com> added the comment:

General loggers are used in the standard way (message, args, etc), but data
loggers are used for different types of data. Instead of message, they
receive the experiment results (dict/list/np.array/binary data) and their
`formatMessage()` method should be modified in order to account for the
changed data-type.

This might indeed be an XY problem on my side. However, it seems that
someone already thought about it before and started implementing this
mechanism (`Manager.setLogRecordFactory()`), but didn't finish. That's why
I suggested this modification.

On Thu, Mar 15, 2018 at 4:21 PM Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> >  I have two types of loggers, one for experiment results ("data") and
> another for general information
>
> In what way is the behaviour of the two types of logger different? I'm
> concerned that this might be an XY problem ...
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33057>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Fri Mar 16 07:15:41 2018
From: report at bugs.python.org (Matt Eaton)
Date: Fri, 16 Mar 2018 11:15:41 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521198941.8.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Jonathan, thank you very much for your thoughts I appreciate the pros and cons of each option.

In regards to your option C, if we provided a flag to optionally raise the error in urlsplit and urlparse were you thinking the default flag to be set to True?  

For example:

def urlparse(url, scheme='', allow_fragments=True, port_validation=True):


def urlsplit(url, scheme='', allow_fragments=True, port_validation=True):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Fri Mar 16 07:24:53 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 16 Mar 2018 11:24:53 +0000
Subject: [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1521199493.93.0.467229070634.issue21611@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Documentation for int constructor mentions __int__ but not __trunc__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21611>
_______________________________________

From report at bugs.python.org  Fri Mar 16 09:34:39 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 16 Mar 2018 13:34:39 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1521207279.61.0.467229070634.issue1100942@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hello, just a small reminder for this issue and the PR ;-) when you have time

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Fri Mar 16 09:59:58 2018
From: report at bugs.python.org (Maheshwar Kumar)
Date: Fri, 16 Mar 2018 13:59:58 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521208798.53.0.467229070634.issue33084@psf.upfronthosting.co.za>


Maheshwar Kumar <mahesh3309 at gmail.com> added the comment:

Well if i dont consider np.nan as missing data and consider all other values then the answer being 90 is correct,right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 10:32:36 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Mar 2018 14:32:36 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521210756.02.0.467229070634.issue33084@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> then the answer being 90 is correct,right?

How do you deduce that? Why 90 rather than 85 (or 87.5, or some other value)?

For what it's worth, NumPy gives a result of NaN for the median of an array that contains NaNs:

>>> np.median([1.0, 2.0, 3.0, np.nan])
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/function_base.py:4033: RuntimeWarning: Invalid value encountered in median
  r = func(a, **kwargs)
nan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 11:08:17 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Fri, 16 Mar 2018 15:08:17 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1521212897.06.0.467229070634.issue33036@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

Update -- I found the following plist at `/Library/LaunchDaemons/limit.maxfiles.plist`:

```xml
<?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>limit.maxfiles</string>
    <key>ProgramArguments</key>
    <array>
      <string>launchctl</string>
      <string>limit</string>
      <string>maxfiles</string>
      <string>64000</string>
      <string>524288</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>ServiceIPC</key>
    <false/>
  </dict>
</plist>
```

I think I made this file at some point to deal with an error about insufficient file descriptors while playing with asyncio / sockets. After `launchctl unload`ing it and rebooting **the test now passes**, and I now see a *much* higher hard limit (similar to that posted by Ned) with the `getrlimit()` command, and `unlimited` as the hard limit with `launchtl limit`.

I can reproduce the failure by restoring my prior settings:

```bash
$ sudo launchctl limit maxfiles 64000 524288
$ ulimit -n 64000
$ 
$ ./python.exe -m unittest -v test.test_selectors.PollSelectorTestCase.test_above_fd_setsize
test_above_fd_setsize (test.test_selectors.PollSelectorTestCase) ... ERROR

======================================================================
ERROR: test_above_fd_setsize (test.test_selectors.PollSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/n8henrie/git/cpython/Lib/test/support/__init__.py", line 600, in wrapper
    return func(*args, **kw)
  File "/Users/n8henrie/git/cpython/Lib/test/test_selectors.py", line 453, in test_above_fd_setsize
    self.assertEqual(NUM_FDS // 2, len(s.select()))
  File "/Users/n8henrie/git/cpython/Lib/selectors.py", line 376, in select
    fd_event_list = self._poll.poll(timeout)
OSError: [Errno 22] Invalid argument

----------------------------------------------------------------------
Ran 1 test in 9.771s

FAILED (errors=1)

```

----------
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Fri Mar 16 11:49:22 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 15:49:22 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1521215362.28.0.467229070634.issue33036@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Glad you found the problem - and that it wasn't a Python bug!

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:15:15 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 16 Mar 2018 16:15:15 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521210756.02.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <20180316161508.GE16661@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Mar 16, 2018 at 02:32:36PM +0000, Mark Dickinson wrote:
> For what it's worth, NumPy gives a result of NaN for the median of an array that contains NaNs:

By default, R gives the median of a list containing either NaN or NA 
("not available", intended as a missing value) as NA:

> median(c(1, 2, 3, 4, NA))
[1] NA
> median(c(1, 2, 3, 4, NaN))
[1] NA

but you can ignore them too:

> median(c(1, 2, 3, 4, NA), na.rm=TRUE)
[1] 2.5
> median(c(1, 2, 3, 4, NaN), na.rm=TRUE)
[1] 2.5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:20:53 2018
From: report at bugs.python.org (Marcel Plch)
Date: Fri, 16 Mar 2018 16:20:53 +0000
Subject: [issue29673] Some gdb macros are broken in 3.6
In-Reply-To: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za>
Message-ID: <1521217253.49.0.467229070634.issue29673@psf.upfronthosting.co.za>


Change by Marcel Plch <gmarcel.plch at gmail.com>:


----------
keywords: +patch
pull_requests: +5888
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29673>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:36:55 2018
From: report at bugs.python.org (Marcel Plch)
Date: Fri, 16 Mar 2018 16:36:55 +0000
Subject: [issue29673] Some gdb macros are broken in 3.6
In-Reply-To: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za>
Message-ID: <1521218215.94.0.467229070634.issue29673@psf.upfronthosting.co.za>


Marcel Plch <gmarcel.plch at gmail.com> added the comment:

I have created a PR here - https://github.com/python/cpython/pull/6126

The problem was, indeed, change in the code structure. The macro checked for presence inside of PyEval_EvalFrame() using address of a neighbouring function.
Also, arguments to PyEval_EvalFrame() were changed, so the macro responsible for printing of the frame needed a little tweak.

----------
nosy: +Dormouse759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29673>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:42:58 2018
From: report at bugs.python.org (Arun Persaud)
Date: Fri, 16 Mar 2018 16:42:58 +0000
Subject: [issue21018] [patch] added missing documentation about escaping
 characters for configparser
In-Reply-To: <1520894042.94.0.467229070634.issue21018@psf.upfronthosting.co.za>
Message-ID: <be2fbfe7-aaf4-8789-16fb-4524df47a200@gmail.com>


Arun Persaud <arun.persaud at gmail.com> added the comment:

> @Arun.Persaud, would you be interested in converting your patch to a Github pull request?

sure, I'll give it a try.

Arun

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21018>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:45:41 2018
From: report at bugs.python.org (Luc)
Date: Fri, 16 Mar 2018 16:45:41 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521218741.48.0.467229070634.issue33084@psf.upfronthosting.co.za>


Luc <ouaganet at gmail.com> added the comment:

Just to make sure we are focused on the issue, the reported bug is with the statistics library (not with numpy). It happens, when there is at least one missing value in the data and involves the computation of the median, median_low and median_high using the statistics library.
The test was performed on Python 3.6.4.

When there is no missing values (NaNs) in the data, computing the median, median_high and median_low from the statistics library work fine.
So, yes, removing the NaNs (or imputing for them) before computing the median(s) resolve the issue.
Also, just like statistics.mean(data) when data has missing return a nan, the median, median_high and median_low should  behave the same way.

import numpy
import statistics as stats

data = [75, 90,85, 92, 95, 80, np.nan]

Median = stats.median(data) 
Median_high = stats.median_high(data)
Median_low = stats.median_low(data)
print("The incorrect Median is", Median)
The incorrect Median is, 90
print("The incorrect median high is", Median_high)
The incorrect median high is, 90
print("The incorrect median low is", Median_low)
The incorrect median low is, 90

## Mean returns nan
Mean = stats.mean(data)
prin("The mean is", Mean)
The mean is, nan

Now, when we drop the missing values, we have:
data2 = [75, 90,85, 92, 95, 80]
stats.median(data2)
87.5
stats.median_high(data2)
90
stats.median_low(data2)
85

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:45:53 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Mar 2018 16:45:53 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521218753.61.0.467229070634.issue33077@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Would it be worthwhile to show an example of a subclass that overrides or extends  __new__?   

Elsewhere in Python, the usual technique for changing method defaults is for a subclass to override or extend the method in question.  

    class A:
        def somemeth(self, value: bool = True):
            print(value)

    class B(A):
        def somemeth(self, value: bool = False):
            super().somemeth(value)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:58:08 2018
From: report at bugs.python.org (Gabriel Hearot)
Date: Fri, 16 Mar 2018 16:58:08 +0000
Subject: [issue33086] pip: IndexError
Message-ID: <1521219488.5.0.467229070634.issue33086@psf.upfronthosting.co.za>


New submission from Gabriel Hearot <gabriel at hearot.it>:

Traceback (most recent call last):
  File "setup.py", line 45, in <module>
    classifiers=[]
  File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.6/distutils/command/upload.py", line 63, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/lib/python3.6/distutils/command/upload.py", line 156, in upload_file
    value = value[1]
IndexError: tuple index out of range

----------
components: Library (Lib)
messages: 313958
nosy: hearot
priority: normal
severity: normal
status: open
title: pip: IndexError
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33086>
_______________________________________

From report at bugs.python.org  Fri Mar 16 12:58:54 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 16 Mar 2018 16:58:54 +0000
Subject: [issue32476] Add concat functionality to ElementTree xpath find
In-Reply-To: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>
Message-ID: <1521219534.01.0.467229070634.issue32476@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I can't see why this should be restricted to attribute values and not text content in general. Therefore, I would suggest adding general support for functions, and making this only a special case. Otherwise, this would only solve a very niche problem, and would require pretty much a rewrite in order to extend it into the "obvious" direction.

----------
components: +XML

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Fri Mar 16 13:43:46 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Mar 2018 17:43:46 +0000
Subject: [issue33086] pip: IndexError
In-Reply-To: <1521219488.5.0.467229070634.issue33086@psf.upfronthosting.co.za>
Message-ID: <1521222226.48.0.467229070634.issue33086@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

You did not provide enough information for us to reproduce this problem. To see the kind of information we need, see for example https://leantesting.com/write-good-bug-report/

And if you already have determined this is a problem with pip, they have their own issue tracker: https://github.com/pypa/pip/issues

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33086>
_______________________________________

From report at bugs.python.org  Fri Mar 16 13:44:07 2018
From: report at bugs.python.org (Elliot Jenner)
Date: Fri, 16 Mar 2018 17:44:07 +0000
Subject: [issue33087] No reliable clean shutdown method
Message-ID: <1521222247.28.0.467229070634.issue33087@psf.upfronthosting.co.za>


New submission from Elliot Jenner <Void2258 at gmail.com>:

Ptyhon lacks a reliable clean shutdown method. sys.exit(), which should be this method, does not reliably perform this function as it merely terminates the thread it is called from (duplicating the functionality of thread.exit()), exit() and quit() are not supposed to be used except in terminal windows, raise SystemExit has the same issues as sys.exit() and is bad practice, and os._exit() immediately kills everything and does not clean up, which can cause issues with residuals.

This is especially important as some interpreters will break calls (including most worryingly try-except clauses) into threads invisibly, leading to whichever method is used being called in a non-main thread without anything the programmer can do about it even when you are not intentionally using threading.

Ideally, sys.exit() should be changed to properly close down the entire program, as there is no need for 2 functionally identical exit functions, but this may cause legacy issues. Regardless, a method that ALWAYS kill the program and all threads while still cleaning up, regardless of where it is called from, is needed.

----------
components: Library (Lib)
messages: 313961
nosy: Void2258
priority: normal
severity: normal
status: open
title: No reliable clean shutdown method
type: behavior
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/issue33087>
_______________________________________

From report at bugs.python.org  Fri Mar 16 13:47:38 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 16 Mar 2018 17:47:38 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
Message-ID: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi <levkivskyi at gmail.com>:

This is clearly a bug. Would you like to make a PR?

----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Fri Mar 16 13:47:54 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 16 Mar 2018 17:47:54 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521222474.44.0.467229070634.issue33061@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Fri Mar 16 13:51:34 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 16 Mar 2018 17:51:34 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521222694.89.0.467229070634.issue33061@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yes please! Updating __all__ is too easy to forget.

IIRC there are scripts that check for this but they are too strict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Fri Mar 16 14:10:26 2018
From: report at bugs.python.org (Jeff DuMonthier)
Date: Fri, 16 Mar 2018 18:10:26 +0000
Subject: [issue33088] Cannot pass a SyncManager proxy to a multiprocessing
 subprocess on Windows
Message-ID: <1521223826.02.0.467229070634.issue33088@psf.upfronthosting.co.za>


New submission from Jeff DuMonthier <jeffrey.j.dumonthier at nasa.gov>:

The following simple example code creates a started SyncManager and passes it as an argument to a subprocess started with multiprocessing.Process().  It works on Linux and Mac OS but fails on Windows.

import multiprocessing as mp

def subProcFn(m1):
    pass
    
if __name__ == "__main__":

    __spec__ = None
    
    m1 = mp.Manager()
    
    p1 = mp.Process(target=subProcFn, args=(m1,))
    p1.start()
    p1.join()

This is the traceback in Spyder:

runfile('D:/ManagerBug.py', wdir='D:')
Traceback (most recent call last):

  File "<ipython-input-1-534b9087bae9>", line 1, in <module>
    runfile('D:/ManagerBug.py', wdir='D:')

  File "...\anaconda3\lib\site-packages\spyder\utils\site\sitecustomize.py", line 705, in runfile
    execfile(filename, namespace)

  File "...\anaconda3\lib\site-packages\spyder\utils\site\sitecustomize.py", line 102, in execfile
    exec(compile(f.read(), filename, 'exec'), namespace)

  File "D:/ManagerBug.py", line 22, in <module>
    p1.start()

  File "...\anaconda3\lib\multiprocessing\process.py", line 105, in start
    self._popen = self._Popen(self)

  File "...\anaconda3\lib\multiprocessing\context.py", line 223, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)

  File "...\anaconda3\lib\multiprocessing\context.py", line 322, in _Popen
    return Popen(process_obj)

  File "...\anaconda3\lib\multiprocessing\popen_spawn_win32.py", line 65, in __init__
    reduction.dump(process_obj, to_child)

  File "...\anaconda3\lib\multiprocessing\reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)

TypeError: can't pickle weakref objects

----------
components: Windows
messages: 313964
nosy: jjdmon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot pass a SyncManager proxy to a multiprocessing subprocess on Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33088>
_______________________________________

From report at bugs.python.org  Fri Mar 16 14:25:23 2018
From: report at bugs.python.org (Maheshwar Kumar)
Date: Fri, 16 Mar 2018 18:25:23 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521224723.8.0.467229070634.issue33084@psf.upfronthosting.co.za>


Maheshwar Kumar <mahesh3309 at gmail.com> added the comment:

So From the above i am to conclude that removing np.nan is the best path to be taken? Also the above step is to be included in median_grouped as well right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 14:50:11 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 16 Mar 2018 18:50:11 +0000
Subject: [issue33053] Running a module with `-m` will add empty directory to
 sys.path
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521226211.18.0.467229070634.issue33053@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

FWIW, this behavior is documented:

https://docs.python.org/3/using/cmdline.html#cmdoption-m
"As with the -c option, the current directory will be added to the start of sys.path."

With the -c option, at least you could easily remove the sys.path element yourself:

   python -c 'import sys; sys.path.remove(""); ...'

(This works, because sys is always a builtin module, so it won't be imported from cwd.)

I don't see any obvious way to make "python -m foo" secure in untrusted cwd, though.
The best I could come up with is:

   python -c 'import sys; sys.path.remove(""); import runpy; runpy._run_module_as_main("foo")'

which is quite insane.

----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Fri Mar 16 14:50:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Mar 2018 18:50:58 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
Message-ID: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

A need for a distance-between-two-points function arises frequently enough to warrant consideration for inclusion in the math module.   It shows-up throughout mathematics -- everywhere from simple homework problems for kids to machine learning and computer vision.

In the latter cases, the function is called frequently and would benefit from a fast C implementation that includes good error checking and is algorithmically smart about numerical issues such as overflow and loss-of-precision.

A simple implementation would be something like this:

    def dist(p, q):
        'Multi-dimensional Euclidean distance'
        # XXX needs error checking:  len(p) == len(q)
        return sqrt(sum((x0 - x1) ** 2 for x0, x1 in zip(p, q)))

The implementation could also include value added features such as hypot() style scaling to mitigate overflow during the squaring step:

    def dist2(p, q):
        # https://en.wikipedia.org/wiki/Hypot#Implementation
        diffs = [x0 - x1 for x0, x1 in zip(p, q)]
        scale = max(diffs, key=abs)
        return abs(scale) * sqrt(fsum((d/scale) ** 2 for d in diffs))

----------
components: Library (Lib)
messages: 313967
nosy: mark.dickinson, rhettinger, skrah, steven.daprano, tim.peters
priority: normal
severity: normal
status: open
title: Add multi-dimensional Euclidean distance function to the math module
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Fri Mar 16 14:56:03 2018
From: report at bugs.python.org (David Rebbe)
Date: Fri, 16 Mar 2018 18:56:03 +0000
Subject: [issue32822] finally block doesn't re-raise exception if return
 statement exists inside
In-Reply-To: <1518387497.4.0.467229070634.issue32822@psf.upfronthosting.co.za>
Message-ID: <1521226563.5.0.467229070634.issue32822@psf.upfronthosting.co.za>


David Rebbe <drebbe at intrepidcs.com> added the comment:

I'll have to look into this as I have yet to commit anything but I'll put it on my list of things to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32822>
_______________________________________

From report at bugs.python.org  Fri Mar 16 15:27:09 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Mar 2018 19:27:09 +0000
Subject: [issue30940] Documentation for round() is incorrect.
In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za>
Message-ID: <1521228429.85.0.467229070634.issue30940@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> lisroach
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30940>
_______________________________________

From report at bugs.python.org  Fri Mar 16 15:38:27 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 16 Mar 2018 19:38:27 +0000
Subject: [issue33087] No reliable clean shutdown method
In-Reply-To: <1521222247.28.0.467229070634.issue33087@psf.upfronthosting.co.za>
Message-ID: <1521229107.65.0.467229070634.issue33087@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

To my knowledge, there is no safe way to do this for other threads for a reason.

If you make all your worker threads daemons, then they will terminate with the main thread, but they won't perform cleanup actions.

If you don't make them daemons, any "clean exit" procedure risks the threads choosing not to exit (even if you inject a SystemExit into every other thread, they might be in a try/except: or try/finally that suppresses it, or blocks waiting for something from another thread that has already exited, etc.). Exiting the thread that calls sys.exit() this way is considered okay, since you control when it is called, and it's up to you to do it at a safe place, but doing so asynchronously in other threads introduces all sorts of problems.

Basically, you want a reliable "shut down the process" and a reliable "clean up every thread", but anything that allows clean up in arbitrary threads also allows them to block your desired "shut down the process". Do you have a proposal for handling this?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33087>
_______________________________________

From report at bugs.python.org  Fri Mar 16 15:43:10 2018
From: report at bugs.python.org (Robert Xiao)
Date: Fri, 16 Mar 2018 19:43:10 +0000
Subject: [issue33090] race condition between send and recv in _ssl with
 non-zero timeout
Message-ID: <1521229390.38.0.467229070634.issue33090@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

Environment: Several versions of Python (see below), macOS 10.12.6

The attached script creates an SSL echo server (fairly standard), connects to the server, and spawns a read and write thread.

The write thread repeatedly shovels data into the connection, while the read thread receives data and prints a dot for each successful read.

The socket has a timeout of 10 seconds set: if the timeout is 0, the script blows up immediately due to blocking, and if the timeout is -1 nothing bad happens.

On Linux and the default Mac Python 2.6, the script prints an endless series of dots as expected.

On most other versions of Mac Python (2.7, 3.5, 3.6), the script dies quite quickly (within 1-2 seconds) with an error like this:


$ /usr/bin/python2.7 test_ssl.py 
Got connection from ('127.0.0.1', 49683)
..................................Exception in thread ReadThread:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "test_ssl.py", line 93, in read_thread
    csocket.recv()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 734, in recv
    return self.read(buflen)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 621, in read
    v = self._sslobj.read(len or 1024)
error: [Errno 35] Resource temporarily unavailable


The error can be one of the following:

[Py2.7] error: [Errno 35] Resource temporarily unavailable
[Py2.7] SSLWantReadError: The operation did not complete (read) (_ssl.c:1752)
[Py3.x] BlockingIOError: [Errno 35] Resource temporarily unavailable
[Py3.x] ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:1974)
[Py3.6] ssl.SSLError: Invalid error code (_ssl.c:2217)

The last error occurs under much rarer circumstances, but appears to be associated with the same underlying bug. The "invalid error code" is 0 when tested with a debugger, indicating a successful completion (but somehow the error logic gets triggered anyway).

This was tested with the following configurations:

macOS: /usr/bin/python2.6: Python 2.6.9 from Apple [ok]
macOS: /usr/bin/python2.7: Python 2.7.10 from Apple [crashes]
macOS: /usr/local/bin/python2.7: Python 2.7.13 from Python.org [crashes]
macOS: /usr/local/bin/python3.5: Python 3.5.1 from Python.org [crashes]
macOS: /usr/local/bin/python3.6: Python 3.6.4 from Python.org [crashes]
macOS: /opt/local/bin/python2.7: Python 2.7.14 from MacPorts [crashes]

A number of these were tested on a second machine (to rule out any strange environment issues), and the same results were obtained.

----------
assignee: christian.heimes
components: SSL, macOS
files: test_ssl.py
messages: 313970
nosy: christian.heimes, ned.deily, nneonneo, ronaldoussoren
priority: normal
severity: normal
status: open
title: race condition between send and recv in _ssl with non-zero timeout
type: crash
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47489/test_ssl.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33090>
_______________________________________

From report at bugs.python.org  Fri Mar 16 15:45:01 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 16 Mar 2018 19:45:01 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1521229501.67.0.467229070634.issue25410@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Is this issue still relevant?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Fri Mar 16 15:56:27 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Mar 2018 19:56:27 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521230187.57.0.467229070634.issue33061@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5889
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Fri Mar 16 15:59:01 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Mar 2018 19:59:01 +0000
Subject: [issue33086] pip: IndexError
In-Reply-To: <1521219488.5.0.467229070634.issue33086@psf.upfronthosting.co.za>
Message-ID: <1521230341.86.0.467229070634.issue33086@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33086>
_______________________________________

From report at bugs.python.org  Fri Mar 16 16:07:07 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 20:07:07 +0000
Subject: [issue33053] Running a module with `-m` will add empty directory to
 sys.path
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521230827.69.0.467229070634.issue33053@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Fri Mar 16 16:08:00 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Mar 2018 20:08:00 +0000
Subject: [issue33088] Cannot pass a SyncManager proxy to a multiprocessing
 subprocess on Windows
In-Reply-To: <1521223826.02.0.467229070634.issue33088@psf.upfronthosting.co.za>
Message-ID: <1521230880.32.0.467229070634.issue33088@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33088>
_______________________________________

From report at bugs.python.org  Fri Mar 16 17:14:39 2018
From: report at bugs.python.org (Luc)
Date: Fri, 16 Mar 2018 21:14:39 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521234879.72.0.467229070634.issue33084@psf.upfronthosting.co.za>


Luc <ouaganet at gmail.com> added the comment:

If we are trying to fix this, the behavior should be like computing the mean or harmonic mean with the statistics library when there are missing values in the data.  At least that way, it is consistent with how the statistics library works when computing with NaNs in the data.  Then again, it should be mentioned somewhere in the docs.

import statistics as stats
import numpy as np
import pandas as pd
data = [75, 90,85, 92, 95, 80, np.nan]
stats.mean(data)
nan
stats.harmonic_mean(data)
nan
stats.stdev(data)
nan
As you can see, when there is a missing value, computing the mean, harmonic mean and sample standard deviation with the statistics library 
return a nan.
However, with the median, median_high and median_low, it computes those statistics incorrectly with the missing values present in the data.
It is better to return a nan, then let the user drop (or resolve) any missing values before computing.
## Another example using pandas serie
df = pd.DataFrame(data, columns=['data'])
df.head()
        data
0	75.0
1	90.0
2	85.0
3	92.0
4	95.0
5	80.0
6	NaN

### Use the statistics library to compute the median of the serie
stats.median(df1['data'])
90
 
## Pandas returns the correct median by dropping the missing values
## Now use pandas to compute the median of the serie with missing value
df['data'].median()
87.5

I did not test the median_grouped in statistics library, but will let you know afterwards if its affected as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33084>
_______________________________________

From report at bugs.python.org  Fri Mar 16 17:22:01 2018
From: report at bugs.python.org (Alfred Krohmer)
Date: Fri, 16 Mar 2018 21:22:01 +0000
Subject: [issue33091] ssl.SSLError: Invalid error code (_ssl.c:2217)
Message-ID: <1521235321.12.0.467229070634.issue33091@psf.upfronthosting.co.za>


New submission from Alfred Krohmer <devkid at devkid.net>:

OpenSSL version: 1.1.0.g-1
OS: Arch Linux

I'm creating an SSL socket like this:

    s = socket.create_connection((self.host, 443), 60)
    c = ssl.create_default_context()
    c.set_alpn_protocols(['spdy/2'])
    self.ss = c.wrap_socket(s, server_hostname=self.host)

I'm then reading from the socket in one thread and writing to it in another thread.

I'm experiencing strange behaviour.

Sometimes I randomly get the error message in the title when invoking self.ss.recv(). After investigating the exception, I found that exc.errno = 10, which, according to the OpenSSL documentation means SSL_ERROR_WANT_ASYNC_JOB. This constant is never used in the _ssl.c file in cpython. This seems to me like an OpenSSL error that needs to be handled in the Python implementation but is not.

Also sometimes I have random write timeouts when invoking self.ss.send() (in those cases it seems unlikely to me that those are caused by the server).

Also I found here:

https://github.com/python/cpython/blob/v3.6.4/Modules/_ssl.c#L2184

that Python uses SSL_get_error in an non-mutex locked section. But the OpenSSL documentation of SSL_get_error states the following:

    In addition to ssl and ret, SSL_get_error() inspects the current thread's OpenSSL error queue. Thus, SSL_get_error() must be used in the same thread that performed the TLS/SSL I/O operation, and no other OpenSSL function calls should appear in between. The current thread's error queue must be empty before the TLS/SSL I/O operation is attempted, or SSL_get_error() will not work reliably.

According to that, shouldn't the _PySSL_UPDATE_ERRNO_IF macro be called *after* PySSL_END_ALLOW_THREADS?

----------
assignee: christian.heimes
components: SSL
messages: 313973
nosy: christian.heimes, devkid
priority: normal
severity: normal
status: open
title: ssl.SSLError: Invalid error code (_ssl.c:2217)
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33091>
_______________________________________

From report at bugs.python.org  Fri Mar 16 17:32:49 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2018 21:32:49 +0000
Subject: [issue33044] pdb from base class, get inside a method of derived class
In-Reply-To: <1520718085.04.0.467229070634.issue33044@psf.upfronthosting.co.za>
Message-ID: <1521235969.18.0.467229070634.issue33044@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

bugs.python.org is for issues about patching the Python docs or the CPython implementation, for future releases.  Questions about using python/cpython should go to Q&A forums, such a python-list or Stackoverflow.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33044>
_______________________________________

From report at bugs.python.org  Fri Mar 16 17:55:23 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2018 21:55:23 +0000
Subject: [issue33049] itertools.count() confusingly mentions zip() and
 sequence numbers
In-Reply-To: <1520792191.75.0.467229070634.issue33049@psf.upfronthosting.co.za>
Message-ID: <1521237323.05.0.467229070634.issue33049@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think 'sequential numbers' would be slightly better than 'sequence numbers'.  To be, it better includes stepped and descending sequences.  (Enough better that I would be willing to do the PR and merge.)  Otherwise, I think leave it alone.

----------
nosy: +terry.reedy
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33049>
_______________________________________

From report at bugs.python.org  Fri Mar 16 18:01:24 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Mar 2018 22:01:24 +0000
Subject: [issue33049] itertools.count() confusingly mentions zip() and
 sequence numbers
In-Reply-To: <1520792191.75.0.467229070634.issue33049@psf.upfronthosting.co.za>
Message-ID: <1521237684.25.0.467229070634.issue33049@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Since I don't like "sequential numbers", let's opt for the "leave it alone" option :-)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33049>
_______________________________________

From report at bugs.python.org  Fri Mar 16 18:12:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2018 22:12:18 +0000
Subject: [issue33055] bytes does not implement __bytes__()
In-Reply-To: <1520864882.07.0.467229070634.issue33055@psf.upfronthosting.co.za>
Message-ID: <1521238338.11.0.467229070634.issue33055@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

It is against Guido's general policy to add things not needed purely for consistency.  Unless there is a compelling use case, I think this should be closed.

FHTM: I don't think Serhiy posts on SO, so you might consider adding his answer to yours, or make it a separate answer.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33055>
_______________________________________

From report at bugs.python.org  Fri Mar 16 18:31:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2018 22:31:24 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
In-Reply-To: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>
Message-ID: <1521239484.45.0.467229070634.issue33047@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I copied the three lines into a file, deleted '> ', added  print('done'), and saved.  I ran the file, on Windows 10, with installed 2.7, 3.5, 3.6, and repository 3.6, 3.7, and 3.8.  No failures.
  
Adrien, please retest by copying what you posted, and if you still get a failure, upgrade to 3.6.4 and try again.  Unless we see a failure on another machine, this should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33047>
_______________________________________

From report at bugs.python.org  Fri Mar 16 19:48:54 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 16 Mar 2018 23:48:54 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521244134.07.0.467229070634.issue33089@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This was requested once before, but rejected. I would like to see that decision re-considered.

https://bugs.python.org/issue1880

Some months ago, there was a very brief discussion started by Lawrence D?Oliveiro about this on the comp.lang.python newsgroup. Unfortunately neither his posts nor any replies to them seem to have been archived at the Python-List mailing list. His original post is on google groups:

https://groups.google.com/forum/#!topic/comp.lang.python/GmrGx9QQINQ

but I see no replies there. There is one reply on comp.lang.python, from Stefan Ram, but that doesn't appear on either the mailing list or Google Groups.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Fri Mar 16 19:57:41 2018
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 16 Mar 2018 23:57:41 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521244661.85.0.467229070634.issue33021@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Antoine, thanks for fixing this on master! but I don't think this issue
can be closed yet.

First, the issue is not a performance but reliability. I probably made 
bad choice when I marked this as performance.

When you call mmap.mmap() in one thread, the entire process hangs for
an hour because the file descriptor is on a non-responsive NFS server.

With the fix, only the thread accessing the file descriptor is affected.
The rest of the system can function normally.

Second, the issue affects python 2.7, which is the production version on
many servers, and will be for many years e.g. on RHEL/CentOS 7. I think
it is important to fix this issue for these users.

Here is examples of the issue using reproducer scripts I uploaded to the
bug.

When mmap.mmap block, the entire process hangs. I unblocked the process from 
another shell by removing the iptables rule.

# python bpo-33021/mmap_nfs_test.py mnt dumbo.tlv.redhat.com
2018-03-17 01:17:57,846 - (MainThread) - Starting canary thread
2018-03-17 01:17:57,846 - (Canary) - Blocking access to storage
2018-03-17 01:17:57,857 - (Canary) - If this test is hang, please run: iptables -D OUTPUT -p tcp -d dumbo.tlv.redhat.com --dport 2049 -j DROP
2018-03-17 01:17:57,857 - (Canary) - check 0
2018-03-17 01:17:58,858 - (Canary) - check 1
2018-03-17 01:17:59,858 - (Canary) - check 2
2018-03-17 01:18:00,859 - (Canary) - check 3
2018-03-17 01:18:01,859 - (Canary) - check 4
2018-03-17 01:18:02,859 - (Canary) - check 5
2018-03-17 01:18:03,860 - (Canary) - check 6
2018-03-17 01:18:04,860 - (Canary) - check 7
2018-03-17 01:18:05,861 - (Canary) - check 8
2018-03-17 01:18:06,861 - (Canary) - check 9
2018-03-17 01:18:07,862 - (Canary) - check 10
2018-03-17 01:18:07,868 - (MainThread) - Calling mmap.mmap

(I remove the iptables rule here)

2018-03-17 01:18:57,683 - (MainThread) - OK
2018-03-17 01:18:57,683 - (MainThread) - Done
2018-03-17 01:18:57,683 - (Canary) - check 11

When mmapobject.size() was called, the entire process was hang. I unblocked the
process from another shell by removing the iptables rule.

# python bpo-33021/mmap_size_nfs_test.py mnt dumbo.tlv.redhat.com
2018-03-17 01:22:17,991 - (MainThread) - Starting canary thread
2018-03-17 01:22:17,992 - (Canary) - Blocking access to storage
2018-03-17 01:22:18,001 - (Canary) - If this test is hang, please run: iptables -D OUTPUT -p tcp -d dumbo.tlv.redhat.com --dport 2049 -j DROP
2018-03-17 01:22:18,001 - (Canary) - check 0
2018-03-17 01:22:19,002 - (Canary) - check 1
2018-03-17 01:22:20,002 - (Canary) - check 2
2018-03-17 01:22:21,002 - (Canary) - check 3
2018-03-17 01:22:22,003 - (Canary) - check 4
2018-03-17 01:22:23,003 - (Canary) - check 5
2018-03-17 01:22:24,004 - (Canary) - check 6
2018-03-17 01:22:25,004 - (Canary) - check 7
2018-03-17 01:22:26,004 - (Canary) - check 8
2018-03-17 01:22:27,005 - (Canary) - check 9
2018-03-17 01:22:28,005 - (MainThread) - Calling mmapobject.size

(I removed the ipatables rule here)

2018-03-17 01:23:38,701 - (MainThread) - OK
2018-03-17 01:23:38,701 - (MainThread) - Done
2018-03-17 01:23:38,701 - (Canary) - check 10

I found that os.fdopen issue does not affect RHEL/CentOS 7, because they
use python 2.7.5, and the issue was introduced in python 2.7.7, in:

commit 5c863bf93809cefeb4469512eadac291b7046051
Author: Benjamin Peterson <benjamin at python.org>
Date:   Mon Apr 14 19:45:46 2014 -0400

    when an exception is raised in fdopen, never close the fd (changing on my mind on #21191)

This issue affects Fedora (python 2.7.14) and probably other distros using
latest python 2.7.

Here is example run show how this affects Fedora 27:

# python fdopen_nfs_test.py mnt dumbo.tlv.redhat.com
2018-03-17 01:43:52,718 - (MainThread) - Starting canary thread
2018-03-17 01:43:52,718 - (Canary) - Blocking access to storage
2018-03-17 01:43:52,823 - (Canary) - If this test is hang, please run: iptables -D OUTPUT -p tcp -d dumbo.tlv.redhat.com --dport 2049 -j DROP
2018-03-17 01:43:52,824 - (Canary) - check 0
2018-03-17 01:43:53,824 - (Canary) - check 1
2018-03-17 01:43:54,824 - (Canary) - check 2
2018-03-17 01:43:55,825 - (Canary) - check 3
2018-03-17 01:43:56,825 - (Canary) - check 4
2018-03-17 01:43:57,825 - (Canary) - check 5
2018-03-17 01:43:58,826 - (Canary) - check 6
2018-03-17 01:43:59,826 - (Canary) - check 7
2018-03-17 01:44:00,826 - (Canary) - check 8
2018-03-17 01:44:01,827 - (Canary) - check 9
2018-03-17 01:44:02,827 - (Canary) - check 10
2018-03-17 01:44:02,834 - (MainThread) - Calling os.fdopen

(remove iptbales rule, and force-unmount here) 

2018-03-17 01:50:25,853 - (MainThread) - OK
2018-03-17 01:50:25,854 - (Canary) - check 11
2018-03-17 01:50:25,895 - (MainThread) - Done
Traceback (most recent call last):
  File "fdopen_nfs_test.py", line 75, in <module>
    os.unlink(filename)
OSError: [Errno 2] No such file or directory: 'mnt/test'


So, I think we should:
- backport to 3.7, 3.6
- reconsider backport to 2.7, at least for mmap and os.fdopen.

I can prepare the backports and split the 2.7 patch if this helps.

----------
Added file: https://bugs.python.org/file47490/mmap_nfs_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Fri Mar 16 19:58:26 2018
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 16 Mar 2018 23:58:26 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521244706.02.0.467229070634.issue33021@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Attaching reproducer for mmapobject.size()

----------
Added file: https://bugs.python.org/file47491/mmap_size_nfs_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Fri Mar 16 19:58:46 2018
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 16 Mar 2018 23:58:46 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521244726.32.0.467229070634.issue33021@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Attaching reproducer for os.fdopen()

----------
Added file: https://bugs.python.org/file47492/fdopen_nfs_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Fri Mar 16 20:27:53 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 17 Mar 2018 00:27:53 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521246473.48.0.467229070634.issue33089@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The obvious work-around of calling hypot multiple times is not only tedious, but it loses precision. For example, the body diagonal through a 1x1x1 cube should be ?3 exactly:

py> from math import hypot, sqrt
py> hypot(hypot(1, 1), 1) == sqrt(3)
False


I know of at least five languages or toolkits which support this feature, or something close to it: Javascript, Julia, Matlab, GNU Scientific Library, and C++.

Javascript and Julia support arbitrary numbers of arguments:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/hypot

https://github.com/JuliaLang/julia/pull/15649

Using Firefox's javascript console, I get the correct body diagonal for the cube:

>> Math.hypot(1, 1, 1) == Math.sqrt(3)
true


Matlab's hypot() function only takes two arguments, but norm(vector) returns the Euclidean 2-norm of the vector, i.e. equivalent to the hypot of multiple arguments.

https://au.mathworks.com/help/matlab/ref/norm.html

The GNU Scientific Library and C++ support a three-argument form of hypot:

http://git.savannah.gnu.org/cgit/gsl.git/commit/?id=e1711c84f7ba5c2b22d023dcb7e10810233fff27

http://en.cppreference.com/w/cpp/numeric/math/hypot
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0030r1.pdf


So +1 on math.hypot supporting arbitrary number of arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Fri Mar 16 20:36:38 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 17 Mar 2018 00:36:38 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521246998.03.0.467229070634.issue33089@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Ah wait, I appear to have misunderstood Raymond's request. Sorry Raymond!

(I've been spending too much time teaching Pythagoras' theorem and my mind was primed to go directly from Euclidean distance to hypotenuse.)

Not withstanding my misunderstanding, if hypot supported arbitrary number of arguments, then the implementation of distance could simply defer to hypot:

def distance(p, q):
    # TODO error checking that p and q have the same number of items
    return hypot(*(x-y for x,y in zip(p, q)))


giving results like this:

py> distance((11, 21), (14, 17))
5.0


In either case, I agree with Raymond that this would be a useful feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Fri Mar 16 21:22:01 2018
From: report at bugs.python.org (Asdger Gdsfe)
Date: Sat, 17 Mar 2018 01:22:01 +0000
Subject: [issue29270] super call in ctypes sub-class fails in 3.6
In-Reply-To: <1484345422.14.0.967631121608.issue29270@psf.upfronthosting.co.za>
Message-ID: <1521249721.58.0.467229070634.issue29270@psf.upfronthosting.co.za>


Asdger Gdsfe <doubledhelix at gmail.com> added the comment:

Hey 3.6 is pretty old now so can we get this patch merged I'd really like this code to start working again, appreciate all your hard work!

class Something(ctypes.c_ulong):
  def __repr__(self):
    return super(Something, self).value

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ set to <class '__main__.Something'> defining 'Something' as <class '__main__.Something'>

----------
nosy: +Asdger Gdsfe

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29270>
_______________________________________

From report at bugs.python.org  Sat Mar 17 00:46:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Mar 2018 04:46:01 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
In-Reply-To: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>
Message-ID: <1521261961.52.0.467229070634.issue33047@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Running on MacOs, I can't reproduce the failure.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33047>
_______________________________________

From report at bugs.python.org  Sat Mar 17 01:41:29 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Mar 2018 05:41:29 +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: <1521265289.53.0.467229070634.issue32374@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset c2b0b12d1a137ada1023ab7c10b8d9a0249d95f9 by Nick Coghlan (Marcel Plch) in branch 'master':
bpo-32374:  m_traverse may be called with m_state=NULL (GH-5140)
https://github.com/python/cpython/commit/c2b0b12d1a137ada1023ab7c10b8d9a0249d95f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Sat Mar 17 01:41:48 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 17 Mar 2018 05:41:48 +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: <1521265308.74.0.467229070634.issue32374@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5890

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Sat Mar 17 01:42:30 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 17 Mar 2018 05:42:30 +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: <1521265350.79.0.467229070634.issue32374@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5891

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Sat Mar 17 02:02:06 2018
From: report at bugs.python.org (pmpp)
Date: Sat, 17 Mar 2018 06:02:06 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
In-Reply-To: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>
Message-ID: <1521266526.51.0.467229070634.issue33047@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/issue33047>
_______________________________________

From report at bugs.python.org  Sat Mar 17 02:03:58 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 17 Mar 2018 06:03:58 +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: <1521266638.78.0.467229070634.issue32374@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 136905fffd5f77395f80e3409630c11756b5469c by Miss Islington (bot) in branch '3.7':
bpo-32374:  m_traverse may be called with m_state=NULL (GH-5140)
https://github.com/python/cpython/commit/136905fffd5f77395f80e3409630c11756b5469c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Sat Mar 17 02:29:32 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 17 Mar 2018 06:29:32 +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: <1521268172.37.0.467229070634.issue32374@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1da0479f687613a43620430616f4db87e2ed4423 by Miss Islington (bot) in branch '3.6':
bpo-32374:  m_traverse may be called with m_state=NULL (GH-5140)
https://github.com/python/cpython/commit/1da0479f687613a43620430616f4db87e2ed4423


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Sat Mar 17 05:28:50 2018
From: report at bugs.python.org (Yonatan Zunger)
Date: Sat, 17 Mar 2018 09:28:50 +0000
Subject: [issue32421] Keeping an exception in cache can segfault the
 interpreter
In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za>
Message-ID: <1521278930.47.0.467229070634.issue32421@psf.upfronthosting.co.za>


Yonatan Zunger <zunger at gmail.com> added the comment:

Apologies -- I've been completely swamped and haven't had time to build a repro case. I don't think I have enough state on the way I found this to reconstruct it easily right now, so I'll close it and re-open if I find it again.

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32421>
_______________________________________

From report at bugs.python.org  Sat Mar 17 05:46:20 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Mar 2018 09:46:20 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521279980.51.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

FYI, I will have some time to debug the test failure this weekend. If I (or Lele or someone else) can't find the problem by Monday, I'm going to revert the patch from 3.7 branch (and probably from master too)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 17 05:53:56 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Mar 2018 09:53:56 +0000
Subject: [issue33086] pip: IndexError
In-Reply-To: <1521219488.5.0.467229070634.issue33086@psf.upfronthosting.co.za>
Message-ID: <1521280436.65.0.467229070634.issue33086@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The OP has also asked this on Stack Overflow: https://stackoverflow.com/questions/49329079/distutils-indexerror-tuple-index-out-of-range

The problem was that they were passing a tuple to the url field.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33086>
_______________________________________

From report at bugs.python.org  Sat Mar 17 06:38:52 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Mar 2018 10:38:52 +0000
Subject: [issue33091] ssl.SSLError: Invalid error code (_ssl.c:2217)
In-Reply-To: <1521235321.12.0.467229070634.issue33091@psf.upfronthosting.co.za>
Message-ID: <1521283132.46.0.467229070634.issue33091@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Steve, this sounds like a duplicate of #32533.

----------
assignee: christian.heimes -> steve.dower
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33091>
_______________________________________

From report at bugs.python.org  Sat Mar 17 07:24:33 2018
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 17 Mar 2018 11:24:33 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521285873.64.0.467229070634.issue27645@psf.upfronthosting.co.za>


Change by Aviv Palivoda <palaviv at gmail.com>:


----------
pull_requests: +5892

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 17 07:27:25 2018
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 17 Mar 2018 11:27:25 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521286045.11.0.467229070634.issue27645@psf.upfronthosting.co.za>


Aviv Palivoda <palaviv at gmail.com> added the comment:

The problem is that change https://www.sqlite.org/src/info/169b5505498c0a7e was part of sqlite version 3.8.8
I opened a PR with a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 17 07:43:33 2018
From: report at bugs.python.org (Lele Gaifax)
Date: Sat, 17 Mar 2018 11:43:33 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521287013.48.0.467229070634.issue27645@psf.upfronthosting.co.za>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

Thank you Berker&Aviv, I'm sorry I could not find the time to investigate the problem by myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:18:45 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sat, 17 Mar 2018 12:18:45 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521289125.17.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

One more question I would raise based upon a point made earlier by Eric is if option C would be too large of a change for 3.8?  Any thoughts on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:23:31 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 17 Mar 2018 12:23:31 +0000
Subject: [issue32911] Doc strings no longer stored in body of AST
In-Reply-To: <1519302007.93.0.467229070634.issue32911@psf.upfronthosting.co.za>
Message-ID: <1521289411.45.0.467229070634.issue32911@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

I still think that option 2 would be best, but given that it is late in the release cycle, I will accept the status quo.

A couple of comments for the record:

Constant folding occurs after AST creation, so doesn't make the AST worse.

The parse tree created by lib2to3 is a concrete parse tree, not an AST. However, it might would sense (as ?ukasz suggests) to use it as a basis for an AST designed for tooling and leave the AST generated by the C parser for bytecode generation.


Happy to close this issue now, unless anyone else has something to add.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32911>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:25:15 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 17 Mar 2018 12:25:15 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521289515.13.0.467229070634.issue33034@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

For backward comparability, option C would have to default to not raising an exception. Which would limit it's usefulness, but that's the way it goes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:32:17 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sat, 17 Mar 2018 12:32:17 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521289937.27.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

This is a very good point, Eric.  For backwards compatibility we would have to set the default parameter to false, so we be in the same state we are today by default.  Knowing this my vote would be to go with the improvements to the ValueError message when using .port as the current PR does now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:33:10 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 17 Mar 2018 12:33:10 +0000
Subject: [issue33092] The bytecode for f-string formatting is inefficient.
Message-ID: <1521289990.47.0.467229070634.issue33092@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

f-string expressions can be formatted in four ways:
   with or without a conversion
   and
   with or without a format specifier

Rather than have one bytecode that parses the opcode argument at runtime it would be more efficient and produce a cleaner interpreter for the compiler to produce one or two bytecode as required.
The bytecodes should be:
  CONVERT_VALUE convert_fn
  FORMAT_SIMPLE
  FORMAT_WITH_SPEC

For simple format expressions with no conversion or format specifier,
which make up about 3/4 of all format expressions in the standard library, just the bytecode FORMAT_SIMPLE need be executed.

----------
components: Interpreter Core
messages: 314000
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: The bytecode for f-string formatting is inefficient.
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33092>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:40:08 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 17 Mar 2018 12:40:08 +0000
Subject: [issue33092] The bytecode for f-string formatting is inefficient.
In-Reply-To: <1521289990.47.0.467229070634.issue33092@psf.upfronthosting.co.za>
Message-ID: <1521290408.48.0.467229070634.issue33092@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Would this change really have a performance impact? Not saying it wouldn't, but if we're going to add bytecodes we should know the answer in advance.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33092>
_______________________________________

From report at bugs.python.org  Sat Mar 17 08:45:29 2018
From: report at bugs.python.org (Jonathan)
Date: Sat, 17 Mar 2018 12:45:29 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521290729.06.0.467229070634.issue33034@psf.upfronthosting.co.za>


Jonathan <bugreports at lightpear.com> added the comment:

Thanks for the thoughts.
If only the exception message changes, that doesn't really address the issue that caused me to raise this - namely that it seems to be inconsistent with how almost every other Python builtin function I've used works. I have to defer to you folks who know how feasible changing any of that is - I can see your reasoning.

One quick observation - on glancing over the patch, it seems to only be for urlparse, but this happens to urlsplit too. Or does urlsplit import from that function (as I said, I only glanced).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sat Mar 17 09:00:56 2018
From: report at bugs.python.org (Adrien)
Date: Sat, 17 Mar 2018 13:00:56 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
In-Reply-To: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>
Message-ID: <1521291656.89.0.467229070634.issue33047@psf.upfronthosting.co.za>


Adrien <delgan.py at gmail.com> added the comment:

Thanks for your attention to this issue.

I am not surprised that you was not able to reproduce it as it seems deeply related to multiprocessing and threads. 

I tested it on 3 others completely different computers, and I was able to reproduce the error for 2 of them which were running Ubuntu 16.04 and  Windows 10. I made a totally fresh install of Python 3.6.4, the Windows machine never had Python installed before. 
The only common point between computers where the error occurs compared to the third one, whether running Windows or Linux, is that they have a fairly old or weak hardware, and therefore are slower.

Fortunately, the error was systematic on my machine. So I was able to study the trace.py code to try to isolate the problem. Piece by piece, I simplified trace.py to get a small snippet that reproduces the bug (I joined the file to this message).
Sometimes, there is also a "BrokenPipeError" which pop-out. I do not know if this is related.

The error seems to come from the fact that "counts" start to be iterated while compiled code execution is not fully terminated, and so "localtrace_count" may add another item to the dict. Move the "time.sleep()" before the loop and the error should gone. This is most likely related to the internal thread used by Queue as using a SimpleQueue doesn't raise an exception.

As I do not have access for now to a computer where the error does not occur, I can not continue my investigations. However I hope that I give a little more information so that you maybe succeed to reproduce it.

----------
Added file: https://bugs.python.org/file47493/minitrace.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33047>
_______________________________________

From report at bugs.python.org  Sat Mar 17 09:02:10 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 17 Mar 2018 13:02:10 +0000
Subject: [issue33092] The bytecode for f-string formatting is inefficient.
In-Reply-To: <1521289990.47.0.467229070634.issue33092@psf.upfronthosting.co.za>
Message-ID: <1521291730.58.0.467229070634.issue33092@psf.upfronthosting.co.za>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +5893
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33092>
_______________________________________

From report at bugs.python.org  Sat Mar 17 09:05:29 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 17 Mar 2018 13:05:29 +0000
Subject: [issue33092] The bytecode for f-string formatting is inefficient.
In-Reply-To: <1521289990.47.0.467229070634.issue33092@psf.upfronthosting.co.za>
Message-ID: <1521291929.95.0.467229070634.issue33092@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Even if doesn't speed things up by a significant amount, I would suggest that a simper interpreter with smaller, simpler bytecodes is a worthy goal in itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33092>
_______________________________________

From report at bugs.python.org  Sat Mar 17 09:13:12 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sat, 17 Mar 2018 13:13:12 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521292392.9.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Yes, my goal for the patch was to provide a more explicit error message for this situation and to provide a low surface area change to the overall source, knowing that there are future development goals and backward compatibility to keep in mind.  That way the patch would be a first step in providing more explicit information when a developer would run into this situation and hopefully improving the current situation at hand.

The new ValueError message raised in this patch does work for both urlparse and urlsplit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Sat Mar 17 10:41:01 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Mar 2018 14:41:01 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521297661.95.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This shouldn't affect the public ABI, so I don't think it's a blocker for the ABI freeze, but it's a regression that effectively makes PySys_AddWarnOption (and related APIs) unusable, so we should definitely fix it before shipping 3.7.

For now, I've marked the bug as critical, and I'll be aiming to have it fixed before 3.7.0b3 at the end of the month.

For PySys_AddWarnOption and PySys_ResetWarnOptions, my current plan is to adjust them to maintain a singly-linked list of "wchar *" pointers when called prior to _Py_InitializeCore (i.e. when "PyThreadState_GET() == NULL"), while using the existing 3.7.0b2 path when the thread state is available. _Py_InitializeCore will then take care of cleaning up the memory allocations while converting them to Python unicode entries in a Python list object.

_PySys_AddXOption would work similarly (just with a separate list).

For PySys_AddWarnOptionUnicode, I think we need to make it call Py_FatalError for 3.7 when called prior to Py_Initialize, with a recommendation to use PySys_AddWarnOption instead. In 3.8, that API will become useful again, once the public Py_InitializeCore API provides a supported multi-stage startup process that allows unicode objects to be created safely before Py_InitializeMainInterpreter (or whatever we end up calling that API) reads sys.warnoptions and configures the warning subsystem accordingly.

----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sat Mar 17 11:17:38 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sat, 17 Mar 2018 15:17:38 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521299858.96.0.467229070634.issue33069@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I've fixed this in setuptools ( PR here: https://github.com/pypa/setuptools/pull/1294 ).

Should we leave this open to track distutils upgrading to support all of PEP 345, or close this with "distutils will never support > 1.1".  If the latter, maybe that should be explicitly documented somewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Sat Mar 17 13:36:10 2018
From: report at bugs.python.org (Eric Toombs)
Date: Sat, 17 Mar 2018 17:36:10 +0000
Subject: [issue33093] Fatal error on SSL transport
Message-ID: <1521308170.69.0.467229070634.issue33093@psf.upfronthosting.co.za>


New submission from Eric Toombs <ewtoombs at gmail.com>:

I'm not exactly sure what caused this error, but I was a client receiving messages on a websocket for a while (about 12 hours). Suddenly all incoming data stopped, then nothing happened for about 5 hours. Finally, I received a ConnectionClosed and the following appeared on stdout:

```
Fatal error on SSL transport
protocol: <asyncio.sslproto.SSLProtocol object at 0x7f17ae393e48>
transport: <_SelectorSocketTransport closing fd=15 read=idle write=<idle, bufsize=0>>
Traceback (most recent call last):
  File "/usr/lib/python3.6/asyncio/sslproto.py", line 636, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
AttributeError: 'NoneType' object has no attribute 'feed_appdata'
```

I can't imagine this is what was supposed to happen. This has happened about three times now, so I can confirm it is reproducible. I'm writing a minimalist client now to see if I can isolate the problem any further. It's still unclear, though, which layer is responsible---websockets or asyncio. The websockets issue is here:

https://github.com/aaugustin/websockets/issues/356

----------
components: asyncio
messages: 314008
nosy: Eric Toombs, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Fatal error on SSL transport
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33093>
_______________________________________

From report at bugs.python.org  Sat Mar 17 14:07:58 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Mar 2018 18:07:58 +0000
Subject: [issue32829] Lib/ be more pythonic
In-Reply-To: <1518437200.03.0.467229070634.issue32829@psf.upfronthosting.co.za>
Message-ID: <1521310078.56.0.467229070634.issue32829@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The risk of introducing a bug is higher than the minimal benefit of making the changes.  Thus we do not typically accept changes like this.  We'll clean up such code when we touching it for other reasons.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32829>
_______________________________________

From report at bugs.python.org  Sat Mar 17 14:28:51 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Mar 2018 18:28:51 +0000
Subject: [issue33047] "RuntimeError: dictionary changed size during iteration"
 using trace.py module
In-Reply-To: <1520788799.16.0.467229070634.issue33047@psf.upfronthosting.co.za>
Message-ID: <1521311331.42.0.467229070634.issue33047@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for the improved example.  From Command Prompt, I now see
f:\dev\37>python -m trace -c f:/python/a/tem2.py
Running Debug|Win32 interpreter...
Traceback (most recent call last):
  File "f:\dev\37\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "f:\dev\37\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "f:\dev\37\lib\trace.py", line 737, in <module>
    main()
  File "f:\dev\37\lib\trace.py", line 725, in main
    t.runctx(code, globs, globs)
  File "f:\dev\37\lib\trace.py", line 463, in runctx
    exec(cmd, globals, locals)
  File "f:/python/a/tem2.py", line 31, in <module>
    main()
  File "f:/python/a/tem2.py", line 24, in main
    for filename, lineno in counts:
RuntimeError: dictionary changed size during iteration

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33047>
_______________________________________

From report at bugs.python.org  Sat Mar 17 14:39:35 2018
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Mar 2018 18:39:35 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1521311975.79.0.467229070634.issue32958@psf.upfronthosting.co.za>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32958>
_______________________________________

From report at bugs.python.org  Sat Mar 17 15:13:28 2018
From: report at bugs.python.org (Simon Charette)
Date: Sat, 17 Mar 2018 19:13:28 +0000
Subject: [issue3692] improper scope in list comprehension,
 when used in class declaration
In-Reply-To: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
Message-ID: <1521314008.24.0.467229070634.issue3692@psf.upfronthosting.co.za>


Simon Charette <charette.s at gmail.com> added the comment:

I stumble upon this bug when porting a Python 2 codebase to 3 and suddenly got a NameError for the following code.


    class Foo:
        a = [1,2,3]
        b = [4,5,6]
        c = [x * y for x in a for y in b]

    NameError: name 'b' is not defined

Not sure what could be done at this point but I thought I'd leave some feedback given I was surprised this would break given it works just fine if not defined at the class level.

    a = [1,2,3]
    b = [4,5,6]
    c = [x * y for x in a for y in b]

----------
nosy: +charettes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3692>
_______________________________________

From report at bugs.python.org  Sat Mar 17 15:44:39 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 17 Mar 2018 19:44:39 +0000
Subject: [issue33057] logging.Manager.logRecordFactory is never used
In-Reply-To: <1520871485.85.0.467229070634.issue33057@psf.upfronthosting.co.za>
Message-ID: <1521315879.19.0.467229070634.issue33057@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> However, it seems that someone already thought about it before and started implementing this mechanism

That someone was me. I decided that a single module-level factory was good enough but failed to delete the things you noticed.

>From what you've said, it looks more and more like an XY problem and I would guess that your requirement can be solved by either using a custom message object or some other method already supported by existing mechanisms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33057>
_______________________________________

From report at bugs.python.org  Sat Mar 17 17:05:45 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 17 Mar 2018 21:05:45 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1521320745.91.0.467229070634.issue32949@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

We have two competing PRs for this issue. Again.

For comparison, using the same micro-benchmark, PR 5112 has these timings:
Master branch: Mean +- std dev: 252 ns +- 4 ns
PR 5112: Mean +- std dev: 216 ns +- 4 ns

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Sat Mar 17 17:19:47 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Sat, 17 Mar 2018 21:19:47 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521321587.18.0.467229070634.issue33081@psf.upfronthosting.co.za>


Henrique Andrade <hcma at unscrambl.com> added the comment:

Here is the repro (I am running this on Ubuntu 16 with the stock Python 
 version 2.7.12):

========================================================================================

#!/usr/bin/env python      
                
import os              
import subprocess                               
import sys                                        
                                                
from multiprocessing import Process, Queue      
from multiprocessing.queues import _sentinel                
                                                            
                                                            
def run_external_application(application_name, queue):      
    """Runs an Oxygen application"""                                     
    exit_status = 10            
    queue.put(exit_status)                         
    # none of the following help as far as making the pipe go away       
    queue.put(_sentinel)                                 
    queue.close()                                             
                                                              
                                                            
def run(application_name="external_application"):                                                       
    print "Starting '%s'" % application_name                                                            
                                                                                                              
    queue = Queue()                                                                                   
    application_process = Process(target=run_external_application, args=(application_name, queue))      
                                                                                                      
    application_process.start()         
                                             
    try:                                     
        application_process.join()         
    except KeyboardInterrupt:              
        application_process.terminate()      
                                           
    exit_status = queue.get()                                                                                    
    print "exit status", exit_status                                                                             
                                                                                                               
    queue.close()                                                                                         
    # the deletion below has no effect                                                                      
    del queue                                                                                               
    # the only thing that will make the pipe go away is to uncomment the below statement                      
    # queue._writer.close()                                                                                 
                                                                                                            
    print "\nthe '%s' application finished with exit status '%s'...\n" % (application_name, exit_status)      
     
    print "Note the file descriptor #4 below"     
    subprocess.call(["ls", "-la", "/proc/%d/fd" % os.getpid()])      
                                        
    return exit_status                  
                                                                                                                       
                                                                                                                       
if __name__ == "__main__":                                                                                             
    print "starting ", os.getpid()                                                                                     
    exit_status = run()                                                                                                
    sys.exit(exit_status)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sat Mar 17 17:29:49 2018
From: report at bugs.python.org (Martin Panter)
Date: Sat, 17 Mar 2018 21:29:49 +0000
Subject: [issue27069] webbrowser creates zombi processes in the background mode
In-Reply-To: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>
Message-ID: <1521322189.31.0.467229070634.issue27069@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

It does look similar. They probably could be merged. The main difference is in Issue 5993 Eivind suggested to somehow use a ?wait? system call, while here Victor suggested ?fork? (perhaps to orphan a grandchild process?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27069>
_______________________________________

From report at bugs.python.org  Sat Mar 17 17:34:41 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2018 21:34:41 +0000
Subject: [issue21018] [patch] added missing documentation about escaping
 characters for configparser
In-Reply-To: <1395464420.76.0.68706986346.issue21018@psf.upfronthosting.co.za>
Message-ID: <1521322481.06.0.467229070634.issue21018@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +5894

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21018>
_______________________________________

From report at bugs.python.org  Sat Mar 17 17:36:07 2018
From: report at bugs.python.org (Arun Persaud)
Date: Sat, 17 Mar 2018 21:36:07 +0000
Subject: [issue21018] [patch] added missing documentation about escaping
 characters for configparser
In-Reply-To: <be2fbfe7-aaf4-8789-16fb-4524df47a200@gmail.com>
Message-ID: <eb3eb99e-b899-31fa-2a77-eb45f8662537@gmail.com>


Arun Persaud <arun.persaud at gmail.com> added the comment:

created github PR #6137. Hope everything is in the correct format.

Arun

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21018>
_______________________________________

From report at bugs.python.org  Sat Mar 17 19:03:50 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Sat, 17 Mar 2018 23:03:50 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
Message-ID: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>


New submission from Adrian Stachlewski <adrian.stachlewski at gmail.com>:

Class variables should behave in the same way whether with or without ClassVar annotation. Unfortunately there are not.

class A:
    __slots__ = ()
    x: ClassVar = set()

A()  # it's ok

@dataclass
class B:
    __slots__ = ()
    x = set()

B()  # ok too

@dataclass
class C:
    __slots__ = ()
    # cannot use set() because of error
    x: ClassVar = field(default_factory=set) 

C()  # AttributeError: 'C' object has no attribute 'x'

Exception is raised from __init__ method, with flag init=False nothing changes. 

Python version: 3.7.0b2

----------
components: Library (Lib)
messages: 314017
nosy: stachel
priority: normal
severity: normal
status: open
title: dataclasses: ClassVar attributes are not working properly
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Sat Mar 17 20:49:03 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Mar 2018 00:49:03 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521334143.27.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset bbf7bb7a636b3112ef6f6b31df385606d52517ce by Berker Peksag (Aviv Palivoda) in branch 'master':
bpo-27645: Fix version number in 'database in transaction' fallback (GH-6131)
https://github.com/python/cpython/commit/bbf7bb7a636b3112ef6f6b31df385606d52517ce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 17 20:49:26 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 00:49:26 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521334166.19.0.467229070634.issue27645@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5895

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sat Mar 17 23:32:22 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Mar 2018 03:32:22 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1521343942.35.0.467229070634.issue33014@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the original report that this issue was opened for:

   Use keyword.iskeyword() to test for reserved identifiers such as "def" and "class".

The obvious replacement is:

   Use the iskeyword() function from the keyword module to test for reserved identifiers such as "def" and "class".

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Sun Mar 18 00:27:46 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Mar 2018 04:27:46 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521347266.92.0.467229070634.issue33094@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Sun Mar 18 01:31:20 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 05:31:20 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521351080.92.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This isn't considered a security issue, as running "python3" interactively behaves in exactly the same way (i.e. tracking changes to the current working directory for the duration of the session), and running "python3 script.py" adds the full path to the current directory.

In all cases, the expectation is that end users will at least enable isolated mode if they don't want to risk importing arbitrary code from user controlled directories.

    $ echo "print('Hello')" > foo.py
    $ python3 -m foo
    Hello
    $ python3 -Im foo
    /usr/bin/python3: No module named foo

However, I'm flagging this as an enhancement request for 3.8+ (with a reworded issue title), as the non-isolated `-m` switch algorithm for sys.path[0] calculation could be made more robust as follows:

1. Start out with "os.getcwd()" rather than the empty string
2. Once `__main__.__file__` has been calculated, delete sys.path[0] if __main__ was found somewhere else

A potentially related enhancement would be to modify directory & zipfile execution to only look for `__main__.py` in `sys.path[0]` rather than searching the whole of `sys.path` (which is what currently happens).

----------
title: Running a module with `-m` will add empty directory to sys.path -> Avoid adding an empty directory to sys.path when running a module with `-m`
type: security -> enhancement
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 01:44:11 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 05:44:11 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521351851.22.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also, a small upstream community interaction tip: if you want people to seriously consider your requests for changes in default behaviour (which inevitably risk backwards compatibility breaks), don't start out by insulting them.

Python's defaults are currently set up for a *trusted personal automation tool*, where the person writing the code is also the person running it.

By starting out with an insult like "I think this is a really stupid security bug", you're actually saying "I know very little about Python's history, or the audiences it was originally written to serve, and instead of politely suggesting an alternative behaviour that would be more robust in the face of system configuration errors, I'm going to try to use shame, guilt, and embarrassment to get people to do work for me". That kind of behaviour *isn't* a good way to get your issues addressed, but it *is* a good way to encourage people to decide that volunteering as an open source maintainer isn't worth the associated hassles.

The opening insult added nothing to your issue report, and could more productively have been replaced with an explanation of the expectations you had of the default behaviour, how you came by those expectations, and how the current behaviour failed to meet them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 01:57:16 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 05:57:16 +0000
Subject: [issue33095] Cross-reference isolated mode from relevant locations
Message-ID: <1521352636.34.0.467229070634.issue33095@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

In https://bugs.python.org/issue33053#msg313966, jwilk noted that it isn't obvious from https://docs.python.org/3/using/cmdline.html#cmdoption-m how to keep the current directory from being added to `sys.path` when using the -m switch. The answer is to pass the `-I` switch as well (to activate isolated mode), but there's no cross reference to help readers discover that fact.

https://docs.python.org/3/using/cmdline.html#id2 is the main documentation for isolated mode, so the steps needed to close this issue are:

1. At least add a reference from the -m switch documentation to the -I switch documentation
2. Review the other parts of the `using` docs that describe how `sys.path` is initialised, and reference the -I switch documentation where relevant

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 314022
nosy: docs at python, jwilk, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Cross-reference isolated mode from relevant locations
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33095>
_______________________________________

From report at bugs.python.org  Sun Mar 18 01:58:43 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 05:58:43 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521352723.89.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've also separated out https://bugs.python.org/issue33095 (a docs issue about making isolated mode more discoverable) based on the jwilk's comment that it wasn't clear how to disable the default "add the current directory to sys.path" behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 02:04:33 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 06:04:33 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521353073.06.0.467229070634.issue33021@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Regarding 2.7: if folks want this fixed on RHEL/CentOS, then they need to talk to Red Hat about it, not the upstream CPython devs. I used to work there, and was told multiple times by Red Hat executives that none of their customers actually used Python, so the Python ecosystem wasn't of any strategic interest to them, and hence zero funding was available for full-time upstream CPython maintenance econtributions.

As such, I no longer consider it acceptable for anyone to ask community volunteers to compensate for Red Hat's abject negligence and executive incompetence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Sun Mar 18 02:19:42 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 18 Mar 2018 06:19:42 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521353982.38.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Whoa, wait, what?

I agree that the original post is not as diplomatic as it could be, but my reaction to learning about this just now is also shock and confusion, so I guess I can sympathize with the OP a bit...

The reason I'm surprised is that -- while this probably wasn't fully anticipated when -m was designed -- it's turned out to be a bit of a meme to replace calls like 'pip ...' with 'python -m pip ...', or 'virtualenv ...' with 'python -m virtualenv ...', etc. I thought these were generally pretty much equivalent. I definitely did *not* know that running 'python -m pip' could lead to executing arbitrary code from the cwd, and I'm sure I've run it inside e.g. random git checkouts. If someone had tried to spearphish me with this they would totally have succeeded. (I hope they haven't?)

If you want to run a file in the current directory, is there any advantage to doing 'python -m myscript' instead of 'python myscript.py'? Could we declare that the latter is the One Obvious Way and remove support for the former entirely?

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 02:24:41 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Mar 2018 06:24:41 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521354281.84.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 429ca448d2a36040f229ad9edc67e31fc6d18bf4 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-27645: Fix version number in 'database in transaction' fallback (GH-6131)
https://github.com/python/cpython/commit/429ca448d2a36040f229ad9edc67e31fc6d18bf4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sun Mar 18 02:52:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 06:52:19 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521355939.63.0.467229070634.issue33069@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm going to abuse the "third party" resolution type a bit and mark this as closed (at least for now) on the basis of "use setuptools instead if you want the improved behaviour".

I've also opened https://github.com/pypa/packaging-problems/issues/127 to discuss coming up with a migration plan whereby *setuptools* eventually becomes the reference implementation of the distutils API, and we remove the CPython level implementation entirely.

----------
resolution:  -> third party
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Sun Mar 18 03:04:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 07:04:27 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521356667.61.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

"python -m mypkg.myscript" does the right thing as far as local packages are concerned, whereas "python -m mypkg/myscript.py" will set you up for double-import bugs.

Note that you can almost always trigger arbitrary non-obvious code execution just by writing sitecustomize.py to the current directory, and any package you install can add a "<installation-site-packages>/arbitrary-code.pth" or "<user-site-packages>/arbitrary-code.pth" file that gets run at startup (setuptools has long relied on this to implement various features).

Opting in to isolated mode turns *all* of those features off by saying "I'm expecting to run system code only here, not custom user code".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 03:53:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 07:53:17 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521359597.31.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bc300ce205f99acb1ef92c37de06dc76147e073b by Serhiy Storchaka in branch 'master':
bpo-33041: Add tests for jumps in/out of 'async with' blocks. (#6110)
https://github.com/python/cpython/commit/bc300ce205f99acb1ef92c37de06dc76147e073b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 03:55:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 07:55:56 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1521359756.05.0.467229070634.issue32056@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 134cb01cda50f02725575808130b05d2d776693f by Serhiy Storchaka in branch 'master':
bpo-32056: Improve exceptions in aifc, wave and sunau. (GH-5951)
https://github.com/python/cpython/commit/134cb01cda50f02725575808130b05d2d776693f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32056>
_______________________________________

From report at bugs.python.org  Sun Mar 18 03:56:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 07:56:55 +0000
Subject: [issue32489] Allow 'continue' in 'finally' clause
In-Reply-To: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>
Message-ID: <1521359815.17.0.467229070634.issue32489@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fe2bbb1869b42222a3f331a3dfb8b304a19a5819 by Serhiy Storchaka in branch 'master':
bpo-32489: Allow 'continue' in 'finally' clause. (GH-5822)
https://github.com/python/cpython/commit/fe2bbb1869b42222a3f331a3dfb8b304a19a5819


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32489>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:01:20 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 09:01:20 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1521363680.24.0.467229070634.issue32056@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32056>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:09:10 2018
From: report at bugs.python.org (Igor Yakovchenko)
Date: Sun, 18 Mar 2018 09:09:10 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
Message-ID: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>


New submission from Igor Yakovchenko <truestarecat at gmail.com>:

ttk.Treeview.insert(... iid=None, ...) method has a check:
        if iid:
            res = self.tk.call(self._w, "insert", parent, index,
                "-id", iid, *opts)
        else:
            res = self.tk.call(self._w, "insert", parent, index, *opts)

Documentation says that "If iid is specified, it is used as the item identifier", but as you can see from code, iid is used only if it's "True". It means that you cannot use iids like 0, 0.0 etc.

----------
components: Tkinter
messages: 314032
nosy: gpolo, serhiy.storchaka, truestarecat
priority: normal
severity: normal
status: open
title: ttk.Treeview.insert() does not allow to insert item with "False" iid
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:16:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 09:16:54 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1521364614.78.0.467229070634.issue32056@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Now open() in modules aifc, sunau and wave will raise only EOFError (if the file was truncated) or corresponding module error exception on corrupted files. aifc.open() can raise also OverflowError, but this is a different issue32978. And of course OSError, MemoryError, RecursionError and KeyboardInterrupt can be raised for causes not related to the correctness of the file.

I withdraw the part of my claim in msg313084. I have tested -- backporting this is safe, because some error always was raised in open(). But it can help existing user code which was not aware about wider set of exceptions (like in the original report). It can work in common case, and handle most corrupted files well, but fail in cases of specially created malicious data. Thus I think it is worth to backport this change at least to 3.7. What are your thoughts Ned?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32056>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:19:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 09:19:26 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1521364766.62.0.467229070634.issue33096@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
versions: +Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:23:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 09:23:34 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521365014.77.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5897

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:29:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 09:29:37 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521365377.94.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5898

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 05:56:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 09:56:09 +0000
Subject: [issue32489] Allow 'continue' in 'finally' clause
In-Reply-To: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>
Message-ID: <1521366969.2.0.467229070634.issue32489@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/issue32489>
_______________________________________

From report at bugs.python.org  Sun Mar 18 06:31:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 10:31:41 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521369101.42.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 773573e9ac654d4b5c6682e70360f75864acd80e by Serhiy Storchaka in branch '3.7':
[3.7] bpo-33041: Add tests for jumps in/out of 'async with' blocks. (GH-6110). (GH-6140)
https://github.com/python/cpython/commit/773573e9ac654d4b5c6682e70360f75864acd80e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 06:32:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 10:32:34 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521369154.24.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 193760f00aacb122698674ed15327dba412653a5 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-33041: Add tests for jumps in/out of 'async with' blocks. (GH-6110). (GH-6141)
https://github.com/python/cpython/commit/193760f00aacb122698674ed15327dba412653a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 06:40:23 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 18 Mar 2018 10:40:23 +0000
Subject: [issue33095] Cross-reference isolated mode from relevant locations
In-Reply-To: <1521352636.34.0.467229070634.issue33095@psf.upfronthosting.co.za>
Message-ID: <1521369623.01.0.467229070634.issue33095@psf.upfronthosting.co.za>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy:  -jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33095>
_______________________________________

From report at bugs.python.org  Sun Mar 18 06:46:07 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 18 Mar 2018 10:46:07 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521369967.19.0.467229070634.issue33053@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

-I implies -s, which is not something I want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 08:14:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 12:14:15 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521375255.39.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5899

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 08:19:14 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 18 Mar 2018 12:19:14 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521375554.41.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

When I run your script I do not see any file descriptor associated with the queue when 

subprocess.call(["ls", "-la", "/proc/%d/fd" % os.getpid()])

is executed.

This is my output if I just execute your program:

starting  3728
Starting 'external_application'
exit status 10

the 'external_application' application finished with exit status '10'...

Note the file descriptor #4 below
total 0
dr-x------ 2 pablogsal pablogsal  0 Mar 18 12:17 .
dr-xr-xr-x 9 pablogsal pablogsal  0 Mar 18 12:17 ..
lrwx------ 1 pablogsal pablogsal 64 Mar 18 12:17 0 -> /dev/pts/1
lrwx------ 1 pablogsal pablogsal 64 Mar 18 12:17 1 -> /dev/pts/1
lrwx------ 1 pablogsal pablogsal 64 Mar 18 12:17 2 -> /dev/pts/1
lr-x------ 1 pablogsal pablogsal 64 Mar 18 12:17 5 -> /dev/urandom

This is my output if I remove the call to "del queue":

starting  3892
Starting 'external_application'
exit status 10

the 'external_application' application finished with exit status '10'...

Note the file descriptor #4 below
total 0
dr-x------ 2 pablogsal pablogsal  0 Mar 18 12:18 .
dr-xr-xr-x 9 pablogsal pablogsal  0 Mar 18 12:18 ..
lrwx------ 1 pablogsal pablogsal 64 Mar 18 12:18 0 -> /dev/pts/1
lrwx------ 1 pablogsal pablogsal 64 Mar 18 12:18 1 -> /dev/pts/1
lrwx------ 1 pablogsal pablogsal 64 Mar 18 12:18 2 -> /dev/pts/1
l-wx------ 1 pablogsal pablogsal 64 Mar 18 12:18 4 -> 'pipe:[104568]'
lr-x------ 1 pablogsal pablogsal 64 Mar 18 12:18 5 -> /dev/urandom

So at least on my side "del queue" is having the desired effect.

Notice that calling

> del queue

does not destroy the object but just decrement in 1 the number of references to the object. To force collection of any possible cycles once you have destroyed all references on your side you can call

> import gc
> gc.collect()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 08:29:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 12:29:13 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521376153.2.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 6142 fixes issues 2 and 4. It adds a new opcode END_ASYNC_FOR and therefore can't be backported. END_ASYNC_FOR combines a number of other opcodes and guaranties using the true StopAsyncIteration. The new opcode is neccessary also for detecting an "async for" loop when jump. Besides introducing the new opcode the code of an "async for" loop was changed in a way that allowed to disallow jumping into an "async for" loop (this is the only part that can be backported). The final bytecode is much simpler. The compiler has been cleaned up and its code is now much simpler too. I expect also a performance boost, but don't know how to benchmark this.

Perhaps only the half of issue 4 (disallowing jumps into an "async for" loop) can be solved in 3.7 and 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Sun Mar 18 09:15:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 13:15:49 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1521378949.46.0.467229070634.issue32949@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your PR Mark.

The main difference between PR 5883 and PR 5112 is that in PR 5883 the pair of old WITH_CLEANUP_FINISH and END_FINALLY are replaced with a single new WITH_CLEANUP_FINISH, and in PR 5112 it is replaced with a sequence of 7 opcodes including a new opcode RERAISE.

    POP_JUMP_IF_TRUE  L
    RERAISE
L:
    POP_TOP
    POP_TOP
    POP_TOP
    POP_EXCEPT
    POP_TOP

This doesn't affect a performance in normal case because this code is executed only when an exception has been raised (an in that case the performance is less important). And seems this doesn't introduce new race conditions.

The number of opcodes is the same in both PRs. The implementation of RERAISE in ceval.c in PR 5112 is a tiny bit simpler than the implementation of WITH_CLEANUP_FINISH in PR 5883. But the generated bytecode and the compiler are a tiny bit simpler in PR 5883. If RERAISE be used for other purposes besides implementing a "with" statement, it would be a great advantage.

For now both approaches look to me not having significant advantages or disadvantages against the other one. Does anybody have preferences?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Sun Mar 18 09:21:06 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 13:21:06 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521379266.23.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

https://bugs.python.org/issue13475 is the existing enhancement request to expose sys.path[0] management independently of the other execution isolation features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 18 09:28:01 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Mar 2018 13:28:01 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
 sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1521379681.04.0.467229070634.issue13475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This question recently came up again over in https://bugs.python.org/issue33053#msg314040.

With the assorted startup refactorings that were landed for 3.7, it likely makes sense to take another run at this for 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Sun Mar 18 10:31:29 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sun, 18 Mar 2018 14:31:29 +0000
Subject: [issue33093] Fatal error on SSL transport
In-Reply-To: <1521308170.69.0.467229070634.issue33093@psf.upfronthosting.co.za>
Message-ID: <1521383489.85.0.467229070634.issue33093@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Eric, what is needed to try and reproduce this issue accurately?  Would it be installing websockets and setting up your client to ping to the server forever (12 hours in this case)?  If you are able to provide a client I would be willing to setup a test case on my end.

----------
nosy: +agnosticdev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33093>
_______________________________________

From report at bugs.python.org  Sun Mar 18 11:34:34 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Sun, 18 Mar 2018 15:34:34 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521387274.48.0.467229070634.issue33081@psf.upfronthosting.co.za>


Henrique Andrade <hcma at unscrambl.com> added the comment:

@pablo: I am using Python 2.7.12 (distributed with Ubuntu 16), what are you using? This might explain the difference between what we see.

Yet, irrespective of this difference, imho, it would be a better design to have "close" actually closing the underlying resources.

In general, if one has to delete and/or invoke the garbage collector on an object, it's an indication that the design needs a bit of polish. Just picture the small scenario I described amplified to a situation where a large number of queues is used, which is perhaps an artificial scenario, but one would end up with a bunch of file descriptors hanging around for no reason.

This is what files and sockets, for example, would do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:35:13 2018
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 18 Mar 2018 16:35:13 +0000
Subject: [issue30406] async and await should be keywords in 3.7
In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za>
Message-ID: <1521390913.31.0.467229070634.issue30406@psf.upfronthosting.co.za>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
pull_requests: +5900

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30406>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:41:13 2018
From: report at bugs.python.org (Mark Nemec)
Date: Sun, 18 Mar 2018 16:41:13 +0000
Subject: [issue33097] concurrent.futures executors accept tasks after
 interpreter shutdown
Message-ID: <1521391273.18.0.467229070634.issue33097@psf.upfronthosting.co.za>


New submission from Mark Nemec <mark.nemec at gmail.com>:

Currently, one can submit a task to an executor (both ThreadPoolExecutor and ProcessPoolExecutor) during interpreter shutdown. One way to do this is to register function fun with atexit as below.

@atexit.register
def fun():
   pool.submit(print, "apple")

The future is accepted and goes into PENDING state. However, this can cause issues if the _python_exit function (located in concurrent/futures/thread.py and/or concurrent/futures/process.py) executes before function fun.

Function _python_exit will shutdown the running workers in the pool and hence there will be no workers running by the time fun is executed so the future will be left in PENDING state forever.

The solution submitted here is to instead raise a RuntimeException when a task is submitted during interpreter shutdown. This is the same behaviour as when the shutdown method of an executor is called explicitly.

----------
components: Library (Lib)
messages: 314044
nosy: Mark Nemec
priority: normal
severity: normal
status: open
title: concurrent.futures executors accept tasks after interpreter shutdown
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33097>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:42:03 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Mar 2018 16:42:03 +0000
Subject: [issue33097] concurrent.futures executors accept tasks after
 interpreter shutdown
In-Reply-To: <1521391273.18.0.467229070634.issue33097@psf.upfronthosting.co.za>
Message-ID: <1521391323.63.0.467229070634.issue33097@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5901
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33097>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:46:23 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 18 Mar 2018 16:46:23 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521391583.97.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Notice that the documentation for close says:

> Indicate that no more data will be put on this queue by the current process. The background thread will quit once it has flushed all buffered data to the pipe. This is called automatically when the queue is garbage collected.

The method does not promise to close any pipe, just "Indicate that no more data will be put on this queue by the current process". Closing prematurely the writer side could lead to issues. I still do not understand why you would want to close the pipes but maintain the queue alive.

I could be missing something, so let's see if other people think differently about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:54:36 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 18 Mar 2018 16:54:36 +0000
Subject: [issue30406] async and await should be keywords in 3.7
In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za>
Message-ID: <1521392076.36.0.467229070634.issue30406@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset f64aae46da292f71f6be750026cd052362e066bc by ?ukasz Langa (Jelle Zijlstra) in branch 'master':
Revert "bpo-30406: Make async and await proper keywords (#1669)" (GH-6143)
https://github.com/python/cpython/commit/f64aae46da292f71f6be750026cd052362e066bc


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30406>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:54:47 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 16:54:47 +0000
Subject: [issue30406] async and await should be keywords in 3.7
In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za>
Message-ID: <1521392087.88.0.467229070634.issue30406@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5903

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30406>
_______________________________________

From report at bugs.python.org  Sun Mar 18 12:55:48 2018
From: report at bugs.python.org (Mark Nemec)
Date: Sun, 18 Mar 2018 16:55:48 +0000
Subject: [issue33097] concurrent futures Executors accept tasks after
 interpreter shutdown
In-Reply-To: <1521391273.18.0.467229070634.issue33097@psf.upfronthosting.co.za>
Message-ID: <1521392148.17.0.467229070634.issue33097@psf.upfronthosting.co.za>


Change by Mark Nemec <mark.nemec at gmail.com>:


----------
title: concurrent.futures executors accept tasks after interpreter shutdown -> concurrent futures Executors accept tasks after interpreter shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33097>
_______________________________________

From report at bugs.python.org  Sun Mar 18 13:04:53 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Sun, 18 Mar 2018 17:04:53 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521391583.97.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <CALAFW=A16e8E2t0tGmD+6HMFLy9v5MhCefXobPwwWiREUpR-2g@mail.gmail.com>


Henrique Andrade <hcma at unscrambl.com> added the comment:

I don't want to "close the pipes but maintain the queue alive" - I want to
terminate the queue and make sure that no resources are leaked. It's that
simple.

When one closes a file or a socket, there is no underlying OS resource
being held. That's what I would like to have here too.

Apparently the design does not support that and, if that's the case, it's
fine, it's just that it goes against most of the norm afaict.

On Sun, Mar 18, 2018 at 12:46 PM, Pablo Galindo Salgado <
report at bugs.python.org> wrote:

>
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> Notice that the documentation for close says:
>
> > Indicate that no more data will be put on this queue by the current
> process. The background thread will quit once it has flushed all buffered
> data to the pipe. This is called automatically when the queue is garbage
> collected.
>
> The method does not promise to close any pipe, just "Indicate that no more
> data will be put on this queue by the current process". Closing prematurely
> the writer side could lead to issues. I still do not understand why you
> would want to close the pipes but maintain the queue alive.
>
> I could be missing something, so let's see if other people think
> differently about this.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33081>
> _______________________________________
>

-- 

Henrique Andrade | +1-530-426-2123 | hcma at unscrambl.com |
https://unscrambl.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 13:12:15 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 18 Mar 2018 17:12:15 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521393135.74.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>"I want to terminate the queue and make sure that no resources are leaked.

Then you don't need to do anything special, those will be cleared on object destruction. This is not an unusual pattern even in other languages. For example, RAII in C++ is one of the most used patterns for acquiring resources and that works cleaning those resources on object destruction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 13:22:06 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Sun, 18 Mar 2018 17:22:06 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521393135.74.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <CALAFW=BcgRmh_Np5UZr-vDOCebyN1ho0V80N-ypN_1-X1wF4sw@mail.gmail.com>


Henrique Andrade <hcma at unscrambl.com> added the comment:

Your comparison is not correct.

RAII in C++ ensures that, on object destruction, resources that have been
acquired will be closed and deallocated.

The closest analogy in Python is the use of a context manager, which, btw,
a Queue does not provide.

Indeed, such a design (with a context manager) would have been cleaner
because, on exit, both pipes would have been closed and file descriptors
would not hang around.

And, yes, that is what I'd prefer too - but one can't have everything. :)

With the current design, which is more akin to Java, one is exposed to the
vagaries of the garbage collector. Note that, even in Java,
try-with-resources and the auto-closeable interface would also take care of
this. In fact, most the Java classes that require external resources have
migrated to this model.

For these reasons, I think the design could be substantially improved
(i.e., with a context manager or with the provision of a method that really
terminates the queue, so resources are properly closed immediately).

On Sun, Mar 18, 2018 at 1:12 PM, Pablo Galindo Salgado <
report at bugs.python.org> wrote:

>
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> >"I want to terminate the queue and make sure that no resources are leaked.
>
> Then you don't need to do anything special, those will be cleared on
> object destruction. This is not an unusual pattern even in other languages.
> For example, RAII in C++ is one of the most used patterns for acquiring
> resources and that works cleaning those resources on object destruction.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33081>
> _______________________________________
>

-- 

Henrique Andrade | +1-530-426-2123 | hcma at unscrambl.com |
https://unscrambl.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 14:01:05 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 18 Mar 2018 18:01:05 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521396065.37.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> RAII in C++ ensures that, on object destruction, resources that have been acquired will be closed and deallocated.

Which is exactly what is happening here. When the queue gets destroyed (because the reference count reaches 0 or because of the garbage collector) resources that have been acquired by the queue will be closed an deallocated. 

Sadly, I don't think I have anything different to apport to this discussion, so let's see what other people opinions are on this.

Of course, feel free to start a thread on python-dev or python-ideas on how to improve the design. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 15:15:54 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 19:15:54 +0000
Subject: [issue30406] async and await should be keywords in 3.7
In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za>
Message-ID: <1521400554.75.0.467229070634.issue30406@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a90df5085b51e8bb9de1c04c408bbef42ce6cbc3 by Miss Islington (bot) in branch '3.7':
Revert "bpo-30406: Make async and await proper keywords (GH-1669)" (GH-6143)
https://github.com/python/cpython/commit/a90df5085b51e8bb9de1c04c408bbef42ce6cbc3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30406>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:01:03 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Mar 2018 20:01:03 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1521403263.03.0.467229070634.issue27645@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Buildbots look happy, closing this one as 'fixed'. Thanks, Aviv!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:02:50 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 18 Mar 2018 20:02:50 +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: <1521403370.45.0.467229070634.issue19417@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 3fe33043ee83d19e15551094fc1e0984617ded3c by Mariatta (xdegaye) in branch 'master':
bpo-19417: Add test_bdb.py (GH-5217)
https://github.com/python/cpython/commit/3fe33043ee83d19e15551094fc1e0984617ded3c


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:03:00 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 20:03:00 +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: <1521403380.51.0.467229070634.issue19417@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5904

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:25:17 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 20:25:17 +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: <1521404717.25.0.467229070634.issue19417@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fdd8e8b4ffb68a4e8749bdc3b130fea7bbbf821e by Miss Islington (bot) in branch '3.7':
bpo-19417: Add test_bdb.py (GH-5217)
https://github.com/python/cpython/commit/fdd8e8b4ffb68a4e8749bdc3b130fea7bbbf821e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:35:56 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Mar 2018 20:35:56 +0000
Subject: [issue32958] socket module calls with long host names can fail with
 idna codec error
In-Reply-To: <1519674755.43.0.467229070634.issue32958@psf.upfronthosting.co.za>
Message-ID: <1521405356.29.0.467229070634.issue32958@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/issue32958>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:41:00 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Mar 2018 20:41:00 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1521405660.18.0.467229070634.issue32056@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I'm OK with merging this for 3.7.0b3.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32056>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:46:22 2018
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Mar 2018 20:46:22 +0000
Subject: [issue32911] Doc strings no longer stored in body of AST
In-Reply-To: <1519302007.93.0.467229070634.issue32911@psf.upfronthosting.co.za>
Message-ID: <1521405982.23.0.467229070634.issue32911@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks everyone for your inputs.  Let's go with the status quo -> closing this issue.

----------
priority: deferred blocker -> 
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32911>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:50:43 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 18 Mar 2018 20:50:43 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1521406243.58.0.467229070634.issue32056@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3c0a5a7c7ba8fbbc95dd1fe76cd7a1c0ce167371 by Miss Islington (bot) in branch '3.7':
bpo-32056: Improve exceptions in aifc, wave and sunau. (GH-5951)
https://github.com/python/cpython/commit/3c0a5a7c7ba8fbbc95dd1fe76cd7a1c0ce167371


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32056>
_______________________________________

From report at bugs.python.org  Sun Mar 18 16:52:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 20:52:01 +0000
Subject: [issue32056] Improve exceptions in aifc, sunau and wave
In-Reply-To: <1510911746.81.0.213398074469.issue32056@psf.upfronthosting.co.za>
Message-ID: <1521406321.3.0.467229070634.issue32056@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/issue32056>
_______________________________________

From report at bugs.python.org  Sun Mar 18 17:00:04 2018
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 18 Mar 2018 21:00:04 +0000
Subject: [issue29673] Some gdb macros are broken in 3.6
In-Reply-To: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za>
Message-ID: <1521406804.83.0.467229070634.issue29673@psf.upfronthosting.co.za>


Change by Skip Montanaro <skip.montanaro at gmail.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29673>
_______________________________________

From report at bugs.python.org  Sun Mar 18 17:07:29 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 18 Mar 2018 21:07:29 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1521407249.63.0.467229070634.issue32949@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

I intend to reuse RERAISE to implement the exceptional case for a finally block. Something like:

SETUP_FINALLY final
    body
    finalbody
JUMP exit
final:
     finalbody
     RERAISE
exit:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Sun Mar 18 17:16:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Mar 2018 21:16:51 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1521407811.83.0.467229070634.issue32949@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There are problems with the f_lineno setter when duplicate a finally body. The duplication works for "with" only because the cleanup code for "with" doesn't correspond any line number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Sun Mar 18 17:29:19 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 18 Mar 2018 21:29:19 +0000
Subject: [issue32953] Dataclasses: frozen should not be inherited for
 non-dataclass derived classes
In-Reply-To: <1519597431.47.0.467229070634.issue32953@psf.upfronthosting.co.za>
Message-ID: <1521408559.68.0.467229070634.issue32953@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5905
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32953>
_______________________________________

From report at bugs.python.org  Sun Mar 18 17:37:32 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 18 Mar 2018 21:37:32 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1521409052.74.0.467229070634.issue32949@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

It is fiddly to get the frame-setlineno code right for duplicated catch blocks, but it is far from impossible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Sun Mar 18 17:44:54 2018
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Mar 2018 21:44:54 +0000
Subject: [issue33017] Special set-cookie setting will bypass Cookielib
In-Reply-To: <1520392643.04.0.467229070634.issue33017@psf.upfronthosting.co.za>
Message-ID: <1521409494.64.0.467229070634.issue33017@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you explain what you think the problem is?  I don't know what your "POC" snippets are trying to demonstrate.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33017>
_______________________________________

From report at bugs.python.org  Sun Mar 18 18:00:28 2018
From: report at bugs.python.org (Aristide Grange)
Date: Sun, 18 Mar 2018 22:00:28 +0000
Subject: [issue33098] add implicit conversion for random.choice() on a dict
Message-ID: <1521410428.93.0.467229070634.issue33098@psf.upfronthosting.co.za>


New submission from Aristide Grange <aristide.grange at gmail.com>:

In Python 3, the expression:

```python
random.choice(d)
```

where `d` is a `dict`, raises this error:

```
~/anaconda3/lib/python3.6/random.py in choice(self, seq)
    256         except ValueError:
    257             raise IndexError('Cannot choose from an empty sequence') from None
--> 258         return seq[i]
    259 
    260     def shuffle(self, x, random=None):

KeyError: 2
```

Converting `d` into a list restores the Python 2's behavior:

```python
random.choice(list(d))
```

I am aware that the keys of a dict have now their own type. But IMHO the error message is rather uninformative, and above all, couldn't this conversion be made implicitely under the hood?

----------
messages: 314062
nosy: Aristide Grange
priority: normal
severity: normal
status: open
title: add implicit conversion for random.choice() on a dict
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33098>
_______________________________________

From report at bugs.python.org  Sun Mar 18 18:03:00 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 18 Mar 2018 22:03:00 +0000
Subject: [issue32867] argparse assertion failure with multiline metavars
In-Reply-To: <1518930403.05.0.467229070634.issue32867@psf.upfronthosting.co.za>
Message-ID: <1521410580.56.0.467229070634.issue32867@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

I haven't seen anyone try to use \n in a metavar before, but other special characters like [] and () produce this assertion error.  At this point the code is trying split the usage into 2 or more lines, because it's too long for one.  It creates a usage for optionals and positionals separately.

In a clumsy way, it formats the whole usage string, and tries to split it into pieces so it can decide to split long lines.  The 'assert' is used to make sure it has split the line into meaningful blocks.  It splits with

    r'\(.*?\)+|\[.*?\]+|\S+'

basically white space (including nl) and [] and () which are used to mark optional arguments and groups.  So including any of these characters in text via metavar will screwup this split.

We could try to refine this splitting expression, but that feels like a never ending task as users become more inventive.

I suggested a major rewrite of this section, one that keeps the pieces a list, and joins them after deciding how many can fit on a line.

No one has, to my knowledge, come up with a comprehensive list of characters that will cause problems here.

argparse does provide a backup - a user provided usage string.  That's not as nice as a automatically generated one, but if you have to have something special, that's the way to go.  In the long run there's only so much that general purpose parser can do to accommodate special needs.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32867>
_______________________________________

From report at bugs.python.org  Sun Mar 18 18:18:03 2018
From: report at bugs.python.org (Jay Yin)
Date: Sun, 18 Mar 2018 22:18:03 +0000
Subject: [issue33099] test_poplib hangs with the changes done in PR
Message-ID: <1521411483.84.0.467229070634.issue33099@psf.upfronthosting.co.za>


New submission from Jay Yin <jayyin11043 at gmail.com>:

my test hangs locally on my computer with the changes I've done in bpo-32642 but doesn't hang on TravisCI, anyone able to help with checking what's wrong here (sounds like another edge case with my env but I could be wrong)

the trace for the command https://pastebin.com/q4FKnPZH

----------
components: Tests
messages: 314064
nosy: jayyin11043
priority: normal
severity: normal
status: open
title: test_poplib hangs with the changes done in PR
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33099>
_______________________________________

From report at bugs.python.org  Sun Mar 18 18:18:44 2018
From: report at bugs.python.org (Jay Yin)
Date: Sun, 18 Mar 2018 22:18:44 +0000
Subject: [issue32642] add support for path-like objects in sys.path
In-Reply-To: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>
Message-ID: <1521411524.61.0.467229070634.issue32642@psf.upfronthosting.co.za>


Jay Yin <jayyin11043 at gmail.com> added the comment:

srry I opened another issue bpo-33099

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Sun Mar 18 18:55:14 2018
From: report at bugs.python.org (Henrique Andrade)
Date: Sun, 18 Mar 2018 22:55:14 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521396065.37.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <CALAFW=AJ-8StrrbMxYnHhPr+EPFcLtG33wzrmhJWT7Q4XdyjYw@mail.gmail.com>


Henrique Andrade <hcma at unscrambl.com> added the comment:

You're a missing the fact that in C++, there is no garbage collector. The
destructor both releases resources and deallocates memory.

There is no window between releasing resources and object destruction.

Python, while not exactly like Java, is similar to Java in the sense that
there is a window of time between an object no longer having a reference
and its being reaped by the garbage collector. During that window,
resources can be held even if no longer in use.

In extreme cases, a lot of these resources can be held (think hundreds of
Queues being created and closed in succession without an intervening GC
run), even if not used. Sure, at some point, they will be reaped, but it
might be a while.

And that's one of the reasons Python and Java have mechanisms to
acquire/release resources in a more timely fashion. Context managers in the
former and try-with-resources in the latter.

The mere presence of a proper close/shutdown method can make this work in
an improved way in the case of a Queue, allowing OS resources (pipes) to be
released in a more timely fashion.

But, sure, let's hear what the community thinks.

On Sun, Mar 18, 2018, 14:01 Pablo Galindo Salgado <report at bugs.python.org>
wrote:

>
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> > RAII in C++ ensures that, on object destruction, resources that have
> been acquired will be closed and deallocated.
>
> Which is exactly what is happening here. When the queue gets destroyed
> (because the reference count reaches 0 or because of the garbage collector)
> resources that have been acquired by the queue will be closed an
> deallocated.
>
> Sadly, I don't think I have anything different to apport to this
> discussion, so let's see what other people opinions are on this.
>
> Of course, feel free to start a thread on python-dev or python-ideas on
> how to improve the design. :)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33081>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 19:24:10 2018
From: report at bugs.python.org (Ronan Lamy)
Date: Sun, 18 Mar 2018 23:24:10 +0000
Subject: [issue26917] unicodedata.normalize(): bug in Hangul Composition
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1521415450.33.0.467229070634.issue26917@psf.upfronthosting.co.za>


Ronan Lamy <ronan.lamy at gmail.com> added the comment:

Victor's patch is correct. I implemented the same fix in PyPy in https://bitbucket.org/pypy/pypy/commits/92b4fb5b9e58

----------
nosy: +Ronan.Lamy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26917>
_______________________________________

From report at bugs.python.org  Sun Mar 18 19:37:32 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 18 Mar 2018 23:37:32 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521416252.15.0.467229070634.issue33081@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The garbage collector in Python does not work like that. If an object reaches zero references is destroyed immediately. The only problem is when circular references exist and is in this case when object deletion is delayed until the garbage collector runs the algorithm to detect circular references and delete them. This time is longer depending on the generation in which the object is placed.

Although this is true, there might be a problem in the lines you explain because is not guaranteed to collect garbage containing circular references (see Data Model in the documentation). In this case is important as you state to have an interface to ensure releasing the resources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Sun Mar 18 19:49:54 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 18 Mar 2018 23:49:54 +0000
Subject: [issue33098] add implicit conversion for random.choice() on a dict
In-Reply-To: <1521410428.93.0.467229070634.issue33098@psf.upfronthosting.co.za>
Message-ID: <1521416994.82.0.467229070634.issue33098@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

This won't be changed.  The dict type doesn't support efficient random choice (neither do sets, by the way), and it's been repeatedly decided that it would do a disservice to users to hide that.  As you know, you can materialize the keys in a list (or tuple) first if you _want_ to pay that cost.  Otherwise you should use a different data structure.

Note that there's really no differnce between Pythons 2 and 3 here.  If you _happen_ to have a dict that uses little integers as keys, then it can _appear_ to work, when a random integer picked from range(len(the_dict)) happens to be one of the keys.  But then you get back the associated dict value, not the key.  For example, here under Python 2.7.11:

>>> import random
>>> random.choice({0: "a", 1: "b"})
'b'
>>> random.choice({0: "a", 1: "b"})
'b'
>>> random.choice({0: "a", 1: "b"})
'a'

But if the keys don't happen to be little integers, it always fails:

>>> random.choice({"a": 1, "b": 2})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\random.py", line 275, in choice
    return seq[int(self.random() * len(seq))]  # raises IndexError if seq is empty
KeyError: 1

----------
nosy: +tim.peters
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33098>
_______________________________________

From report at bugs.python.org  Sun Mar 18 20:40:37 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 00:40:37 +0000
Subject: [issue32953] Dataclasses: frozen should not be inherited for
 non-dataclass derived classes
In-Reply-To: <1519597431.47.0.467229070634.issue32953@psf.upfronthosting.co.za>
Message-ID: <1521420037.8.0.467229070634.issue32953@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset f199bc655eb50c28e94010714629b376bbbd077b by Eric V. Smith in branch 'master':
bpo-32953: Dataclasses: frozen should not be inherited for non-dataclass derived classes (#6147)
https://github.com/python/cpython/commit/f199bc655eb50c28e94010714629b376bbbd077b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32953>
_______________________________________

From report at bugs.python.org  Sun Mar 18 20:41:52 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 19 Mar 2018 00:41:52 +0000
Subject: [issue32953] Dataclasses: frozen should not be inherited for
 non-dataclass derived classes
In-Reply-To: <1519597431.47.0.467229070634.issue32953@psf.upfronthosting.co.za>
Message-ID: <1521420112.91.0.467229070634.issue32953@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5906

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32953>
_______________________________________

From report at bugs.python.org  Sun Mar 18 20:57:09 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 19 Mar 2018 00:57:09 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521421029.98.0.467229070634.issue33083@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +5907
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Sun Mar 18 21:03:39 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 01:03:39 +0000
Subject: [issue32953] Dataclasses: frozen should not be inherited for
 non-dataclass derived classes
In-Reply-To: <1519597431.47.0.467229070634.issue32953@psf.upfronthosting.co.za>
Message-ID: <1521421419.39.0.467229070634.issue32953@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 45648312e540cda3b10109b6a808cbf6955c84eb by Eric V. Smith (Miss Islington (bot)) in branch '3.7':
bpo-32953: Dataclasses: frozen should not be inherited for non-dataclass derived classes (GH-6147) (GH-6148)
https://github.com/python/cpython/commit/45648312e540cda3b10109b6a808cbf6955c84eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32953>
_______________________________________

From report at bugs.python.org  Sun Mar 18 21:04:16 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 01:04:16 +0000
Subject: [issue32953] Dataclasses: frozen should not be inherited for
 non-dataclass derived classes
In-Reply-To: <1519597431.47.0.467229070634.issue32953@psf.upfronthosting.co.za>
Message-ID: <1521421456.34.0.467229070634.issue32953@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/issue32953>
_______________________________________

From report at bugs.python.org  Sun Mar 18 21:15:56 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 01:15:56 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521422156.96.0.467229070634.issue33094@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

There are a couple of problems here. You're using ClassVar incorrectly. It should be:

>>> @dataclass
... class C:
...   __slots__=()
...   x: ClassVar[int] = field(default=3)
... 
>>> C()
C()
>>> C.x
3


And you cannot have a ClassVar with a default_factory, since it would never get called:

>>> @dataclass
... class C:
...   __slots__=()
...   x: ClassVar[int] = field(default_factory=set)
... 

    raise TypeError(f'field {f.name} cannot have a '
TypeError: field x cannot have a default factory

Although this error message could be improved. Neither InitVars or ClassVars can have default factories.

I'm not exactly sure how to improve the error message that you're seeing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Sun Mar 18 21:16:12 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 01:16:12 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521422172.34.0.467229070634.issue33094@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/issue33094>
_______________________________________

From report at bugs.python.org  Sun Mar 18 21:29:30 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 01:29:30 +0000
Subject: [issue32960] dataclasses: disallow inheritance between frozen and
 non-frozen classes
In-Reply-To: <1519688486.17.0.467229070634.issue32960@psf.upfronthosting.co.za>
Message-ID: <1521422970.91.0.467229070634.issue32960@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Resolved by issue 32953.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32960>
_______________________________________

From report at bugs.python.org  Sun Mar 18 21:51:51 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 19 Mar 2018 01:51:51 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521424311.11.0.467229070634.issue33089@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I'd be +1 on generalizing math.hypot to accept an arbitrary number of arguments.  It's the natural building block for computing distance, but the reverse is strained.  Both are useful.

Here's scaling code translated from the Fortran implementation of SNRM2 in LAPACK.  It only looks at each element once, so would work almost as-is for an argument that's an arbitrary iterable (just change the formal argument from `*xs` to `xs`):

    # http://www.netlib.org/lapack/explore-html/d7/df1/snrm2_8f_source.html
    def hypot(*xs):
        import math
        scale = 0.0
        sumsq = 1.0
        for x in xs:
            if x:
                absx = abs(x)
                if scale < absx:
                    sumsq = 1.0 + sumsq * (scale / absx)**2
                    scale = absx
                else:
                    sumsq += (absx / scale)**2
        return scale * math.sqrt(sumsq)

I believe it does the right with infinities by magic (return math.inf).  It returns 0.0 if no arguments are passed, which makes sense.  For one argument, it's a convoluted way to return its absolute value.  The "if x:" test is necessary to prevent division by 0.0 if the first argument is 0.0.  It would need another blob of code to give up (and return math.nan) if one of the arguments is a NaN (there's no guessing what various C compilers would do without special-casing NaN).

I doubt `fsum()` would add much value here:  all the addends have the same sign, so cancellation is impossible.

To get really gonzo, a single-rounding dot product would be the best building block (the vector norm is the square root of the dot product of a vector with itself).  `fsum()` is a special case of that (the dot product of a vector with a same-length vector of all ones).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Sun Mar 18 22:38:07 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Mon, 19 Mar 2018 02:38:07 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521427087.04.0.467229070634.issue33094@psf.upfronthosting.co.za>


Adrian Stachlewski <adrian.stachlewski at gmail.com> added the comment:

Thanks for explaining. I was trying to do something like

@dataclass
class A:
  x: ClassVar = set()

and thanks to you I know it should be 

@dataclass
class A:
  x: ClassVar[Set] = set()

If you are looking for improved error message, it's probably should be somehow connected to not proper usage of annotation. I've ended with default_factory because x: ClassVar = set() wasn't working and there was no error with default_factory and without slots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Sun Mar 18 22:45:21 2018
From: report at bugs.python.org (Ma Lin)
Date: Mon, 19 Mar 2018 02:45:21 +0000
Subject: [issue26917] unicodedata.normalize(): bug in Hangul Composition
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1521427521.92.0.467229070634.issue26917@psf.upfronthosting.co.za>


Ma Lin <malincns at 163.com> added the comment:

> Victor's patch is correct.

I'm afraid you are wrong.
Please see PR 1958 in issue29456, IMO this PR can be merged.

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26917>
_______________________________________

From report at bugs.python.org  Sun Mar 18 23:30:15 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Mon, 19 Mar 2018 03:30:15 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
Message-ID: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>


New submission from Adrian Stachlewski <adrian.stachlewski at gmail.com>:

I've tried to declare two classes

@dataclass
class Base:
    __slots__ = ('x',)
    x: Any


@dataclass
class Derived(Base):
    x: int
    y: int

As long as I correctly understood PEP 557 (inheritance part), changing type of variable is possible. This code produce error:

TypeError: non-default argument 'y' follows default argument

'x' variable in Derived class has changed default from MISSING to member_descriptor and that's the reason of the exception.

----------
components: Library (Lib)
messages: 314077
nosy: stachel
priority: normal
severity: normal
status: open
title: dataclasses and __slots__ - non-default argument (member_descriptor)
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Sun Mar 18 23:43:05 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Mar 2018 03:43:05 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521430985.36.0.467229070634.issue33100@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 02:46:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Mar 2018 06:46:41 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521442001.2.0.467229070634.issue33089@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

With this implementation

>>> hypot(*range(15), 3)
32.00000000000001

The exact result is 32.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 03:04:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Mar 2018 07:04:43 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521443083.91.0.467229070634.issue33089@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

[Uncle Timmy]
> I doubt `fsum()` would add much value here:  all the addends have the 
> same sign, so cancellation is impossible

fsum() may be overkill for this problem.  I mentioned it because the math module already had the requisite code and because it improved accuracy with high dimensional data in machine learning examples I've encountered:

    >>> from math import fsum, sqrt

    >>> n = 1000
    >>> sum([0.1] * n)
    99.9999999999986
    >>> fsum([0.1] * n)
    100.0

    >>> sqrt(sum([0.1] * n) / n)
    0.3162277660168357
    >>> sqrt(fsum([0.1] * n) / n)
    0.31622776601683794

    # fsum() version exactly matches the decimal crosscheck
    >>> getcontext().prec = 40
    >>> (sum([Decimal(0.1)] * n) / n).sqrt()
    Decimal('0.3162277660168379419769730258850242641698')

If we care about those little differences (about 80 ulp in this example), the single-rounding dot products seems like a better way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 03:48:23 2018
From: report at bugs.python.org (Aristide Grange)
Date: Mon, 19 Mar 2018 07:48:23 +0000
Subject: [issue33098] add implicit conversion for random.choice() on a dict
In-Reply-To: <1521410428.93.0.467229070634.issue33098@psf.upfronthosting.co.za>
Message-ID: <1521445703.14.0.467229070634.issue33098@psf.upfronthosting.co.za>


Aristide Grange <aristide.grange at gmail.com> added the comment:

My bad... For my reference to Python 2, I relied on my memory only, which starts to vanish. Really sorry about that. Yes, `random.choice(d)` (mostly) fails in Python 2 too, with an error message that I better understand after reading your explanation.

So, in Python 2/3, when `random.choice()` is applied to a dictionary, it draws a random integer i in [0, len(d)[ and tries to return the _value_ `d[i]`. It's quite unexpected, for me at last. According to the doc:

random.choice(seq)
Return a random element from the non-empty sequence seq. If seq is empty, raises IndexError.

In Python 3, evaluating `choice(d.keys())` raises "TypeError: 'dict_keys' object does not support indexing". Shouldn't `choice(d)` _always_ fail with the same error message? I am not sure to see any legitimate use for the current behavior.

With regard to the repeated refusal to hide the fact that `choice`-ing among the keys of a dictionary is a linear operation, I can understand this decision. The general interest does not necessary align with that of an algorithmic teacher which only uses Python as a support language for introducing students to basic / transversal datatypes such as lists, arrays, dictionaries, sets, and prefers to avoid speaking of `dict_keys` and other Python's niceties...

Anyway, thanks a lot for your detailed and patient answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33098>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:17:00 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 19 Mar 2018 08:17:00 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521447420.27.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

@ncoghlan: The comparison I'm worried about is specifically this one: IIUC, right now it's safe to run 'pip --version' in an arbitrary directory, but it's not safe to run 'python -m pip --version' in an arbitrary directory. Am I wrong? (I actually couldn't convince either version to execute arbitrary code in 2 minutes of trying, but that's my understanding of the discussion so far.)

If that's correct, then I don't think this is like... the hugest security bug ever, but... I also think that it's irresponsible for e.g. packaging.python.org to be recommending people run 'python -m pip' the way it does now, and we need to find some way to change things so our beginner docs aren't triggering arbitrary code execution in a rare and subtle case.

We could add a bunch of warnings to packaging.python.org, explaining about how the code execution can be triggered, but that seems unsatisfactory given how those docs are targeted at beginners, plus there are so many places around the internet that recommend 'python -m pip' we'd never find them all.

We could update all those docs to instead recommend 'python -Im pip', but that has the same problems: no-one will understand, and people won't do it.

We could stop recommending 'python -m pip' entirely, but that runs into all the problems that have motivated this in the first place.

So I think we should find a way to make it so 'python -m pip' *never* executes code from the current directory (modulo the usual caveats, like the user explicitly setting PYTHONPATH to an insecure value etc.).

If 'python -m mypkg.myscript' is important, maybe we can make it 'PYTHONPATH=. python -m mypkg.myscript', or 'python -M mypkg.myscript', or making 'python mypkg/myscript.py' DTRT, or... something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:25:09 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Mar 2018 08:25:09 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521447909.06.0.467229070634.issue33089@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 for a single-rounded dot product. If we're allowed to assume IEEE 754, it's straightforward to code up something that's not too inefficient and gives correctly rounded results for "normal" cases, using a combination of Veltkamp splitting, Dekker multiplication, and fsum. The difficulties come in if you want to maintain correct rounding in cases where any of the partial products overflows or (especially awkwardly) underflows.

Also, if we can figure out how to do a correctly-rounded dot product, that gives us math.fma as a special case... (a*b + c = dot([a, c], [b, 1.0])). (Of course, that's a bit backwards, since usually you'd see fma as a primitive and *use* it in computing a dot product.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:25:55 2018
From: report at bugs.python.org (Robert Collins)
Date: Mon, 19 Mar 2018 08:25:55 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521447955.72.0.467229070634.issue33021@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Re: backporting this. I think backporting to 3.6/3.7 makes a lot of sense - bugfix and prerelease respectively.

For 2.7, this bug has been around for ages, the patch is small, and I have no objection - but the RM has already said no, so I guess not happening :).

That said, if I was analyzing this from scratch I'd look at the pypi download stats to assess what footprint 2.7 still has, and whether taking this fix there would make objective sense.

While it is a genuine bug - and a nice catch - I have to say that running any Python with mmapped data off of NFS is a supremely bad idea :).

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:39:04 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Mar 2018 08:39:04 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521448744.11.0.467229070634.issue33083@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raymond: what are your thoughts on deprecating the ability of `math.factorial` to accept a float (as in `math.factorial(5.0)` -> `120`)?

For me, I'm not sure I see the value of the deprecation. It's the usual story: the answer to "Knowing what we know now, should we have done this differently in the first place" is "Probably, yes". But "Should we change the current behaviour" is a very different question. I'm tempted to see the acceptance of integral floats as a harmless quirk, and the deprecation of that behaviour as a case of gratuitous breakage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:52:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Mar 2018 08:52:15 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521449535.4.0.467229070634.issue33083@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

"Special cases aren't special enough to break the rules."

Supporting floats is a special case. After ending the period of deprecation the code can be simplified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:56:31 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Mon, 19 Mar 2018 08:56:31 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521449791.9.0.467229070634.issue33094@psf.upfronthosting.co.za>


Adrian Stachlewski <adrian.stachlewski at gmail.com> added the comment:

Once more same mistake. 

'x' should be declared as: 
- x: ClassVar[set] = set()
- x: ClassVar[Set[Any]] = set()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Mon Mar 19 04:57:06 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 08:57:06 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521449826.45.0.467229070634.issue33100@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This is the same reason that this fails:

class Base:
    __slots__ = ('x',)
    x = 3

with:
ValueError: 'x' in __slots__ conflicts with class variable

In the dataclasses case, the error needs to be improved, and moved to when the base class is being defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 05:06:39 2018
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 19 Mar 2018 09:06:39 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521450399.34.0.467229070634.issue33053@psf.upfronthosting.co.za>


Antti Haapala <antti at haapala.name> added the comment:

Took 2 seconds.

% sudo python3 -mpip --version
hello world
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.6/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.6/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/usr/lib/python3/dist-packages/pip/__init__.py", line 4, in <module>
    import locale
  File "/usr/lib/python3.6/locale.py", line 180, in <module>
    _percent_re = re.compile(r'%(?:\((?P<key>.*?)\))?'
AttributeError: module 're' has no attribute 'compile'
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 53, in apport_excepthook
    if not enabled():
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 28, in enabled
    return re.search(r'^\s*enabled\s*=\s*0\s*$', conf, re.M) is None
AttributeError: module 're' has no attribute 'search'

Original exception was:
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.6/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.6/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/usr/lib/python3/dist-packages/pip/__init__.py", line 4, in <module>
    import locale
  File "/usr/lib/python3.6/locale.py", line 180, in <module>
    _percent_re = re.compile(r'%(?:\((?P<key>.*?)\))?'
AttributeError: module 're' has no attribute 'compile'

Same for `python -mhttp.server`, say. 

----

I'd prefer there be a change that the default be always safe from some version on, so that the REPL can do whatever it does, but `-m` etc probably shouldn't even have neither the *initial* current directory *nor* the current current directory in the path unless the interactive session is requested. I am not worried about the garbage that the user would have installed in their own directories breaking things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Mon Mar 19 05:14:19 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 19 Mar 2018 09:14:19 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521450859.72.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Ah, yeah, I see:

~/t$ echo 'print("hi")' > re.py
~/t$ pip --version
pip 9.0.1 from /home/njs/.user-python3.5-64bit/local/lib/python3.5/site-packages (python 3.5)
~/t$ python -m pip --version
hi
Traceback (most recent call last):
[...]

But if I create a sitecustomize.py or an io.py in the current directory (knowing that 'import io' happens implicitly startup), then those *don't* seem to get picked up by 'python -m pip' or 'python -c ...' or plain 'python'. I guess the cwd doesn't get added to sys.path until after initial bootstrapping is finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Mon Mar 19 05:14:50 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Mon, 19 Mar 2018 09:14:50 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521450890.85.0.467229070634.issue33100@psf.upfronthosting.co.za>


Adrian Stachlewski <adrian.stachlewski at gmail.com> added the comment:

I don't really get your point. 

@dataclass
class Base:
    __slots__ = ('x',)
    x: Any

This case is described in PEP 557 as correct, so I don't understand why you want to generate error. Also inheritance without defining slots is correct as stated in data model. 

In my opinion, member_descriptor should be treated same as MISSING and everything should work correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 07:32:31 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 11:32:31 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521459151.79.0.467229070634.issue33100@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

My point is that the problem is that after:

@dataclass
class Base:
    __slots__ = ('x',)
    x: Any

Base.x has a value (it's the member_descriptor for x). That's what's causing the problem that when adding a field to the derived class, it thinks you're adding a field without a default value after one that has a default value.

I agree that I could detect this specific case and allow it. My comment about the error message was inaccurate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 08:22:46 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 19 Mar 2018 12:22:46 +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: <1521462166.33.0.467229070634.issue19417@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +5908

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Mon Mar 19 08:54:24 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Mar 2018 12:54:24 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521464064.25.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It occurs to me that there may be some additional unshared context here: the way `python -m pip` searches for the module to execute is much closer to the way Windows searches for a command like `pip` (i.e. current directory first) than it is to the way *nix systems search for it (i.e. if the current directory isn't on PATH it must be specified explicitly as "./pip"). If you spend a lot of time on Windows systems, or working with Windows users, it becomes a habit to assume that folks aren't going to expect it to be safe to run arbitrary commands from arbitrary directories.

This behaviour means that if you want to intercept "python -m pip", the current easiest filename to use to intercept it is just "pip.py", similar to the way you can use "pip.exe"  or "python.exe" to intercept those commands on Windows.

I do think switching from a Windows-style default search behaviour to a *nix style default search behaviour is potentially reasonable, but the related backwards compatibility considerations would likely push it into being a PEP level change.

I'll also note that Nathaniel's right that I was wrong about `sitecustomize` always being easy to intercept from the current directory, though, as sys.path[0] gets set *after* "import site" has already executed.

I was just confusing myself, as my default approach to double-checking the behaviour of the "-m" switch is to run "python -m site", but that's misleading in this case since doing that *also* re-runs the site and user customisation modules (and will pick them up from the current working directory) - it's closely akin to testing `python3 -c "import runpy; runpy.run_module('site', run_name='__main__')"`

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Mon Mar 19 09:19:15 2018
From: report at bugs.python.org (Yomguithereal)
Date: Mon, 19 Mar 2018 13:19:15 +0000
Subject: [issue33101] Possible name inversion in heapq implementation
Message-ID: <1521465555.06.0.467229070634.issue33101@psf.upfronthosting.co.za>


New submission from Yomguithereal <guillaumeplique at gmail.com>:

Hello Python team,

I might be hallucinating but I am under the impression that the `heapq` module uses reverse naming.

What I mean is that it seems to me that the _siftup method should actually be named _siftdown and, the other way around, _siftdown should be named _siftup.

This has absolutely no practical consequence since the module works as it should but I am a bit confused since I don't know if the module got naming wrong or if it followed another canonical naming I don't know about.

I am willing to open a PR to fix this if the named reverasl was to be confirmed.

Good day to you.

----------
components: Library (Lib)
messages: 314093
nosy: Yomguithereal
priority: normal
severity: normal
status: open
title: Possible name inversion in heapq implementation
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33101>
_______________________________________

From report at bugs.python.org  Mon Mar 19 09:25:56 2018
From: report at bugs.python.org (amjad ben hedhili)
Date: Mon, 19 Mar 2018 13:25:56 +0000
Subject: [issue33102] get the nth folder
Message-ID: <1521465956.78.0.467229070634.issue33102@psf.upfronthosting.co.za>


New submission from amjad ben hedhili <amjadbenhedhili at gmail.com>:

It will be handy if there was an os or os.path function that returns the path to the nth directory in a given path

for example:
given path = "C:\Users\User\AppData\Local\Programs\Python\Python36\Lib\asyncio\__init__.py"

os.path.nthpath(path, 2) returns "C:\Users\User\AppData\Local\Programs\Python\Python36\Lib"

----------
messages: 314094
nosy: amjad ben hedhili
priority: normal
severity: normal
status: open
title: get the nth folder
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33102>
_______________________________________

From report at bugs.python.org  Mon Mar 19 09:26:58 2018
From: report at bugs.python.org (amjad ben hedhili)
Date: Mon, 19 Mar 2018 13:26:58 +0000
Subject: [issue33102] get the nth folder of a given path
In-Reply-To: <1521465956.78.0.467229070634.issue33102@psf.upfronthosting.co.za>
Message-ID: <1521466018.4.0.467229070634.issue33102@psf.upfronthosting.co.za>


Change by amjad ben hedhili <amjadbenhedhili at gmail.com>:


----------
title: get the nth folder -> get the nth folder of a given path

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33102>
_______________________________________

From report at bugs.python.org  Mon Mar 19 09:36:19 2018
From: report at bugs.python.org (amjad ben hedhili)
Date: Mon, 19 Mar 2018 13:36:19 +0000
Subject: [issue33103] Syntax to get multiple items from an iterable
Message-ID: <1521466579.3.0.467229070634.issue33103@psf.upfronthosting.co.za>


New submission from amjad ben hedhili <amjadbenhedhili at gmail.com>:

It will be much of improvement for readability to write:

my_list = ["John", "Richard", "Alice", 1, True, 2.1, "End"]
a, b, c = my_list[1, 3, -1]

instead of:

my_list = ["John", "Richard", "Alice", 1, True, 2.1, "End"]
a, b, c = my_list[1], my_list[3], my_list[-1]

----------
messages: 314095
nosy: amjad ben hedhili
priority: normal
severity: normal
status: open
title: Syntax to get multiple items from an iterable
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33103>
_______________________________________

From report at bugs.python.org  Mon Mar 19 09:36:49 2018
From: report at bugs.python.org (amjad ben hedhili)
Date: Mon, 19 Mar 2018 13:36:49 +0000
Subject: [issue33103] Syntax to get multiple arbitrary items from an iterable
In-Reply-To: <1521466579.3.0.467229070634.issue33103@psf.upfronthosting.co.za>
Message-ID: <1521466609.38.0.467229070634.issue33103@psf.upfronthosting.co.za>


Change by amjad ben hedhili <amjadbenhedhili at gmail.com>:


----------
title: Syntax to get multiple items from an iterable -> Syntax to get multiple arbitrary items from an iterable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33103>
_______________________________________

From report at bugs.python.org  Mon Mar 19 09:57:14 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 13:57:14 +0000
Subject: [issue33102] get the nth folder of a given path
In-Reply-To: <1521465956.78.0.467229070634.issue33102@psf.upfronthosting.co.za>
Message-ID: <1521467834.85.0.467229070634.issue33102@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Path.parents will do what you want. I don't have a Windows box handy, but this is on MacOS:

>>> from pathlib import Path
>>> p = Path("/Users/User/AppData/Local/Programs/Python/Python36/Lib/asyncio/__init__.py")
>>> p.parents[1]
PosixPath('/Users/User/AppData/Local/Programs/Python/Python36/Lib')
>>>

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33102>
_______________________________________

From report at bugs.python.org  Mon Mar 19 11:19:54 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Mar 2018 15:19:54 +0000
Subject: [issue33101] Possible name inversion in heapq implementation
In-Reply-To: <1521465555.06.0.467229070634.issue33101@psf.upfronthosting.co.za>
Message-ID: <1521472794.46.0.467229070634.issue33101@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There isn't universal agreement on whether it should be sift up or sift down.  One point of view for sift down is that the datum is moving downward.  The other point of view is that the datum is stationary which the rest of the heap moves downward (like sifting a ring out of flour).  Different sources make different choices in this regard. 


"There is some confusion in the literature on the naming of the siftup/down routines. presented above. The routine named siftdown here is called siftdown in [1], siftup. in [3], trickledown in [4] and heapify in [5]." -- www.diku.dk/~jyrki/PE-lab/Jesper/heaplab/survey.ps.gz

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33101>
_______________________________________

From report at bugs.python.org  Mon Mar 19 11:48:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Mar 2018 15:48:09 +0000
Subject: [issue33103] Syntax to get multiple arbitrary items from an iterable
In-Reply-To: <1521466579.3.0.467229070634.issue33103@psf.upfronthosting.co.za>
Message-ID: <1521474489.04.0.467229070634.issue33103@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This syntax already is supported for dicts and NumPy arrays, but with different semantic.

>>> d = {(1, 2): 'foo'}
>>> d[1, 2]
'foo'
>>> a = numpy.array([[1, 2], [3, 4]])
>>> a[1, 0]
3

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33103>
_______________________________________

From report at bugs.python.org  Mon Mar 19 12:07:10 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 19 Mar 2018 16:07:10 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521475630.23.0.467229070634.issue33089@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Some notes on the hypot() code I pasted in:  first, it has to special case infinities too - it works fine if there's only one of 'em, but returns a NaN if there's more than one (it ends up computing inf/inf, and the resulting NaN propagates).

Second, it's not clear to me what the result "should be" if there's at least one infinity _and_ at least one NaN.  At the start, "anything with a NaN input returns a NaN" was the rule everything followed.  Later an exception to that was made for NaN**0 == 1, under the theory that it didn't really matter if the computation of the base screwed up, because anything whatsoever to the 0 power is 1 0 viewing NaN as meaning "we have no idea what the true value is", it simply doesn't matter what the true value is in this context.  By the same logic, if there's an infinite argument to hypot(), it doesn't matter what any other argument is - the result is +inf regardless.  So that requires some investigation.  Offhand I'm inclined to return NaN anyway.

Finally, if there is a robust single-rounding dot product, of course scaling can be skipped (and so eliminate another source of small errors).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 12:21:06 2018
From: report at bugs.python.org (Eric Appelt)
Date: Mon, 19 Mar 2018 16:21:06 +0000
Subject: [issue33104] Documentation for EXTENDED_ARG in dis module is
 incorrect for >=3.6
Message-ID: <1521476466.68.0.467229070634.issue33104@psf.upfronthosting.co.za>


New submission from Eric Appelt <eric.appelt at gmail.com>:

The documentation for the EXTENDED_ARG instruction in the dis module documentation refers to the way the opcode worked before 3.6: https://docs.python.org/3.6/library/dis.html#opcode-EXTENDED_ARG

As I understand, since moving to 2-byte wordcode in 3.6, each EXTENDED_ARG effectively adds a byte to the argument of the next instruction and they can be chained to allow up to a 32-bit argument. The current documentation refers the 2-byte arguments from the older bytecode used in 3.5 and below.

I'm trying to think of a clear and concise wording for how it works now and will add a PR to fix this issue unless someone gets to it before me.

----------
assignee: docs at python
components: Documentation
messages: 314100
nosy: Eric Appelt, docs at python
priority: normal
severity: normal
status: open
title: Documentation for EXTENDED_ARG in dis module is incorrect for >=3.6
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33104>
_______________________________________

From report at bugs.python.org  Mon Mar 19 12:27:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Mar 2018 16:27:26 +0000
Subject: [issue33104] Documentation for EXTENDED_ARG in dis module is
 incorrect for >=3.6
In-Reply-To: <1521476466.68.0.467229070634.issue33104@psf.upfronthosting.co.za>
Message-ID: <1521476846.12.0.467229070634.issue33104@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Isn't this a duplicate of issue32625?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33104>
_______________________________________

From report at bugs.python.org  Mon Mar 19 12:29:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Mar 2018 16:29:10 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1521476950.29.0.467229070634.issue26647@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -1041

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Mon Mar 19 12:41:56 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Mar 2018 16:41:56 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521477716.03.0.467229070634.issue33089@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> By the same logic, if there's an infinite argument to hypot(), it doesn't matter what any other argument is - the result is +inf regardless.

Yep, that's what IEEE 754-2008 says for the two-argument case, so I think that's the logic that should be followed in the many-argument case: if any of the inputs is an infinity, the output should be infinity.

>From section 9.2.1 of IEEE 754:

> For the hypot function, hypot(?0, ?0) is +0, hypot(? , qNaN) is + , and
> hypot(qNaN, ? ) is + .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 12:43:34 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Mar 2018 16:43:34 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521477814.14.0.467229070634.issue33089@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, that cut and paste didn't work so well. Just imagine an infinity symbol in those missing spaces. Trying again:

> For the hypot function, hypot(?0, ?0) is +0, hypot(??, qNaN) is +?, and
> hypot(qNaN, ??) is +?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 13:26:11 2018
From: report at bugs.python.org (paul j3)
Date: Mon, 19 Mar 2018 17:26:11 +0000
Subject: [issue32756] argparse: parse_known_args: raising exception on unknown
 arg following known one
In-Reply-To: <1517661104.06.0.467229070634.issue32756@psf.upfronthosting.co.za>
Message-ID: <1521480371.62.0.467229070634.issue32756@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

>From the documentation, 16.4.4.1. Option value syntax

> For short options (options only one character long), the option and its value can be concatenated:

> Several short options can be joined together, using only a single - prefix, as long as only the last option (or none of them) requires a value:

It does not promise that an short option and an unrelated (not-required) value will work.  The only value that works in such a construct is one required by the last short option.

I think this should be closed, unless you can support your expectations from documentation, or examples from other parsers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32756>
_______________________________________

From report at bugs.python.org  Mon Mar 19 13:30:50 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 19 Mar 2018 17:30:50 +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: <1521480650.86.0.467229070634.issue19417@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 424f3dafea16fbaee55a30903af2d6717f4d4a6b by Mariatta (xdegaye) in branch '3.6':
bpo-19417: Add test_bdb.py (GH-5217)
https://github.com/python/cpython/commit/424f3dafea16fbaee55a30903af2d6717f4d4a6b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Mon Mar 19 13:41:26 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 19 Mar 2018 17:41:26 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1521481286.81.0.467229070634.issue31550@psf.upfronthosting.co.za>


Change by Anthony Sottile <asottile at umich.edu>:


----------
pull_requests: +5909

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Mon Mar 19 13:44:23 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 19 Mar 2018 17:44:23 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1521481463.71.0.467229070634.issue31550@psf.upfronthosting.co.za>


Anthony Sottile <asottile at umich.edu> added the comment:

I made a new PR which instead *reverts* the python2.7 patch to restore consistency

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Mon Mar 19 13:51:21 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 19 Mar 2018 17:51:21 +0000
Subject: [issue25433] whitespace in strip()/lstrip()/rstrip()
In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>
Message-ID: <1521481881.61.0.467229070634.issue25433@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25433>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:08:00 2018
From: report at bugs.python.org (Eric Appelt)
Date: Mon, 19 Mar 2018 18:08:00 +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: <1521482880.23.0.467229070634.issue32625@psf.upfronthosting.co.za>


Change by Eric Appelt <eric.appelt at gmail.com>:


----------
nosy: +Eric Appelt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32625>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:09:55 2018
From: report at bugs.python.org (Eric Appelt)
Date: Mon, 19 Mar 2018 18:09:55 +0000
Subject: [issue33104] Documentation for EXTENDED_ARG in dis module is
 incorrect for >=3.6
In-Reply-To: <1521476466.68.0.467229070634.issue33104@psf.upfronthosting.co.za>
Message-ID: <1521482995.07.0.467229070634.issue33104@psf.upfronthosting.co.za>


Eric Appelt <eric.appelt at gmail.com> added the comment:

Yes, thanks. I failed to see the duplicate searching for open issues, closing.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33104>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:09:57 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Mar 2018 18:09:57 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1521482997.3.0.467229070634.issue32968@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Mark, I tried `Fraction(10**23) // 1e22`, and I got 10.

Sorry: that result was with your PR (as it was at the time I wrote that comment). On master, you do indeed get 10.

> I think the fact that floating-point rounding error sometimes causes
> strange results is not a reason to do really unexpected things like
> making 1.0 // 1/10 equal 9.0, if that can be reasonably avoided.

I understand, but I think in this case, the cure is worse than the disease. I don't think converting the float to a Fraction in mixed-type operations is going to work, for a number of reasons:

- it's changing the behaviour for _all_ the arithmetic operations, not just // and %; that widens the scope for accidental breakage. For example, with the latest commit 038664e6a6288f6113ab96103e57d3b25b39a8c2 on your PR:

>>> Fraction(1) + math.inf
inf
>>> math.inf + Fraction(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mdickinson/Python/cpython/Lib/fractions.py", line 391, in reverse
    return float(fallback_operator(Fraction(a), b))
  File "/Users/mdickinson/Python/cpython/Lib/fractions.py", line 130, in __new__
    self._numerator, self._denominator = numerator.as_integer_ratio()
OverflowError: cannot convert Infinity to integer ratio

But on master, we have:

>>> import math
>>> from fractions import Fraction
>>> math.inf + Fraction(1)
inf
>>> Fraction(1) + math.inf
inf

- it's counter to the spirit of the numeric tower, where for most arithmetic operations, values are propagated _up_ the tower (from Integral -> Rational -> Real -> Complex) to the first common type before the operation is performed. That keeps things simple; having some cases where values are converted down the tower is going to cause confusion. (Comparisons are necessarily a special case: the need to preserve transitivity of equality and trichotomy means that using the same rules as for arithmetic operations won't fly)

- it introduces a non-obvious difference between mixed-mode Fraction-float and int-float operations. For an int x and a float y, I'd expect the result of `x <some_op> y` to be identical to the result of `Fraction(x) <some_op> y`.

So I'm sorry, but I do think having 1.0 // Fraction(1, 10) give 9.0 rather than 10.0 is the least worst option here. It's a surprise, but it's not a _new_ surprise: it's a surprise that's already there in the world of floating-point arithmetic.

>>> 1.0 // 0.1
9.0

You're evaluating a discontinuous function _at_ a discontinuity, using a type that's known for its inexactness. In that situation, getting the value for _either_ side of that discontinuity is reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:28:31 2018
From: report at bugs.python.org (Luis Conejo-Alpizar)
Date: Mon, 19 Mar 2018 18:28:31 +0000
Subject: [issue33105] os.isfile returns false on Windows when file path is
 longer than 260 characters
Message-ID: <1521484111.52.0.467229070634.issue33105@psf.upfronthosting.co.za>


New submission from Luis Conejo-Alpizar <luisconej at gmail.com>:

Windows has a maximum path length limitation of 260 characters. This limitation, however, can be bypassed in the scenario described below. When this occurs, os.isfile() will return false, even when the affected file does exist. For Windows systems, the behavior should be for os.isfile() to return an exception in this case, indicating that maximum path length has been exceeded.

Sample scenario:

1. Let's say you have a folder, named F1 and located in your local machine at this path:

C:\tc\proj\MTV\cs_fft\Milo\Fries\STL\BLNA\F1\

2. Inside of that folder, you have a log file with this name:

This_is_a_really_long_file_name_that_by_itself_is_not_capable_of_exceeding_the_path_length_limitation_Windows_has_in_pretty_much_every_single_version_of_Wind.log

3. The combined length of the path and the file is exactly 260 characters, so Windows lets you get away with it when the file is initially created and/or placed there.

4. Later, you decide to make the F1 folder available on your network, under this name:

\\tst\tc\proj\MTV\cs_fft\Milo\Fries\STL\BLNA\F1\

5. Your log file continues to be in the folder, but its full network path is now 263 characters, effectively violating the maximum path length limitation.

6. If you use os.listdir() on the networked folder, the log file will come up.

7. Now, if you try os.path.isfile(os.path.join(networked_path,logfile_name)) it will return false, even though the file is indeed there and is indeed a file.

----------
components: Library (Lib)
messages: 314109
nosy: ldconejo
priority: normal
severity: normal
status: open
title: os.isfile returns false on Windows when file path is longer than 260 characters
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33105>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:30:05 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Mar 2018 18:30:05 +0000
Subject: [issue33105] os.isfile returns false on Windows when file path is
 longer than 260 characters
In-Reply-To: <1521484111.52.0.467229070634.issue33105@psf.upfronthosting.co.za>
Message-ID: <1521484205.47.0.467229070634.issue33105@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33105>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:38:50 2018
From: report at bugs.python.org (Arran McCutcheon)
Date: Mon, 19 Mar 2018 18:38:50 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1521484730.75.0.467229070634.issue25345@psf.upfronthosting.co.za>


Arran McCutcheon <arran-m at hotmail.com> added the comment:

Hi Steve, thanks for the reply. I tried the download again and got the same error with a slightly different log file, hopefully that will help identify the problem. Apart from that, I don't know of any other Python log files, there's no others in the same folder and I can't find others elsewhere. The full error message reads: 'Another installation is already in progress. Complete that installation before proceeding with this install.'

----------
Added file: https://bugs.python.org/file47494/Python 3.6.4 (64-bit)_20180319182314.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Mon Mar 19 14:41:40 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 19 Mar 2018 18:41:40 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521484900.01.0.467229070634.issue33061@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 4573820d2a9156346392838d455e89f33067e9dd by Ivan Levkivskyi (aetracht) in branch 'master':
bpo-33061: Add missing 'NoReturn' to __all__ in typing.py (GH-6127)
https://github.com/python/cpython/commit/4573820d2a9156346392838d455e89f33067e9dd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Mon Mar 19 15:05:12 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 19 Mar 2018 19:05:12 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1521486312.32.0.467229070634.issue25345@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Arran - I think you have something else going wrong with your machine. There is nothing we do to cause multiple installs to start at the same time, and if rebooting does not help then I have to assume you have some permanently corrupt state.

Have you installed Windows Updates recently? I would expect that updates will either fail (and may be able to recover better than a 3rd-party installer) or succeed and clear the state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Mon Mar 19 15:12:06 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 19 Mar 2018 19:12:06 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521486726.99.0.467229070634.issue33089@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Mark, thanks!  I'm happy with that resolution:  if any argument is infinite, return +inf; else if any argument is a NaN, return a NaN; else do something useful ;-)

Serhiy, yes, the scaling that prevents catastrophic overflow/underflow due to naively squaring unscaled values can introduce small errors of its own.  A single-rounding dot product could avoid that, leaving two sources of single-rounding errors (the dot product, and the square root).

Raymond, yes, fsum() on its own can reduce errors.  Note that scaling on its own can also reduce errors (in particular, when the arguments are all the same, they're each scaled to exactly 1.0):

>>> import math
>>> n = 1000
>>> math.sqrt(sum([0.1 ** 2] * n))
3.1622776601683524
>>> math.sqrt(math.fsum([0.1 ** 2] * n))
3.1622776601683795
>>> hypot(*([0.1] * n)) # using the code above
3.1622776601683795
>>> math.sqrt(n) * 0.1
3.1622776601683795

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 15:17:44 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 19 Mar 2018 19:17:44 +0000
Subject: [issue33105] os.isfile returns false on Windows when file path is
 longer than 260 characters
In-Reply-To: <1521484111.52.0.467229070634.issue33105@psf.upfronthosting.co.za>
Message-ID: <1521487064.21.0.467229070634.issue33105@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Given basically every other file operation on Windows XP will also break on this file, I don't think it's worth us fixing in 2.7.

If it occurs on Python 3.6 on Windows 7, we can consider it. But considering how well known this limitation is (and the workarounds for newer OSs), I don't think it's particularly urgent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33105>
_______________________________________

From report at bugs.python.org  Mon Mar 19 15:51:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Mar 2018 19:51:36 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1521489095.99.0.467229070634.issue31550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to leave this as-is.  Consistency between error message wording is one of our least important considerations.  The __getitem__ message is somewhat useful -- it helps learners know which magic method is being called and what they would need to add to a class to make it work.  This was the typical wording for old-style classes.  For example, calling len() on an old-style class without __len__ gave this message, "AttributeError: A instance has no attribute '__len__'".

In addition, we are getting very close to end-of-life for Python2.7.  Accordingly, any changes at this point should be limited to things that really matter.  It will be too easy to introduce a new problem that we won't have an opportunity to fix later.

I recommend closing this and shifting attention to things that matter.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Mon Mar 19 16:00:19 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 19 Mar 2018 20:00:19 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1521489619.88.0.467229070634.issue31550@psf.upfronthosting.co.za>


Anthony Sottile <asottile at umich.edu> added the comment:

I think the main concern here is ease in portability coupled with the incorrectness of the current message (pointed out in https://bugs.python.org/issue31550#msg302738)

For instance it was consistent in 2.7.1, but not later on in the 2.7.x tree.  *And* it's different than python3 (for no good reason?)

The message is misleading as well, it's not looking for __getitem__ on the instance but on the type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Mon Mar 19 16:37:00 2018
From: report at bugs.python.org (Arran McCutcheon)
Date: Mon, 19 Mar 2018 20:37:00 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1521491820.93.0.467229070634.issue25345@psf.upfronthosting.co.za>


Arran McCutcheon <arran-m at hotmail.com> added the comment:

Yes there have been various Cumulative Updates and Security Updates in the past few months, the most recent five days ago. Last features update was successfully installed in December. Update Status: Your device is up to date. Last checked today, 09:14. 
I certainly agree that it's a machine issue, although it's strange that I'm still able to install windows updates, notepads, video editors etc without problems. I just tried to install Java - and got a similar error. According to the Java error, msiexec.exe is currently processing another installation. It seems to only be a problem when attempting to install programming languages. Could a clean boot help? I saw that recommended somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Mon Mar 19 16:45:55 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Mar 2018 20:45:55 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1521492355.42.0.467229070634.issue31550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> it's different than python3 (for no good reason?)
Python 3 has new style classes which were always different.

> main concern here is ease in portability  
We've long stated that there should never be dependency on the exact wording of an error message.  We're allowed to change that.

> For instance it was consistent in 2.7.1
To the extent we care about this, it is more important to be consistent with later releases than earlier releases.

Since I don't see any evidence that there is a real world problem, I would like to see this left alone.  At this point, in Python 2.7's life we need to have a strong aversion to any changes at all.  Not only has that ship sailed, its voyage is almost over.

----------
versions: +Python 2.7 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Mon Mar 19 17:44:11 2018
From: report at bugs.python.org (sds)
Date: Mon, 19 Mar 2018 21:44:11 +0000
Subject: [issue33106] Deleting a key in a read-only gdbm results in KeyError, 
 not gdbm.error
Message-ID: <1521495851.1.0.467229070634.issue33106@psf.upfronthosting.co.za>


New submission from sds <sds at gnu.org>:

deleting a key from a read-only gdbm should be gdbm.error, not KeyError:


>>> import gdbm
>>> db = gdbm.open("foo","n")   # create new
>>> db["a"] = "b"
>>> db.close()
>>> db = gdbm.open("foo","r")   # read only
>>> db["x"] = "1"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
gdbm.error: Reader can't store    # correct
>>> db["a"]
'b'
>>> del db["a"]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'a'    # WRONG!  should be the same as above

----------
components: Library (Lib)
messages: 314119
nosy: sam-s
priority: normal
severity: normal
status: open
title: Deleting a key in a read-only gdbm results in KeyError, not gdbm.error
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33106>
_______________________________________

From report at bugs.python.org  Mon Mar 19 17:49:04 2018
From: report at bugs.python.org (sds)
Date: Mon, 19 Mar 2018 21:49:04 +0000
Subject: [issue33106] Deleting a key in a read-only gdbm results in KeyError, 
 not gdbm.error
In-Reply-To: <1521495851.1.0.467229070634.issue33106@psf.upfronthosting.co.za>
Message-ID: <1521496144.33.0.467229070634.issue33106@psf.upfronthosting.co.za>


sds <sds at gnu.org> added the comment:

Same problem with 3.6.4, start with

>>> from dbm import gnu as gdbm

then the same incorrect behavior

----------
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33106>
_______________________________________

From report at bugs.python.org  Mon Mar 19 17:52:16 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Mon, 19 Mar 2018 21:52:16 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521496336.21.0.467229070634.issue33100@psf.upfronthosting.co.za>


Adrian Stachlewski <adrian.stachlewski at gmail.com> added the comment:

There's also another major problem. Because Base.x has value, __init__ is not prepared correctly (member_descriptor is passed as default). 

@dataclass
class Base:
    __slots__ = ('x',)
    x: Any

Base()  # No TypeError exception

Fixing this should be quite easy, if you want I can prepare PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 18:30:01 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Mar 2018 22:30:01 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521498601.63.0.467229070634.issue33100@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, but I'm already looking at this in the context of a different bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 19:04:49 2018
From: report at bugs.python.org (Matthias Kievernagel)
Date: Mon, 19 Mar 2018 23:04:49 +0000
Subject: [issue3405] Add support for the new data option supported by event
 generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1521500689.78.0.467229070634.issue3405@psf.upfronthosting.co.za>


Change by Matthias Kievernagel <mkiever at web.de>:


----------
nosy: +mkiever

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Mon Mar 19 20:19:56 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 20 Mar 2018 00:19:56 +0000
Subject: [issue33087] No reliable clean shutdown method
In-Reply-To: <1521222247.28.0.467229070634.issue33087@psf.upfronthosting.co.za>
Message-ID: <1521505196.79.0.467229070634.issue33087@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
type: behavior -> enhancement
versions: +Python 3.8 -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/issue33087>
_______________________________________

From report at bugs.python.org  Mon Mar 19 20:49:32 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 00:49:32 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521506972.42.0.467229070634.issue33100@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5910
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 20:55:02 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 20 Mar 2018 00:55:02 +0000
Subject: [issue33105] os.path.isfile returns false on Windows when file path
 is longer than 260 characters
In-Reply-To: <1521484111.52.0.467229070634.issue33105@psf.upfronthosting.co.za>
Message-ID: <1521507302.95.0.467229070634.issue33105@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Python 2.7 is all but set in stone. Changes to its behavior have to correct serious bugs, not work around limits in an OS. You can do that yourself. For example, use an extended local-device path, i.e. a path that's prefixed by u"\\\\?\\". This path type must be unicode, fully-qualified, and use only backslash as the path separator. Also, the UNC device has to be used explicitly. Python 2 has poor support for unicode raw strings (\u and \U escapes aren't disabled), so you can instead use forward slashes and normpath(). For example: 

    f1_path = os.path.normpath(u"//?/UNC/tst/tc/proj/MTV/cs_fft/Milo/Fries/STL/BLNA/F1") 
    log_path = os.path.join(f1_path, log_filename)
    assert os.path.isfile(log_path)

----------
nosy: +eryksun
title: os.isfile returns false on Windows when file path is longer than 260 characters -> os.path.isfile returns false on Windows when file path is longer than 260 characters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33105>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:07:55 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 01:07:55 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521508075.71.0.467229070634.issue33100@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 7389fd935c95b4b6f094312294e703ee0de18719 by Eric V. Smith in branch 'master':
bpo-33100: Dataclasses now handles __slots__ and default values correctly. (GH-6152)
https://github.com/python/cpython/commit/7389fd935c95b4b6f094312294e703ee0de18719


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:08:15 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 01:08:15 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521508095.66.0.467229070634.issue33100@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:11:32 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 01:11:32 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1521508292.83.0.467229070634.issue1467929@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee: eric.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:12:25 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Mar 2018 01:12:25 +0000
Subject: [issue33103] Syntax to get multiple arbitrary items from an iterable
In-Reply-To: <1521466579.3.0.467229070634.issue33103@psf.upfronthosting.co.za>
Message-ID: <1521508345.15.0.467229070634.issue33103@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, there is already a way to do this but it involves the extra step of applying map() to a bound method:

>>> my_list = ["John", "Richard", "Alice", 1, True, 2.1, "End"]
>>> a, b, c = map(my_list.__getitem__, [1, 3, -1])
>>> a
'Richard'
>>> b
1
>>> c
'End'

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33103>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:12:55 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 20 Mar 2018 01:12:55 +0000
Subject: [issue33105] os.path.isfile returns false on Windows when file path
 is longer than 260 characters
In-Reply-To: <1521484111.52.0.467229070634.issue33105@psf.upfronthosting.co.za>
Message-ID: <1521508375.14.0.467229070634.issue33105@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> If you use os.listdir() on the networked folder, the log file 
> will come up.

Querying a file's parent directory (e.g. via os.scandir in Python 3) can provide a basic stat (i.e. attributes, reparse tag, size, and timestamps) when opening the file directly fails. Currently the os.[l]stat implementation in Python 3 falls back on querying the directory for ERROR_ACCESS_DENIED (e.g. due to a file's security, delete disposition, or an exclusive open) and ERROR_SHARING_VIOLATION (e.g. a system paging file). 

This could be expanded to ERROR_PATH_NOT_FOUND, which among other reasons, can indicate the path was too long if long-path support isn't available. This would expand the reach to all files in which the path of the parent directory is less than MAX_PATH. This would keep os.[l]stat consistent with os.listdir and os.scandir, which it currently is not. For example:

    >>> parent_path, filename = os.path.split(path)
    >>> len(path), len(parent_path), filename
    (264, 255, 'spam.txt')

    >>> os.path.exists(path)
    False
    >>> entry = next(os.scandir(parent_path))
    >>> entry.name
    'spam.txt'
    >>> entry.stat()
    os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0,
                   st_uid=0, st_gid=0, st_size=0, st_atime=1521507879,
                   st_mtime=1521507879, st_ctime=1521507879)

----------
components: +Windows
stage:  -> needs patch
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33105>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:23:04 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 01:23:04 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521508984.15.0.467229070634.issue33094@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Are there any remaining issues here? If not, I'm going to close this issue.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:31:25 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 01:31:25 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521509485.48.0.467229070634.issue33100@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 3d41f482594b6aab12a316202b3c06757262109a by Eric V. Smith (Miss Islington (bot)) in branch '3.7':
bpo-33100: Dataclasses now handles __slots__ and default values correctly. (GH-6152) (GH-6153)
https://github.com/python/cpython/commit/3d41f482594b6aab12a316202b3c06757262109a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:39:18 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 01:39:18 +0000
Subject: [issue33100] dataclasses and __slots__ - non-default argument
 (member_descriptor)
In-Reply-To: <1521430215.98.0.467229070634.issue33100@psf.upfronthosting.co.za>
Message-ID: <1521509958.18.0.467229070634.issue33100@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/issue33100>
_______________________________________

From report at bugs.python.org  Mon Mar 19 21:49:38 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 20 Mar 2018 01:49:38 +0000
Subject: [issue33089] Add multi-dimensional Euclidean distance function to the
 math module
In-Reply-To: <1521226258.78.0.467229070634.issue33089@psf.upfronthosting.co.za>
Message-ID: <1521510578.75.0.467229070634.issue33089@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Mark, how about writing a clever single-rounding dot product that merely _detects_ when it encounters troublesome cases?  If so, it can fall back to a (presumably) much slower method.  For example, like this for the latter:

    def srdp(xs, ys):
        "Single rounding dot product."
        import decimal
        from decimal import Decimal, Inexact
        # XXX check that len(xs) == len(ys)
        with decimal.localcontext(decimal.ExtendedContext) as ctx:
            ctx.traps[Inexact] = True
            total = Decimal(0)
            for x, y in zip(map(Decimal, xs), map(Decimal, ys)):
                while True:
                    try:
                        total += x * y
                        break
                    except Inexact:
                        ctx.prec += 1
            return float(total)

So it just converts everything to Decimal; relies on decimal following all the IEEE rules for special cases; retries the arithmetic boosting precision until decimal gets an exact result (which it eventually will since we're only doing + and *); and relies on float() to get everything about final rounding, overflow, and denorms right.  If that doesn't work, I'd say it's a bug in the decimal module ;-)

I'd bet a dollar that, in real life, falling back to this would almost never happen, outside of test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33089>
_______________________________________

From report at bugs.python.org  Mon Mar 19 23:08:12 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 20 Mar 2018 03:08:12 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521515292.68.0.467229070634.issue33053@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> the way `python -m pip` searches for the module to execute is much 
> closer to the way Windows searches for a command like `pip` (i.e. 
> current directory first)

That's classic Windows behavior. However, search paths for CreateProcess and the loader are composed on demand, which allows different behavior to be selected easily enough. The current behavior depends on a mix of environment variables, registry settings, reserved names (known DLLs, API sets), application and DLL manifests, .local redirection, and in-process configuration. For example, to skip the working directory when searching for DLLs, there's the CWDIllegalInDllSearch registry setting, SetDllDirectoryW(L""), or SetDefaultDllDirectories (the latter removes PATH as well, so it's not suited for loosely-couple systems). To skip  the working directory when searching for executables, define the environment variable "NoDefaultCurrentDirectoryInExePath".

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Tue Mar 20 02:39:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Mar 2018 06:39:47 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521527987.76.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5912

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Tue Mar 20 02:40:57 2018
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 20 Mar 2018 06:40:57 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1521528057.73.0.467229070634.issue32872@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

reopening.

Lib/test/libregrtest/setup.py still needs fixing at least on 3.6, I didn't check the trunk.

libregrtest/setup.py:

60c60
<         if hasattr(module, '__file__'):
---
>         if getattr(module, '__file__', None):

----------
stage:  -> patch review
status:  -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Tue Mar 20 02:41:39 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 20 Mar 2018 06:41:39 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521528099.5.0.467229070634.issue33034@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 2cb4661707818cfd92556e7fdf9068a993577002 by Berker Peksag (Matt Eaton) in branch 'master':
bpo-33034: Improve exception message when cast fails for {Parse,Split}Result.port (GH-6078)
https://github.com/python/cpython/commit/2cb4661707818cfd92556e7fdf9068a993577002


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Tue Mar 20 02:46:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Mar 2018 06:46:02 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521528362.58.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm surprised, but seems PR 6154 fixes the whole issue 3 in 3.7.

It keeps only one POP_BLOCK corresponding to SETUP_LOOP. It also make the generated bytecode a tiny bit more efficient (less jumps).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Tue Mar 20 05:23:12 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 09:23:12 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1521537792.4.0.467229070634.issue33084@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/issue33084>
_______________________________________

From report at bugs.python.org  Tue Mar 20 05:43:06 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 20 Mar 2018 09:43:06 +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: <1521538986.74.0.467229070634.issue19417@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +5913

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Tue Mar 20 06:00:28 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 20 Mar 2018 10:00:28 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521540028.19.0.467229070634.issue28247@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Paul,

Were you interested in moving forward with this doc change?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 06:19:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Mar 2018 10:19:51 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521541191.74.0.467229070634.issue33069@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Donald made an interesting suggestion over on https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331, which was to have distutils stop overwriting the Author metadata with the Maintainer metadata when both are specified and instead emit a warning about an unknown keyword argument.

I'm not sure we'd want to change the behaviour of mapping Maintainer -> Author (since it's a nice way to retain credit in the code, while changing the metadata on PyPI to reflect the current metadata), but I *do* think it would be reasonable to have distutils emit a warning that metadata version 1.1 can't represent the maintainer information properly, and folks should upgrade to using setuptools instead.

?ric, your thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Tue Mar 20 06:42:51 2018
From: report at bugs.python.org (Paul Moore)
Date: Tue, 20 Mar 2018 10:42:51 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521542571.85.0.467229070634.issue28247@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Hi Cheryl,
Looks like I dropped the ball on this one :-( I think it just needs to be applied to the main branch (3.7/3.8) - I don't think it's worth backporting.

I'll try to get to it when I can, but it may not be for a few weeks, as I have other stuff on my plate at the moment. I've not done anything under the new github workflow, so I don't want to rush it and risk making mistakes. I'm happy if someone else wants to merge it in the meantime.

----------
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 06:54:27 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 20 Mar 2018 10:54:27 +0000
Subject: [issue11566] hypot define in pyconfig.h clashes with g++'s cmath
In-Reply-To: <1300232356.74.0.516279839285.issue11566@psf.upfronthosting.co.za>
Message-ID: <1521543267.18.0.467229070634.issue11566@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11566>
_______________________________________

From report at bugs.python.org  Tue Mar 20 08:16:00 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Mar 2018 12:16:00 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521548159.99.0.467229070634.issue33042@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5914
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Tue Mar 20 08:21:47 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Mar 2018 12:21:47 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521548507.88.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The linked PR has the draft test case for this - it goes beyond the ones I used to find the cause of the problem by actually checking that sys.warnoptions and sys._xoptions have been populated as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:00:01 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 20 Mar 2018 13:00:01 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521550801.49.0.467229070634.issue33034@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The problem with adding a port_validation argument is that the port attribute is not the only thing that is computed lazily. There is also hostname, username, password attributes etc.

I think the best way would be introducing a new API with more strict parsing rules. For example:

    from urllib.parse URL

    url = URL('http://Server=sde; Service=sde:oracle').parse()

would raise a ValueError earlier than urlparse() and return a immutable namedtuple.

Such an API can be designed as a standalone module first and then can be added into the existing urllib.parse module. I'd personally happy to review and discuss such a modern and user friendly API in the standard library.

I think Eric has explained the current situation perfectly and we can now close this issue. We can create a new issue or a new python-ideas thread when or if we have a prototype of a new API.

Thank you, everyone!

----------
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.8 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:06:43 2018
From: report at bugs.python.org (Matt Eaton)
Date: Tue, 20 Mar 2018 13:06:43 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1521551203.85.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Berker and Eric, thank you very much.  I really like the idea of introducing a new API with more strict parsing rules for this situation. I would be willing to put some ideas down on a first pass at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:10:42 2018
From: report at bugs.python.org (Siyuan Ren)
Date: Tue, 20 Mar 2018 13:10:42 +0000
Subject: [issue33107] Feature request: more typing.SupportsXXX
Message-ID: <1521551442.12.0.467229070634.issue33107@psf.upfronthosting.co.za>


New submission from Siyuan Ren <netheril96 at gmail.com>:

Currently in module `typing` we have the following classes

* SupportsInt
* SupportsFloat
* SupportsComplex
* SupportsBytes
* SupportsRound

There is no reason that people only need these classes. They may need, say, `SupportsIndex` to denote all integer like types, `SupportsAdd` for arithmetic types, etc. It is best that the list of `SupportsXXX` are expanded to be as complete as possible, and even better, a mechanism for user specified `SupportsXXX` be provided.

----------
components: Library (Lib)
messages: 314141
nosy: Siyuan Ren
priority: normal
severity: normal
status: open
title: Feature request: more typing.SupportsXXX
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33107>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:22:06 2018
From: report at bugs.python.org (Kiril Dimitrov)
Date: Tue, 20 Mar 2018 13:22:06 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len 2
Message-ID: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>


New submission from Kiril Dimitrov <kiril.dimitroff at gmail.com>:

>>> chr(304)
'?'
>>> chr(304).lower()
'i?'
>>> len(chr(304).lower())
2

This breaks unicode text matching. There is no other unicode character with the same behaviour (in 3.6.2 and 3.6.4).

----------
components: Unicode
messages: 314142
nosy: Kiril Dimitrov, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Unicode char 304 in lowercase has len 2
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:22:23 2018
From: report at bugs.python.org (Kiril Dimitrov)
Date: Tue, 20 Mar 2018 13:22:23 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <1521552143.69.0.467229070634.issue33108@psf.upfronthosting.co.za>


Change by Kiril Dimitrov <kiril.dimitroff at gmail.com>:


----------
title: Unicode char 304 in lowercase has len 2 -> Unicode char 304 in lowercase has len = 2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:28:48 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Mar 2018 13:28:48 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <1521552528.94.0.467229070634.issue33108@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Another example:

>>> s = "?"
>>> len(s)
1
>>> len(s.upper())
2
>>> s.upper()
'SS'
>>> ord(s)
223


> This breaks unicode text matching.

What do you talking about? re module?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:33:38 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 20 Mar 2018 13:33:38 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1521552818.08.0.467229070634.issue33069@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Donald made an interesting suggestion over on https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331, which was to have distutils stop overwriting the Author metadata with the Maintainer metadata when both are specified and instead emit a warning about an unknown keyword argument.

To be honest, that would not have helped in this situation. I didn't encounter this bug in distutils, I encountered it in setuptools, and I tried fixing it in both places because the comments on issue 962772 indicated that this *should* have been supported in distutils.

In the end I think it's fair to either freeze the distutils API and add a DeprecationWarning to indicate that this is no longer supported and everyone should move to setuptools or modernize it completely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Tue Mar 20 09:41:59 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 20 Mar 2018 13:41:59 +0000
Subject: [issue33109] argparse: make new 'required' argument to add_subparsers
 default to False instead of True
Message-ID: <1521553319.23.0.467229070634.issue33109@psf.upfronthosting.co.za>


New submission from Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:

I find the True default for 'required' quite cumbersome introduced as a result of issue 26510.

With existing parsers it can unnecessarily break compatibility between Python3.x versions only to make porting a bit easier for Python2 users.
I think, this late in the life cycle of Python2, within Python3 compatibility should be ranked higher than py2to3 portability.

Command line parsing of a package of mine has long used optional subparsers (without me even thinking much about the fact). Now in 3.7, running

python3.7 -m MyPackage

without arguments (the parser is in __main__.py) I get the ill-formatted error message:

__main__.py: error: the following arguments are required: 

while my code in 3.3 - 3.6 was catching the empty Namespace returned and printed a help message.

Because the 'required' keyword argument did not exist in < 3.7 there was no simple way for me to write code that is compatible between all 3.x versions. What I ended up doing now is to check sys.argv before trying to parse things, then print the help message, when that only has a single item, just to keep my existing code working.

OTOH, everything would be just fine with a default value of False.
Also that truncated error message should be fixed before 3.7 gets released.

----------
components: Library (Lib)
messages: 314145
nosy: Anthony Sottile, bethard, eric.araujo, memeplex, paul.j3, wolma
priority: normal
severity: normal
status: open
title: argparse: make new 'required' argument to add_subparsers default to False instead of True
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33109>
_______________________________________

From report at bugs.python.org  Tue Mar 20 10:18:08 2018
From: report at bugs.python.org (Kiril Dimitrov)
Date: Tue, 20 Mar 2018 14:18:08 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552528.94.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <CAGsu9GbPSf0AkeeGvm8CvWxo5B4pTZ_1qAxuxFueqJ3R=XpwaQ@mail.gmail.com>


Kiril Dimitrov <kiril.dimitroff at gmail.com> added the comment:

This is roughly my use case:
zip( "?x", [0.5, 0.3]) is [('?', 0.5), ('x', 0.3)]
zip("?x".upper(), [0.5, 0.3])  will be [('S', 0.5), ('S', 0.3)] in later
case you never get to see the value for 'x'.

At least my expectation was that lower and upper should preserve text
length. At least this seemed to be the case in python2.7

2018-03-20 15:28 GMT+02:00 INADA Naoki <report at bugs.python.org>:

>
> INADA Naoki <songofacandy at gmail.com> added the comment:
>
> Another example:
>
> >>> s = "?"
> >>> len(s)
> 1
> >>> len(s.upper())
> 2
> >>> s.upper()
> 'SS'
> >>> ord(s)
> 223
>
>
> > This breaks unicode text matching.
>
> What do you talking about? re module?
>
> ----------
> nosy: +inada.naoki
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33108>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Tue Mar 20 11:27:23 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Mar 2018 15:27:23 +0000
Subject: [issue33107] Feature request: more typing.SupportsXXX
In-Reply-To: <1521551442.12.0.467229070634.issue33107@psf.upfronthosting.co.za>
Message-ID: <1521559643.37.0.467229070634.issue33107@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33107>
_______________________________________

From report at bugs.python.org  Tue Mar 20 11:38:02 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 20 Mar 2018 15:38:02 +0000
Subject: [issue33109] argparse: make new 'required' argument to add_subparsers
 default to False instead of True
In-Reply-To: <1521553319.23.0.467229070634.issue33109@psf.upfronthosting.co.za>
Message-ID: <1521560282.75.0.467229070634.issue33109@psf.upfronthosting.co.za>


Anthony Sottile <asottile at umich.edu> added the comment:

The intention of the change in issue 26510 was to pick the least surprising behaviour for the default value of subparsers -- the compatiblity with the behaviour before the regression was introduced in 3.3 was a nice side-effect.  As with the rest of positional arguments in argparse, the positional subparsers were changed to required by default.

The main issue addressing the 3.3 regression I believe is https://bugs.python.org/issue9253 and not the one linked.

When I revived the patch, I surveyed a number of open source tools using subparsers (~10-20) and they all fell into the following categories:

- Used the workaround (part of this SO post: https://stackoverflow.com/a/23354355/812183) (most fell into this category)
- crashed with some sort of TypeError (NoneType has no attribute startswith, KeyeError: None, etc.) due to not handling "optional" subparsers
- Manually handled when the subparser was `None` to raise an argparse error

You can enable a 3.3-3.7 compatible "always optional subparsers" with a similar pattern that was used to manually restore the pre-regression behaviour:

subparsers = parser.add_subparsers(...)
subparsers.required = False

I believe the error message issue is already tracked: https://bugs.python.org/issue29298

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33109>
_______________________________________

From report at bugs.python.org  Tue Mar 20 11:43:10 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 20 Mar 2018 15:43:10 +0000
Subject: [issue33109] argparse: make new 'required' argument to add_subparsers
 default to False instead of True
In-Reply-To: <1521553319.23.0.467229070634.issue33109@psf.upfronthosting.co.za>
Message-ID: <1521560590.66.0.467229070634.issue33109@psf.upfronthosting.co.za>


Anthony Sottile <asottile at umich.edu> added the comment:

Grabbed the wrong SO link, I believe this is the one I meant to link to: https://stackoverflow.com/a/18283730/812183

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33109>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:06:24 2018
From: report at bugs.python.org (Nathan Henrie)
Date: Tue, 20 Mar 2018 16:06:24 +0000
Subject: [issue33036] test_selectors.PollSelectorTestCase failing on macOS
 10.13.3
In-Reply-To: <1520614438.13.0.467229070634.issue33036@psf.upfronthosting.co.za>
Message-ID: <1521561984.32.0.467229070634.issue33036@psf.upfronthosting.co.za>


Nathan Henrie <n8henrie at gmail.com> added the comment:

I've continued looking into this.

If you have your limits configured higher than default, as I did (and which seems to be working fine):

```
sudo launchctl limit maxfiles 64000 524288
ulimit -Sn 64000
```

then you'll find that having a soft limit (`NUM_FDS`, prior to the `-=32`) greater than 10273 causes the error I was seeing.

First, I found this number by passing in NUM_FDS as an envvar to the unittest and looping in a bash script, but I have since extracted some of the relevant portions to a separate python script:

```python
import selectors
import socket
import sys

def main(NUM_FDS):
    s = selectors.PollSelector()

    NUM_FDS -= 32

    sockets = []

    try:
        for i in range(NUM_FDS // 2):
            try:
                rd, wr = socket.socketpair()
                sockets.extend([rd, wr])
            except OSError as e:
                print(f"err 2: {type(e)} {e}")
                # too many FDs, skip - note that we should only catch EMFILE
                # here, but apparently *BSD and Solaris can fail upon connect()
                # or bind() with EADDRNOTAVAIL, so let's be safe
                print("FD limit reached")

            try:
                s.register(rd, selectors.EVENT_READ)
                s.register(wr, selectors.EVENT_WRITE)
            except OSError as e:
                print(f"err 3: {type(e)} {e}")
                if e.errno == errno.ENOSPC:
                    # this can be raised by epoll if we go over
                    # fs.epoll.max_user_watches sysctl
                    print("FD limit reached")
                raise

        try:
            slen = len(s.select())
        except OSError as e:
            print(f"err 4: {type(e)} {e}")
            raise
        print(f"asserting {NUM_FDS // 2} == {slen}")
        assert NUM_FDS // 2 == slen

    finally:
        for sock in sockets:
            sock.close()
        s.close()
        print("Closed")

if __name__ == "__main__":
    main(int(sys.argv[1]))
```


```shellsession
$ ./python.exe tester.py 10273
asserting 5120 == 5120
Closed
$ ./python.exe tester.py 10274
err 4: <class 'OSError'> [Errno 22] Invalid argument
Closed
Traceback (most recent call last):
  File "tester.py", line 50, in <module>
    main(int(sys.argv[1]))
  File "tester.py", line 36, in main
    slen = len(s.select())
  File "cpython/Lib/selectors.py", line 376, in select
    fd_event_list = self._poll.poll(timeout)
OSError: [Errno 22] Invalid argument
```

Tested and confirmed that I can provoke the error with the above launchctl / ulimit settings on my wife's Macbook Air.

I wonder if the 10273 limit I'm running up against has something to do with the 10240 number I keep running into as a default kern.maxfilesperproc (https://unix.stackexchange.com/a/350824/77904), given the `NUM_FDS -= 32` in the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33036>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:12:41 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 20 Mar 2018 16:12:41 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <1521562361.54.0.467229070634.issue33108@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

It has never been the case that upper() or lower() are guaranteed to preserve string length in Unicode. For example, some characters decompose into a base plus combining characters. Ligatures are another example. See here for more details:

https://unicode.org/faq/casemap_charprop.html


However, this example surprises me. In Python 2, I get the result I expected:

py> c = unichr(304)
py> unicodedata.name(c)
'LATIN CAPITAL LETTER I WITH DOT ABOVE'
py> unicodedata.name(c.lower())
'LATIN SMALL LETTER I'


If I am reading the UnicodeData.txt file correctly, I think that the right behaviour is for LATIN CAPITAL LETTER I WITH DOT ABOVE to lowercase to LATIN SMALL LETTER I, as it did in Python 2.

ftp://ftp.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:12:43 2018
From: report at bugs.python.org (Sam Martin)
Date: Tue, 20 Mar 2018 16:12:43 +0000
Subject: [issue33110] Adding a done callback to a concurrent.futures Future
 once it has already completed, may raise an exception, contrary to docs
Message-ID: <1521562363.32.0.467229070634.issue33110@psf.upfronthosting.co.za>


New submission from Sam Martin <nivekkas at gmail.com>:

Whilst working with concurrent.futures and ThreadPoolExecutors, my colleague and I have noted some undocumented behaviour.

When adding a done_callback to a future that has already completed, we note that that callback is executed directly, outside of any try...except statement.  However, both the docs and the _invoke_callbacks methods will wrap any done_callbacks in a try...except statement which logs the result and returns.

Could we either update the documentation to mention that callback behaviour may raise if added to an already completed future, or simply add the same try...except wrapping that the _invoke_callback method already uses please? (Preferably the latter)

The two pieces of the futures library I am referring to can be viewed here:
_invoke_callbacks: https://github.com/python/cpython/blob/master/Lib/concurrent/futures/_base.py#L323

add_done_callback: https://github.com/python/cpython/blob/master/Lib/concurrent/futures/_base.py#L403

I would note, that the test code which covers this area of the code, doesn't currently exercise this particular condition.  The closest test I could find is test_done_callback_already_failed, which checks that a callback can retrieve an exception from a future, but it does not validate what happens when a callback raises when the future it is attached to is already complete.
Source: https://github.com/python/cpython/blob/c3d9508ff22ece9a96892b628dd5813e2fb0cd80/Lib/test/test_concurrent_futures.py#L1012

The other test closely related is test_done_callback_raises, however this doesn't check the behaviour of a callback when added to an already completed future.  We should be able to simulate this by moving the f.set_result line to above the f.add_done_callback lines?

Source: https://github.com/python/cpython/blob/c3d9508ff22ece9a96892b628dd5813e2fb0cd80/Lib/test/test_concurrent_futures.py#L990

----------
components: Library (Lib)
messages: 314151
nosy: samm
priority: normal
severity: normal
status: open
title: Adding a done callback to a concurrent.futures Future once it has already completed, may raise an exception, contrary to docs
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33110>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:25:49 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 20 Mar 2018 16:25:49 +0000
Subject: [issue33109] argparse: make new 'required' argument to add_subparsers
 default to False instead of True
In-Reply-To: <1521560282.75.0.467229070634.issue33109@psf.upfronthosting.co.za>
Message-ID: <a62289f9-cca1-01e5-1bcd-91be291674ef@biologie.uni-freiburg.de>


Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> added the comment:

On 03/20/2018 04:38 PM, Anthony Sottile wrote:
> 
> Anthony Sottile <asottile at umich.edu> added the comment:
> 
> The intention of the change in issue 26510 was to pick the least surprising behaviour for the default value of subparsers -- the compatiblity with the behaviour before the regression was introduced in 3.3 was a nice side-effect.  As with the rest of positional arguments in argparse, the positional subparsers were changed to required by default.
> 

Since the 3.3 change happened a long time ago and has been kept through 
the next three releases, I never considered it a regression, but rather 
thought the original behavior was an oddity of early Python 3s (I've 
never written an argparse-based parser in Python 2), so it's interesting 
to see this in the larger historical context.

Overall, I think "least surprising" is in the eye of the beholder here 
and I want to emphasize that I'm all for your change of adding the 
keyword argument, just not so convinced about your choice of the default.

My main argument for a default of False and against True: having True as 
the default will only lead people used to the Python 2 and pre-3.3 way 
of things to think that they have code working for Python 3, when, in 
fact, that code will break under 3.3-3.6, and, at least, 3.6 will stay 
in widespread use for a long time (even Ubuntu 18.04 will still ship 
with it as the default python3, so Python3.6 will outlast the life cycle 
of Python 2 by a good measure).
Conversely, most projects are dropping Python 3.2 support these days or 
have done so already, so nobody really cares about how things worked in 
this version (I think it's telling along these lines that your - 
corrected - SO link dates back from 2013). So I think, it is
a rather unnecessary incompatibility you are introducing for project 
maintainers even if the original issue was a regression.

> The main issue addressing the 3.3 regression I believe is https://bugs.python.org/issue9253 and not the one linked.
> 
> When I revived the patch, I surveyed a number of open source tools using subparsers (~10-20) and they all fell into the following categories:
> 
> - Used the workaround (part of this SO post: https://stackoverflow.com/a/23354355/812183) (most fell into this category)
> - crashed with some sort of TypeError (NoneType has no attribute startswith, KeyeError: None, etc.) due to not handling "optional" subparsers
> - Manually handled when the subparser was `None` to raise an argparse error

As yet another option, and similar to the third one on your list, I'm 
using the set_defaults method of the subparser, and I'm checking whether 
the corresponding key is present in the Namespace.

> 
> You can enable a 3.3-3.7 compatible "always optional subparsers" with a similar pattern that was used to manually restore the pre-regression behaviour:
> 
> subparsers = parser.add_subparsers(...)
> subparsers.required = False
> 

Ah, right! That's a good option. Didn't realize it would work this way, 
too :)

But a still think you should consider my above argument.

> I believe the error message issue is already tracked: https://bugs.python.org/issue29298
> 

I see, that looks as if it would fix this part. It would be great if it 
could get merged into Python 3.7 still.

> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33109>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33109>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:31:26 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 20 Mar 2018 16:31:26 +0000
Subject: [issue33109] argparse: make new 'required' argument to add_subparsers
 default to False instead of True
In-Reply-To: <1521553319.23.0.467229070634.issue33109@psf.upfronthosting.co.za>
Message-ID: <1521563486.04.0.467229070634.issue33109@psf.upfronthosting.co.za>


Anthony Sottile <asottile at umich.edu> added the comment:

Yeah, I picked the default value `True` because I couldn't actually find a user of subparsers that _wanted_ optional subparsers. ?\_(?)_/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33109>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:39:04 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 20 Mar 2018 16:39:04 +0000
Subject: [issue33107] Feature request: more typing.SupportsXXX
In-Reply-To: <1521551442.12.0.467229070634.issue33107@psf.upfronthosting.co.za>
Message-ID: <1521563944.0.0.467229070634.issue33107@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Such a mechanism exists, and is called Protocols. See PEP 544 (https://www.python.org/dev/peps/pep-0544/). While the PEP is still in draft, it is supported by mypy. You need to import the 'Protocol' base class from typing_extensions (which is a PyPI module, so use `pip install typing_extensions`).

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33107>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:48:40 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Mar 2018 16:48:40 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1521564520.77.0.467229070634.issue25345@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, very strange that only some MSIs are being affected by this error. They no doubt have something in common.

If by clean boot you mean reinstalling Windows, then yes, that fixes most issues, but it is pretty drastic :)

I don't actually have any good recommendations for fixing Windows Installer problems... there used to be a troubleshooting tool available, but I'm not sure where it's gone. All the best advice I can find online these days basically just says to reinstall, but you could try System Restore first (and it may even help to create a new restore point and then restore to it - I suspect that will reset some state without losing anything you installed recently).

Without full access to your machine and much better installer diagnostic skills than I have there's nothing else I can offer, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Tue Mar 20 12:54:18 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 20 Mar 2018 16:54:18 +0000
Subject: [issue33109] argparse: make new 'required' argument to add_subparsers
 default to False instead of True
In-Reply-To: <1521553319.23.0.467229070634.issue33109@psf.upfronthosting.co.za>
Message-ID: <1521564858.98.0.467229070634.issue33109@psf.upfronthosting.co.za>


Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> added the comment:

_wants_ is a bit a strong word, but, at least, you can do a bit a nicer job than the default error, like printing a nicely formatted list of subcommands as you would get it with the main parsers help.
In fact, in my own code I'm actually catching the missing subparser situation, then calling parse_args again with ['--help'] :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33109>
_______________________________________

From report at bugs.python.org  Tue Mar 20 13:23:46 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 20 Mar 2018 17:23:46 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521566626.54.0.467229070634.issue28247@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests: +5915

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 13:25:24 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 20 Mar 2018 17:25:24 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521566724.22.0.467229070634.issue28247@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Paul,

Thanks for your response.  I've made the pull request from your patch, so it would great if you could review it.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 14:48:09 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Mar 2018 18:48:09 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521571689.05.0.467229070634.issue33021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening for 3.x backports, as per Robert's advice.

----------
status: closed -> open
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Tue Mar 20 14:51:07 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 18:51:07 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521571867.29.0.467229070634.issue33021@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5916
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Tue Mar 20 14:51:43 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 18:51:43 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521571903.77.0.467229070634.issue33021@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5917

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Tue Mar 20 15:16:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Mar 2018 19:16:33 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521573393.1.0.467229070634.issue33021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 56cce1ca84344f519f7ed01024434c083031d354 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-33021: Release the GIL during fstat() calls (GH-6019) (GH-6159)
https://github.com/python/cpython/commit/56cce1ca84344f519f7ed01024434c083031d354


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Tue Mar 20 15:20:56 2018
From: report at bugs.python.org (Ethan Welty)
Date: Tue, 20 Mar 2018 19:20:56 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
Message-ID: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>


New submission from Ethan Welty <ethan.welty at gmail.com>:

Merely importing tkinter breaks the use of parallel code on my system (Mac OSX 10.11.6, tested on Python 2.7.13 / 2.7.14 / 3.5.0 / 3.6.4, all barebones distributions installed with pyenv). I've tested this with both multiprocessing and sharedmem (see minimal scripts below).

The issue seems to apply only to functions that evoke multithreading within their respective package (e.g. `numpy.matmul()`, `cv2.SIFT.detectAndCompute()`). If I make the matrix in the scripts below much smaller (e.g. change `5000` to `5`), avoiding internal multithreading, the scripts work.

## with `multiprocessing`

```python
import numpy as np
import multiprocessing
import _tkinter

def parallel_matmul(x):
    R = np.random.randn(3, 3)
    return np.matmul(R, x)

pool = multiprocessing.Pool(4)
results = pool.map(parallel_matmul, [np.random.randn(3, 5000) for i in range(2)])
```

> *Code never exits and Python has to be force quit*

## with `sharedmem`

```python
import numpy as np
import sharedmem
import _tkinter

def parallel_matmul(x):
    R = np.random.randn(3, 3)
    return np.matmul(R, x)

with sharedmem.MapReduce() as pool:
    results = pool.map(parallel_matmul,
        [np.random.randn(3, 5000) for i in range(2)])
```

> sharedmem.sharedmem.SlaveException: slave process 1 killed by signal 11

----------
components: Tkinter
messages: 314160
nosy: ezwelty
priority: normal
severity: normal
status: open
title: Merely importing tkinter breaks parallel code (multiprocessing, sharedmem)
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Tue Mar 20 15:23:50 2018
From: report at bugs.python.org (Ethan Welty)
Date: Tue, 20 Mar 2018 19:23:50 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521573830.59.0.467229070634.issue33111@psf.upfronthosting.co.za>


Change by Ethan Welty <ethan.welty at gmail.com>:


----------
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Tue Mar 20 15:40:20 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Mar 2018 19:40:20 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521574820.72.0.467229070634.issue33021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset f3e6eadbcf4f3e0fe53f4784485b1c8464c7d282 by Antoine Pitrou (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-33021: Release the GIL during fstat() calls (GH-6019) (GH-6160)
https://github.com/python/cpython/commit/f3e6eadbcf4f3e0fe53f4784485b1c8464c7d282


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Tue Mar 20 15:40:42 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Mar 2018 19:40:42 +0000
Subject: [issue33021] Some fstat() calls do not release the GIL,
 possibly hanging all threads
In-Reply-To: <1520463804.4.0.467229070634.issue33021@psf.upfronthosting.co.za>
Message-ID: <1521574842.84.0.467229070634.issue33021@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33021>
_______________________________________

From report at bugs.python.org  Tue Mar 20 15:45:29 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Mar 2018 19:45:29 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521575129.62.0.467229070634.issue33082@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't really agree that "callbacks are really important in multiprocessing" (I think I've hardly ever used them).  I agree with the other doc changes in the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Tue Mar 20 16:09:08 2018
From: report at bugs.python.org (Martin)
Date: Tue, 20 Mar 2018 20:09:08 +0000
Subject: [issue33112] SequenceMatcher bug
Message-ID: <1521576548.54.0.467229070634.issue33112@psf.upfronthosting.co.za>


New submission from Martin <martt at dtu.dk>:

difflib.SequenceMatcher fails to make a proper alignment between 2 sequences with only 3 single letter changes. Its performance is completely off with a similarity ratio of 0.16, in stead of the more accurate 0.99.

Here is a snippet to replicate the failure:
>>> aa_ref = 'MTLFTTLLVLIFERLFKLGEHWQLDHRLEAFFRRVKHFSLGRTLGMTIIAMGVTFLLLRALQGVLFNVPTLLVWLLIGLLCIGAGKVRLHYHAYLTAASRNDSHARATMAGELTMIHGVPAGCDEREYLRELQNALLWINFRFYLAPLFWLIVGGTWGPVTLMGYAFLRAWQYWLARYQTPHHRLQSGIDAVLHVLDWVPVRLAGVVYALIGHGEKALPAWFASLGDFHTSQYQVLTRLAQFSLAREPHVDKVETPKAAVSMAKKTSFVVVVVIALLTIYGALV'
>>> aa_seq = 'MTLFTTLLVLIFERLFKLGEHWQLDHRLEAFFRRVKHFSLGRTLCMTIIAMGVTFLLLRALQGVLFNVPTLLVWLLIGLLCIGAGKVRLHYHAYLTAASRNDSHAHATMAGELTMIHGVPAGCDEREYLRELQNALLWINFRFYLAPLFWLIVGGTWGPVTLMGYAFLRAWQYWLARYQTPHHRLQSGIDAVLHALDWVPVRLAGVVYALIGHGEKALPAWFASLGDFHTSQYQVLTRLAQFSLAREPHVDKVETPKAAVSMAKKTSFVVVVVIALLTIYGALV'
>>> sum(a!=b for a, b in zip(aa_ref, aa_seq))
3
>>> match = SequenceMatcher(a=aa_ref, b=aa_seq)
>>> match.ratio()
0.1619718309859155
>>> match.get_opcodes()
[('equal', 0, 43, 0, 43), ('delete', 43, 79, 43, 43), ('equal', 79, 81, 43, 45), ('replace', 81, 122, 45, 80), ('equal', 122, 123, 80, 81), ('replace', 123, 284, 81, 284)]

----------
messages: 314163
nosy: mcft
priority: normal
severity: normal
status: open
title: SequenceMatcher bug
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33112>
_______________________________________

From report at bugs.python.org  Tue Mar 20 16:20:53 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 20 Mar 2018 20:20:53 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1521577253.44.0.467229070634.issue27212@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Nofar,

Are you still interested in working on this issue?  Thanks!

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Tue Mar 20 16:35:51 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 20 Mar 2018 20:35:51 +0000
Subject: [issue33112] SequenceMatcher bug
In-Reply-To: <1521576548.54.0.467229070634.issue33112@psf.upfronthosting.co.za>
Message-ID: <1521578151.55.0.467229070634.issue33112@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Please see the response to issue31889.  Short course:  you need to pass `autojunk=False` to the SequenceMatcher constructor.

----------
nosy: +tim.peters
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33112>
_______________________________________

From report at bugs.python.org  Tue Mar 20 17:47:51 2018
From: report at bugs.python.org (Adrian Stachlewski)
Date: Tue, 20 Mar 2018 21:47:51 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521582471.34.0.467229070634.issue33094@psf.upfronthosting.co.za>


Adrian Stachlewski <adrian.stachlewski at gmail.com> added the comment:

There's nothing to do, thanks for help one more again.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Tue Mar 20 17:49:34 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Mar 2018 21:49:34 +0000
Subject: [issue33094] dataclasses: ClassVar attributes are not working properly
In-Reply-To: <1521327830.3.0.467229070634.issue33094@psf.upfronthosting.co.za>
Message-ID: <1521582574.18.0.467229070634.issue33094@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33094>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:00:54 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 20 Mar 2018 22:00:54 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521583254.79.0.467229070634.issue33018@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I am still -1 on changing this in Python 3.7, unless Guido wants this in 3.7, if yes, then we can go ahead. Otherwise, I think we can consider just merging this into master, in this case I would switch to the PR to discuss the details.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:04:41 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 20 Mar 2018 22:04:41 +0000
Subject: [issue33077] typing: Unexpected result with value of instance of
 class inherited from typing.NamedTuple
In-Reply-To: <1521066290.44.0.467229070634.issue33077@psf.upfronthosting.co.za>
Message-ID: <1521583480.99.0.467229070634.issue33077@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Would it be worthwhile to show an example of a subclass that overrides or extends  __new__?

I think yes. I would actually add few examples what could (and maybe also couldn't) be done with named tuples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33077>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:05:27 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Mar 2018 22:05:27 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521583527.51.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Are you by any chance trying to run this under IDLE?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:07:52 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 20 Mar 2018 22:07:52 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521583672.18.0.467229070634.issue33061@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I think it makes sense to also fix this in 3.7. I will prepare a backport now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:17:35 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 20 Mar 2018 22:17:35 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521584255.45.0.467229070634.issue33061@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
pull_requests: +5918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:23:21 2018
From: report at bugs.python.org (Paul Moore)
Date: Tue, 20 Mar 2018 22:23:21 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521584601.43.0.467229070634.issue28247@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:


New changeset 4be79f29463f632cd8b48486feadc2ed308fb520 by Paul Moore (Cheryl Sabella) in branch 'master':
bpo-28247: Document Windows executable creation in zipapp (GH-6158)
https://github.com/python/cpython/commit/4be79f29463f632cd8b48486feadc2ed308fb520


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:24:40 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 22:24:40 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521584680.53.0.467229070634.issue28247@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5919

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:25:30 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 22:25:30 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521584730.72.0.467229070634.issue28247@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5920

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:44:23 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 22:44:23 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521585863.86.0.467229070634.issue28247@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a70b8f593657f563116001f654587620271eb9ae by Miss Islington (bot) in branch '3.7':
bpo-28247: Document Windows executable creation in zipapp (GH-6158)
https://github.com/python/cpython/commit/a70b8f593657f563116001f654587620271eb9ae


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 18:52:43 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 20 Mar 2018 22:52:43 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521586363.9.0.467229070634.issue28247@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 47a0e64ccf711e8d6d0c497d565ca7e2e82de7d4 by Miss Islington (bot) in branch '3.6':
bpo-28247: Document Windows executable creation in zipapp (GH-6158)
https://github.com/python/cpython/commit/47a0e64ccf711e8d6d0c497d565ca7e2e82de7d4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:09:18 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Mar 2018 00:09:18 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1521590958.43.0.467229070634.issue18802@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 5609b78392d59c7362ef8aa5c4a4529325f01f27 by Xiang Zhang (Cheryl Sabella) in branch 'master':
 bpo-18802: Add more details to ipaddress documentation (GH-6083)
https://github.com/python/cpython/commit/5609b78392d59c7362ef8aa5c4a4529325f01f27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:10:42 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 00:10:42 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1521591042.83.0.467229070634.issue18802@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5921

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:11:26 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 00:11:26 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1521591086.69.0.467229070634.issue18802@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5922

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:25:15 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Mar 2018 00:25:15 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1521591915.3.0.467229070634.issue27683@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 10b134a07c898c2fbc5fd3582503680a54ed80a2 by Xiang Zhang in branch 'master':
bpo-27683: Fix a regression for host() of ipaddress network objects (GH-6016)
https://github.com/python/cpython/commit/10b134a07c898c2fbc5fd3582503680a54ed80a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27683>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:26:23 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 00:26:23 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1521591983.04.0.467229070634.issue27683@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5923

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27683>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:27:22 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 00:27:22 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1521592042.81.0.467229070634.issue27683@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5924

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27683>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:30:45 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 00:30:45 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1521592245.69.0.467229070634.issue18802@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a323eee4c481c88f2b4030bbb224d9bc6bc14c9c by Miss Islington (bot) in branch '3.7':
bpo-18802: Add more details to ipaddress documentation (GH-6083)
https://github.com/python/cpython/commit/a323eee4c481c88f2b4030bbb224d9bc6bc14c9c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:50:47 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 00:50:47 +0000
Subject: [issue32896] Error when subclassing a dataclass with a field that
 uses a defaultfactory
In-Reply-To: <1519230106.01.0.467229070634.issue32896@psf.upfronthosting.co.za>
Message-ID: <1521593447.86.0.467229070634.issue32896@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
priority: deferred blocker -> release blocker
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32896>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:52:04 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 00:52:04 +0000
Subject: [issue32896] Error when subclassing a dataclass with a field that
 uses a defaultfactory
In-Reply-To: <1519230106.01.0.467229070634.issue32896@psf.upfronthosting.co.za>
Message-ID: <1521593524.08.0.467229070634.issue32896@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5925
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32896>
_______________________________________

From report at bugs.python.org  Tue Mar 20 20:59:03 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 00:59:03 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1521593943.32.0.467229070634.issue18802@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 481cbe8d6202658a7908d97f19f7e9e6061e3df3 by Miss Islington (bot) in branch '3.6':
bpo-18802: Add more details to ipaddress documentation (GH-6083)
https://github.com/python/cpython/commit/481cbe8d6202658a7908d97f19f7e9e6061e3df3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Tue Mar 20 21:22:27 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 01:22:27 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1521595347.91.0.467229070634.issue27683@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3326c9267f9df15fa77094b8a740be4eaa4b9374 by Miss Islington (bot) in branch '3.7':
bpo-27683: Fix a regression for host() of ipaddress network objects (GH-6016)
https://github.com/python/cpython/commit/3326c9267f9df15fa77094b8a740be4eaa4b9374


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27683>
_______________________________________

From report at bugs.python.org  Tue Mar 20 21:31:47 2018
From: report at bugs.python.org (Tim Peters)
Date: Wed, 21 Mar 2018 01:31:47 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1521595907.31.0.467229070634.issue33083@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

factorial(float) was obviously intended to work the way it does, so I'd leave it alone in whatever changes are made to resolve _this_ issue.  I view it as a harmless-enough quirk, but, regardless, if people want to deprecate it that should be a different issue.

What the code ends up doing for Decimal and Fraction and god-only-knows-what-else is just as obviously confused.  So clean that up and declare victory ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Tue Mar 20 21:37:17 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Mar 2018 01:37:17 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1521583254.79.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJkQ7N68rFNQvBw2vgXkd+Mnp+ru0=GeUue67U=Ps++Pg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

While we're in feature freeze mode, we're not in release candidate mode
yet. I presume the code that would be patched in 3.7 is no different from
master? What's the concern? It doesn't seem anyone thinks it's risky?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Tue Mar 20 21:49:44 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 01:49:44 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1521596984.26.0.467229070634.issue27683@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ae2feb32e7eff328199ce7d527593b3c2aa1fcab by Miss Islington (bot) in branch '3.6':
bpo-27683: Fix a regression for host() of ipaddress network objects (GH-6016)
https://github.com/python/cpython/commit/ae2feb32e7eff328199ce7d527593b3c2aa1fcab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27683>
_______________________________________

From report at bugs.python.org  Tue Mar 20 21:57:16 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Mar 2018 01:57:16 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1521597436.24.0.467229070634.issue18802@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/issue18802>
_______________________________________

From report at bugs.python.org  Tue Mar 20 21:58:25 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Mar 2018 01:58:25 +0000
Subject: [issue27683] ipaddress subnet slicing iterator malfunction
In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>
Message-ID: <1521597505.19.0.467229070634.issue27683@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27683>
_______________________________________

From report at bugs.python.org  Tue Mar 20 22:00:26 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 02:00:26 +0000
Subject: [issue32896] Error when subclassing a dataclass with a field that
 uses a defaultfactory
In-Reply-To: <1519230106.01.0.467229070634.issue32896@psf.upfronthosting.co.za>
Message-ID: <1521597626.31.0.467229070634.issue32896@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 8f6eccdc64cab735c47620fea948e64b19f83684 by Eric V. Smith in branch 'master':
bpo-32896: Fix error when subclassing a dataclass with a field that uses a default_factory (GH-6170)
https://github.com/python/cpython/commit/8f6eccdc64cab735c47620fea948e64b19f83684


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32896>
_______________________________________

From report at bugs.python.org  Tue Mar 20 22:01:50 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 02:01:50 +0000
Subject: [issue32896] Error when subclassing a dataclass with a field that
 uses a defaultfactory
In-Reply-To: <1519230106.01.0.467229070634.issue32896@psf.upfronthosting.co.za>
Message-ID: <1521597710.68.0.467229070634.issue32896@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5926

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32896>
_______________________________________

From report at bugs.python.org  Tue Mar 20 22:14:00 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Mar 2018 02:14:00 +0000
Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an
 IPv4 /32
In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za>
Message-ID: <1521598440.14.0.467229070634.issue28577@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I fixed #27683 since it looks more like an oversight and regression to me instead of a deliberate change. I'd like the behaviour to be consistent across versions. As for "/32", it needs discussion or some expert makes a choice.

----------
resolution: not a bug -> 
stage: resolved -> 
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28577>
_______________________________________

From report at bugs.python.org  Tue Mar 20 22:14:13 2018
From: report at bugs.python.org (kyuupichan)
Date: Wed, 21 Mar 2018 02:14:13 +0000
Subject: [issue33093] Fatal error on SSL transport
In-Reply-To: <1521308170.69.0.467229070634.issue33093@psf.upfronthosting.co.za>
Message-ID: <1521598453.58.0.467229070634.issue33093@psf.upfronthosting.co.za>


kyuupichan <kyuupichan at gmail.com> added the comment:

Looks like https://bugs.python.org/issue33037

----------
nosy: +kyuupichan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33093>
_______________________________________

From report at bugs.python.org  Tue Mar 20 22:18:34 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 21 Mar 2018 02:18:34 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521598714.37.0.467229070634.issue33018@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

If there are some code which depend on ABC.__subclasscheck__() allow class-like object, we'll have to revert it in 3.7b4 or rc.
I think it's the only risk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Tue Mar 20 23:11:59 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 21 Mar 2018 03:11:59 +0000
Subject: [issue32941] mmap should expose madvise()
In-Reply-To: <1519506923.52.0.467229070634.issue32941@psf.upfronthosting.co.za>
Message-ID: <1521601919.11.0.467229070634.issue32941@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +5927
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32941>
_______________________________________

From report at bugs.python.org  Wed Mar 21 00:33:12 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Mar 2018 04:33:12 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1521598714.37.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJmQCNh-JK2pRkChfE64+HF+pG1OPso-nPq7hf5dz+wYQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Hmm... That is actually a not entirely imaginary risk, right? Can you come
up with a test program that would fail that way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Wed Mar 21 02:28:15 2018
From: report at bugs.python.org (guohui)
Date: Wed, 21 Mar 2018 06:28:15 +0000
Subject: [issue33113] Query performance is very low and can even lead to
 denial of service
Message-ID: <1521613695.07.0.467229070634.issue33113@psf.upfronthosting.co.za>


New submission from guohui <ghi5107 at 126.com>:

I found a issue in regex (findall search)function, when seaching some content by some pattern, the function return for a long long time, match performance is very low.
I think this issue could lead to too low query performance, or a attacker may exploit the issue to cause a denail of service condition.


system:  python 2.7.14  regex(2018.2.21)
poc:

import re
pat = r'^(\(?[\w\d\-\.\\]{3,}\|?){1,}[\w\d\-\.\\]{3,}\)?$'
#plaintext content
content = r'(ftp\x3a\x2f\x2f|http\x3a\x2f\x2f|https\x3a\x2f\x2f|c\x3a\x2f\x2f|d\x3a\x2f\x2f|e\x3a\x2f\x2f)a'
result = re.findall(pat, content)
print result

----------
components: Regular Expressions
files: test_performance.py
messages: 314187
nosy: ezio.melotti, ghi5107, mrabarnett
priority: normal
severity: normal
status: open
title: Query performance is very low and can even lead to denial of service
type: security
versions: Python 2.7
Added file: https://bugs.python.org/file47495/test_performance.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33113>
_______________________________________

From report at bugs.python.org  Wed Mar 21 04:52:06 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Mar 2018 08:52:06 +0000
Subject: [issue33113] Query performance is very low and can even lead to
 denial of service
In-Reply-To: <1521613695.07.0.467229070634.issue33113@psf.upfronthosting.co.za>
Message-ID: <1521622326.31.0.467229070634.issue33113@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33113>
_______________________________________

From report at bugs.python.org  Wed Mar 21 05:22:08 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 09:22:08 +0000
Subject: [issue32896] Error when subclassing a dataclass with a field that
 uses a defaultfactory
In-Reply-To: <1519230106.01.0.467229070634.issue32896@psf.upfronthosting.co.za>
Message-ID: <1521624128.32.0.467229070634.issue32896@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 22136c94b6e43c8c584a54f3a513b83b753b96ee by Eric V. Smith (Miss Islington (bot)) in branch '3.7':
bpo-32896: Fix error when subclassing a dataclass with a field that uses a default_factory (GH-6170) (GH-6171)
https://github.com/python/cpython/commit/22136c94b6e43c8c584a54f3a513b83b753b96ee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32896>
_______________________________________

From report at bugs.python.org  Wed Mar 21 05:23:12 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 09:23:12 +0000
Subject: [issue32896] Error when subclassing a dataclass with a field that
 uses a defaultfactory
In-Reply-To: <1519230106.01.0.467229070634.issue32896@psf.upfronthosting.co.za>
Message-ID: <1521624192.43.0.467229070634.issue32896@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks again for the bug report. This ended up being a simple fix, but an important one.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32896>
_______________________________________

From report at bugs.python.org  Wed Mar 21 05:24:43 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 09:24:43 +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: <1521624283.44.0.467229070634.issue32506@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.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/issue32506>
_______________________________________

From report at bugs.python.org  Wed Mar 21 07:03:48 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Mar 2018 11:03:48 +0000
Subject: [issue23239] SSL match_hostname does not accept IP Address
In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za>
Message-ID: <1521630228.8.0.467229070634.issue23239@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

#32819 and #32185 have solved the last outstanding bugs with IP address validation and handling. I'm fine with a backport of the feature to 2.7 now.

----------
assignee: christian.heimes -> 
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23239>
_______________________________________

From report at bugs.python.org  Wed Mar 21 07:44:05 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 21 Mar 2018 11:44:05 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521632645.98.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm fairly sure this is expected behavior on macOS: _tkinter loads the Tk library, which loads Apple GUI frameworks. Those frameworks are not save w.r.t. fork(2) and that can lead to all kinds of unwanted behavior (although I would have expected a more explicit crash than this)

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Wed Mar 21 08:02:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Mar 2018 12:02:27 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521633747.74.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Adding the other import system maintainers to the nosy list, along with Ned as the release manager for 3.6 and 3.7)

Summarizing my current thoughts on this:

I think the fact that "-m" currently adds the empty directory as sys.path[0] instead of the fully resolved cwd is definitely worth changing for 3.8, and is at least arguably a bugfix that should be applied to 3.7 prior to release. (It's probably too late in 3.6's lifecycle to be worth backporting that far, even if we do reclassify this part as a bugfix instead of an enhancement)

The above is what I consider to be in scope for *this* particular issue.

(The details of the current behaviour probably arose from my borrowing an existing code path originally designed for "-c" rather than from a deliberate design decision)



As a separate question, I'd personally be open to the idea of:

1. Deprecating the implicit addition of the current working directory to sys.path (and have that emit a deprecation warning in 3.8)

2. Add support for an explicit leading dot on "-m" arguments to say "Run this from the current directory" (the -m switch was added in 2.4, while the explicit relative import syntax wasn't chosen until 2.5, so this wasn't an available option for the original feature design). Note: given implicit namespace packages, it may make sense to allow additional leading dots in order to add a parent directory to sys.path instead of the current directory.

3. Add a "--basepath <dir>" argument to have "-m" resolve explicit relative imports against a directory other than the current one (this would be a different potential spelling for https://bugs.python.org/issue13475 )

4. Once the current directory is no longer added implicitly (in 3.9 at the earliest), if runpy fails to find the main module, then check the current directory and ask "Did you mean '.name'?" in the error message.

However, that second part is the part I consider out of scope for this issue, and think would require a PEP due to the backwards compatibility challenges.

----------
nosy: +brett.cannon, eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Wed Mar 21 08:12:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Mar 2018 12:12:51 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
 sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1521634371.02.0.467229070634.issue13475@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Over in https://bugs.python.org/issue33053#msg314192, I came up with `--basepath <dir>` as another possible spelling (`--no-basepath` would then be an option for turning it off.

The main argument *against* that name is that we use "base" to mean something different in the `sys` module: "base_prefix" and "base_exec_prefix" refer to the info for the parent environment when in a virtual environment.

Another alternative would be "--mainpath", since what we're really overriding is the default path entry that's normally derived from the location of `__main__`. As an added bonus, we could define "main path" as a glossary entry, rather than having to talk about "sys dot path zero" all the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Wed Mar 21 08:26:54 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 21 Mar 2018 12:26:54 +0000
Subject: [issue13475] Add '-p'/'--path0' command line option to override
 sys.path[0] initialisation
In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>
Message-ID: <1521635214.02.0.467229070634.issue13475@psf.upfronthosting.co.za>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13475>
_______________________________________

From report at bugs.python.org  Wed Mar 21 08:43:27 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 21 Mar 2018 12:43:27 +0000
Subject: [issue28247] Add an option to zipapp to produce a Windows executable
In-Reply-To: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>
Message-ID: <1521636207.97.0.467229070634.issue28247@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28247>
_______________________________________

From report at bugs.python.org  Wed Mar 21 09:06:35 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Mar 2018 13:06:35 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521637595.52.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thinking about PySys_AddWarnOptionUnicode a little further, I'm not sure we actually need to change anything in the implementation there - I think we can just make it clearer in the docs that *only* PySys_AddWarnOption is supported prior to Py_Initialize for the embedding use case - the unicode version of the API currently only makes sense in CPython, where we can call it after _Py_InitializeCore.

It will make sense for embedding applications in 3.8 once we make Py_InitializeCore a public API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Wed Mar 21 09:21:16 2018
From: report at bugs.python.org (AmjadHD)
Date: Wed, 21 Mar 2018 13:21:16 +0000
Subject: [issue33103] Syntax to get multiple arbitrary items from an iterable
In-Reply-To: <1521466579.3.0.467229070634.issue33103@psf.upfronthosting.co.za>
Message-ID: <1521638476.31.0.467229070634.issue33103@psf.upfronthosting.co.za>


AmjadHD <amjadbenhedhili at outlook.com> added the comment:

Yes that's a way to do it but "a, b, c = my_list[1, 3, -1]" seems so pythonic and straight forward, it's like formatting, python had already 3 methods to do it when it introduced a 4th one (f-strings), easier is better especially in python.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33103>
_______________________________________

From report at bugs.python.org  Wed Mar 21 09:36:54 2018
From: report at bugs.python.org (Arran McCutcheon)
Date: Wed, 21 Mar 2018 13:36:54 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1521639414.3.0.467229070634.issue25345@psf.upfronthosting.co.za>


Arran McCutcheon <arran-m at hotmail.com> added the comment:

No problem Steve, I found the solution! I downloaded 'Windows Repair' from tweaking.com, and then used it to repair only the MSI installer. So I've now installed Python correctly. Thanks again for your help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25345>
_______________________________________

From report at bugs.python.org  Wed Mar 21 09:40:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Mar 2018 13:40:52 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1521639652.23.0.467229070634.issue15248@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is possible to make the compiler producing warnings for such kind of errors. The following sample patch does this. I'm not sure it is worth to do.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Wed Mar 21 09:41:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Mar 2018 13:41:21 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1521639681.01.0.467229070634.issue15248@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file47496/compile-warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Wed Mar 21 10:33:36 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Mar 2018 14:33:36 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <CAP7+vJJmQCNh-JK2pRkChfE64+HF+pG1OPso-nPq7hf5dz+wYQ@mail.gmail.com>
Message-ID: <CAP7+vJK11yM-MXqHh0DrFQYf=eqqSDHFa3qBwdooSdmAveVASw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

OTOH if we don't do this now, it's not going to be any easier to make this
change in 3.8. Maybe now's the time to experiment with it, and we can drop
it in rc1 if it causes problems. @Ivan, your thoughts? Would you merge this
into master?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Wed Mar 21 10:41:23 2018
From: report at bugs.python.org (AmjadHD)
Date: Wed, 21 Mar 2018 14:41:23 +0000
Subject: [issue33102] get the nth folder of a given path
In-Reply-To: <1521465956.78.0.467229070634.issue33102@psf.upfronthosting.co.za>
Message-ID: <1521643283.55.0.467229070634.issue33102@psf.upfronthosting.co.za>


AmjadHD <amjadbenhedhili at outlook.com> added the comment:

Yes but i dont know if this is cross platform solution, i guess this function should be in the os.path module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33102>
_______________________________________

From report at bugs.python.org  Wed Mar 21 10:51:24 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 14:51:24 +0000
Subject: [issue33102] get the nth folder of a given path
In-Reply-To: <1521465956.78.0.467229070634.issue33102@psf.upfronthosting.co.za>
Message-ID: <1521643884.91.0.467229070634.issue33102@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Yes, it's cross platform.

For a plain string version, you can use a utility function:

>>> for i in range(n+1):
...   path = os.path.dirname(path)
...

I'm not sure it's worth adding this to os.path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33102>
_______________________________________

From report at bugs.python.org  Wed Mar 21 10:52:57 2018
From: report at bugs.python.org (Scott Eilerman)
Date: Wed, 21 Mar 2018 14:52:57 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
Message-ID: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>


New submission from Scott Eilerman <scott.j.eilerman at gmail.com>:

I ran into a "bug" when using random.sample() in which I got some results I didn't expect. After digging a little more, this is either a side effect of  the optimization that's made when k > 5, or I am using the function in a way that wasn't intended. If that's the case, I would recommend calling out this behavior in the documentation.

The crux of the issue is that, for a given seed, random.sample(choices,k) gives the same sequence of results for k=1 to k=5, but that sequence can be different (for the same seed) at k=6 and higher. From my initial testing this seems to only occur when 'choices' has an even length.

Example code to reproduce this issue:

import random
seed = 199
choices = range(-10,12)

for k in range(10):
    random.seed(seed)
    print(random.sample(choices,k))


Example code to look at many different occurrences of this issue:

import random
choices = range(-10,12)
count = 0
for seed in range(200):
    for k in range(8):
        random.seed(seed)
        seq1 = random.sample(choices, k)
        random.seed(seed)
        seq2 = random.sample(choices, k+1)
        if seq1 != seq2[:-1]:
            print(seed)
            print(seq1)
            print(seq2)
            count += 1
print(f'Number of bugged results: {count}/200')


To illustrate the odd/even issue, changing choices to range(-10,11) results in zero bugged results.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 314201
nosy: Scott Eilerman, docs at python
priority: normal
severity: normal
status: open
title: random.sample() behavior is unexpected/unclear from docs
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:17:33 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Mar 2018 15:17:33 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1521645453.87.0.467229070634.issue33114@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What additional wording do you propose?

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:21:37 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Mar 2018 15:21:37 +0000
Subject: [issue33103] Syntax to get multiple arbitrary items from an sequence
In-Reply-To: <1521466579.3.0.467229070634.issue33103@psf.upfronthosting.co.za>
Message-ID: <1521645697.21.0.467229070634.issue33103@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please leave this closed -- there is no chance that this will go forward on the bug tracker.  It would first need to be thoroughly discussed on the python-ideas mail list.

----------
status: open -> closed
title: Syntax to get multiple arbitrary items from an iterable -> Syntax to get multiple arbitrary items from an sequence
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33103>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:22:31 2018
From: report at bugs.python.org (Scott Eilerman)
Date: Wed, 21 Mar 2018 15:22:31 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1521645751.34.0.467229070634.issue33114@psf.upfronthosting.co.za>


Scott Eilerman <scott.j.eilerman at gmail.com> added the comment:

Something along the lines of: "For a fixed seed, random.sample(population, k) is not guaranteed to return the same samples for different values of k."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:26:54 2018
From: report at bugs.python.org (Scott Eilerman)
Date: Wed, 21 Mar 2018 15:26:54 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1521646014.27.0.467229070634.issue33114@psf.upfronthosting.co.za>


Scott Eilerman <scott.j.eilerman at gmail.com> added the comment:

To clarify the use case where this behavior was problematic for me, I wanted to get the nth random draw from a given distribution, so I used something like:

random.seed(fixed_seed)
random.sample(choices, n)[-1]

Then, later, I want the next draw, so I did:

random.seed(fixed_seed)
random.sample(choices, n)[-1]


The workaround would be to use random.shuffle and pick the nth item, or use random.sample once with the highest k value I expect to need and then pick the nth element from that list. But I settled on the above implementation because for the first few cases I tested, it returned the results I expected, and nothing in the docs suggested I should expect otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:31:08 2018
From: report at bugs.python.org (Scott Eilerman)
Date: Wed, 21 Mar 2018 15:31:08 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1521646268.75.0.467229070634.issue33114@psf.upfronthosting.co.za>


Scott Eilerman <scott.j.eilerman at gmail.com> added the comment:

Sorry, there's a typo in that example. It should look like:


random.seed(fixed_seed)
random.sample(choices, n)[-1]

Then, later, I want the next draw, so I did:

random.seed(fixed_seed)
random.sample(choices, n+1)[-1]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:48:58 2018
From: report at bugs.python.org (Marat Sharafutdinov)
Date: Wed, 21 Mar 2018 15:48:58 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
Message-ID: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>


New submission from Marat Sharafutdinov <decaz89 at gmail.com>:

I want to schedule a lot of parallel tasks, but it becomes slow with loop blocking:

```python
import asyncio

task_count = 10000

async def main():
    for x in range(1, task_count + 1):
        asyncio.ensure_future(f(x))

async def f(x):
    if x % 1000 == 0 or x == task_count:
        print(f'Run f({x})')
    await asyncio.sleep(1)
    loop.call_later(1, lambda: asyncio.ensure_future(f(x)))

loop = asyncio.get_event_loop()
loop.set_debug(True)
loop.run_until_complete(main())
loop.run_forever()
```

Outputs:
```
Executing <Task finished coro=<main() done, defined at test_aio.py:5> result=None created at /usr/lib/python3.6/asyncio/base_events.py:446> took 0.939 seconds

...

Executing <TimerHandle when=1841384.785427177 _set_result_unless_cancelled(<Future finis...events.py:275>, None) at /usr/lib/python3.6/asyncio/futures.py:339 created at /usr/lib/python3.6/asyncio/tasks.py:480> took 0.113 seconds

...

Executing <Task pending coro=<f() running at test_aio.py:12> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7fe89344fcd8>()] created at /usr/lib/python3.6/asyncio/base_events.py:275> created at test_aio.py:13> took 0.100 seconds

...
```

What can be another way to schedule a lot of parallel tasks?

----------
components: asyncio
messages: 314207
nosy: asvetlov, decaz, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio loop blocks with a lot of parallel tasks
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:50:36 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Mar 2018 15:50:36 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521647436.01.0.467229070634.issue33078@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset e2f33add635df4fde81be9960bab367e010c19bf by Antoine Pitrou (Thomas Moreau) in branch 'master':
bpo-33078 - Fix queue size on pickling error (GH-6119)
https://github.com/python/cpython/commit/e2f33add635df4fde81be9960bab367e010c19bf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:50:52 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Mar 2018 15:50:52 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521647452.8.0.467229070634.issue33078@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:51:02 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 15:51:02 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521647462.08.0.467229070634.issue33078@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5928

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 11:55:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 21 Mar 2018 15:55:47 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521647747.86.0.467229070634.issue33115@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Well, there's nothing we can do here, it's just a lot of work for a single-threaded process to get a 10000 tasks going.  You'll get the same picture in any other async Python framework.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Wed Mar 21 12:21:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Mar 2018 16:21:19 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521649279.72.0.467229070634.issue33078@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset bb5b5291971c104ea773db1a30e46d410b6b3e1e by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
bpo-33078 - Fix queue size on pickling error (GH-6119) (GH-6178)
https://github.com/python/cpython/commit/bb5b5291971c104ea773db1a30e46d410b6b3e1e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 12:21:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Mar 2018 16:21:33 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521649293.39.0.467229070634.issue33078@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/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 12:36:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Mar 2018 16:36:17 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521650177.49.0.467229070634.issue33078@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Buildbots are failing on macOS:

http://buildbot.python.org/all/#/builders/14/builds/804/steps/4/logs/stdio
http://buildbot.python.org/all/#/builders/93/builds/459/steps/4/logs/stdio

----------
nosy: +ned.deily
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 13:01:55 2018
From: report at bugs.python.org (Thomas Moreau)
Date: Wed, 21 Mar 2018 17:01:55 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521651715.05.0.467229070634.issue33078@psf.upfronthosting.co.za>


Change by Thomas Moreau <thomas.moreau.2010 at gmail.com>:


----------
pull_requests: +5929
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 13:14:36 2018
From: report at bugs.python.org (Ethan Welty)
Date: Wed, 21 Mar 2018 17:14:36 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521652476.92.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ethan Welty <ethan.welty at gmail.com> added the comment:

I have tried running the script with:

- command line (python <file>): Works without (breaks with) `import _tkinter`.
- basic python console (python): Same as with command line.
- ipython: Fails with or without `import _tkinter`. However, if for example I make the matrix in the scripts smaller or use only functions that don't resort to multithreading, code runs successfully in parallel in ipython.
- IDLE: Perhaps unsurprisingly, the code fails with or without `import _tkinter` (never terminates, or prompts endless "Your program is still running! Do you want to kill it?")

Suspecting a problem with Tcl/Tk (Apple's original 8.5.9), I rebuilt python pointing to tcl-tk installed with brew (8.6.8), which I checked with IDLE and _tkinter.TCL_VERSION() / _tkinter.TK_VERSION(). However, this did not fix the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Wed Mar 21 13:27:23 2018
From: report at bugs.python.org (TD22057)
Date: Wed, 21 Mar 2018 17:27:23 +0000
Subject: [issue9338] argparse optionals with nargs='?',
 '*' or '+' can't be followed by positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1521653243.73.0.467229070634.issue9338@psf.upfronthosting.co.za>


TD22057 <ted.drain at gmail.com> added the comment:

Is there any chance this will ever get fixed?  Patches have been available for 5 years with no progress.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Wed Mar 21 13:28:15 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 21 Mar 2018 17:28:15 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521653295.1.0.467229070634.issue33053@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The proposed change for 3.8 and 3.7 seems reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Wed Mar 21 13:46:30 2018
From: report at bugs.python.org (Marat Sharafutdinov)
Date: Wed, 21 Mar 2018 17:46:30 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521654390.62.0.467229070634.issue33115@psf.upfronthosting.co.za>


Marat Sharafutdinov <decaz89 at gmail.com> added the comment:

But why if I use multiprocessing (run 100 tasks by 100 workers) it still continue blocking loop within some workers? Are 100 tasks "a lot of work" for asyncio loop?

```python
import asyncio
from multiprocessing import Process

worker_count = 100
task_count = 100

def worker_main(worker_id):
    async def main():
        for x in range(1, task_count + 1):
            asyncio.ensure_future(f(x))

    async def f(x):
        if x % 1000 == 0 or x == task_count:
            print(f'[WORKER-{worker_id}] Run f({x})')
        await asyncio.sleep(1)
        loop.call_later(1, lambda: asyncio.ensure_future(f(x)))

    loop = asyncio.get_event_loop()
    loop.set_debug(True)
    loop.run_until_complete(main())
    loop.run_forever()

if __name__ == '__main__':
    for worker_id in range(worker_count):
        worker = Process(target=worker_main, args=(worker_id,), daemon=True)
        worker.start()
    while True:
        pass
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Wed Mar 21 14:09:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 21 Mar 2018 18:09:20 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521655760.44.0.467229070634.issue33115@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The "blocking" you observe is caused by Python GC.  If I add "import gc; gc.disable()" the warnings disappear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Wed Mar 21 14:11:42 2018
From: report at bugs.python.org (Ethan Welty)
Date: Wed, 21 Mar 2018 18:11:42 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521655902.2.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ethan Welty <ethan.welty at gmail.com> added the comment:

I've tried with additional backends: WX, WXAgg, WXCairo, Qt5Agg (in matplotlib speak).

With these, I can at least import matplotlib.pyplot, but as soon as say matplotlib.pyplot.plot is called and the backend is loaded, the code breaks (error message for WXAgg below). Is multiprocessing in an interactive shell simply not meant to be supported on MacOS?

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Users/Admin/.pyenv/versions/3.6.4/Python.framework/Versions/3.6/lib/python3.6/site-packages/matplotlib/_pylab_helpers.py", line 78, in destroy_all
    manager.destroy()
  File "/Users/Admin/.pyenv/versions/3.6.4/Python.framework/Versions/3.6/lib/python3.6/site-packages/matplotlib/backends/backend_wx.py", line 1303, in destroy
    self.frame.Destroy()
  File "/Users/Admin/.pyenv/versions/3.6.4/Python.framework/Versions/3.6/lib/python3.6/site-packages/matplotlib/backends/backend_wx.py", line 1256, in Destroy
    if not self.IsBeingDeleted():
RuntimeError: wrapped C/C++ object of type FigureFrameWxAgg has been deleted

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Wed Mar 21 14:21:20 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Mar 2018 18:21:20 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1521656480.47.0.467229070634.issue15248@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Reviewing Serhiy's patch, I changed my mind from 6 years ago (msg164774).  I may have over-estimated the difficulty; in any case the code patch is written.  (Tests are still needed.)  And the code is rather straightforward and readable.

Beyond that, I see the patch as detecting a SyntaxError during compilation, as explained below, with the hint being frosting on top of that.  (It is not an 'Error' as the grammar is now, but it is an error as we might like it to be, hence Serhiy used SyntaxWarning instead.)

In addition, we now have the 'print' precedent of 'print'.
  >>> print 1
  SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1)?
I don't remember when this was added, but I don't see any mention above.

And it seems from other discussions, like the recent python-ideas thread about possibly deprecating 'string' 'joining', that several people have much more of a problem with missing commas than some of us do.

If it were possible, we would like the 'call' production to be
  call ::=  callable "(" [argument_list [","] | comprehension] ")"
but 'callable' is not syntactically definable.  What is syntactically definable and what Serhiy's patch implements is
 possible_callable  ::= primary - <obvious exclusions>
 call  ::= possible_callable ...

As it happens, our grammar metasyntax does not (I believe) include set difference, and I suspect that implementing 'possible_callable' by set addition would result in something that is not LL(1) and possibly ambiguous.  Even if 'possible_callable' could be defined within the LL(1) constraint, I suspect it would be messy, and special-casing would still be needed for the special-case message.

Ditto for 'possibly_subscriptable'.

I have 3 questions:
1. Why 'chech' instead of 'check'?
2. Will chech_index catch "[1,2] [3,4]"? (I am guessing that is the intent.)
3. Does Syntax Warning stop compilation, or at least execution, as at a >>> prompt?

Aside from that, I would be inclined to mark this for 'Interpreter Core' and seriously consider it.

----------
versions: +Python 3.8 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Wed Mar 21 14:58:34 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Mar 2018 18:58:34 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521658714.43.0.467229070634.issue33078@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

PR 6180 appears to have fixed the 3.x failures, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 14:59:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Mar 2018 18:59:34 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1521658774.29.0.467229070634.issue15248@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Actually the precedence was a warning for an assert like:

    assert(x % 2 == 0, "x is odd")

Currently it is the only syntax warning produced by the compiler.

> 1. Why 'chech' instead of 'check'?

Just a typo replicated with a copy-paste.

> 2. Will chech_index catch "[1,2] [3,4]"? (I am guessing that is the intent.)

Yes, it is. It could be extended to catch also "['foo','bar'] ['baz']".

> 3. Does Syntax Warning stop compilation, or at least execution, as at a >>> prompt?

No, it is just a warning unless you run Python with -Werror.

This patch was inspired by usability improvements in GCC 8 [1]. I haven't created a pull request because I have doubts about that this should be in the compiler rather of a third-party linter. But if several other core developers will support this idea I'll continue working in this direction.

[1] https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Wed Mar 21 15:01:57 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Mar 2018 19:01:57 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521658917.85.0.467229070634.issue33078@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good, I think we can close again now!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 15:30:53 2018
From: report at bugs.python.org (Ethan Welty)
Date: Wed, 21 Mar 2018 19:30:53 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521660653.2.0.467229070634.issue33111@psf.upfronthosting.co.za>


Change by Ethan Welty <ethan.welty at gmail.com>:


----------
components: +macOS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Wed Mar 21 16:33:53 2018
From: report at bugs.python.org (Steven Downum)
Date: Wed, 21 Mar 2018 20:33:53 +0000
Subject: [issue28677] difficult to parse sentence structure in "When an
 instance attribute is referenced that isn't a data attribute"
In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>
Message-ID: <1521664433.9.0.467229070634.issue28677@psf.upfronthosting.co.za>


Change by Steven Downum <devilaether at gmail.com>:


----------
nosy: +steven.downum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28677>
_______________________________________

From report at bugs.python.org  Wed Mar 21 16:47:50 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 20:47:50 +0000
Subject: [issue33116] Field is not exposed in dataclasses.__all__
Message-ID: <1521665270.67.0.467229070634.issue33116@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

'Field' needs to be added to __all__.

----------
assignee: eric.smith
messages: 314222
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Field is not exposed in dataclasses.__all__
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33116>
_______________________________________

From report at bugs.python.org  Wed Mar 21 16:54:27 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 20:54:27 +0000
Subject: [issue33116] Field is not exposed in dataclasses.__all__
In-Reply-To: <1521665270.67.0.467229070634.issue33116@psf.upfronthosting.co.za>
Message-ID: <1521665667.42.0.467229070634.issue33116@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5930
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33116>
_______________________________________

From report at bugs.python.org  Wed Mar 21 17:06:46 2018
From: report at bugs.python.org (Henrique Fingler)
Date: Wed, 21 Mar 2018 21:06:46 +0000
Subject: [issue33117] asyncio example uses non-existing/documented method
Message-ID: <1521666406.67.0.467229070634.issue33117@psf.upfronthosting.co.za>


New submission from Henrique Fingler <idnpolar at gmail.com>:

In the documentation of asyncio.run_coroutine_threadsafe(coro, loop), in Section 19.5.3.6 (https://docs.python.org/3/library/asyncio-task.html#asyncio.run_coroutine_threadsafe), the example code does the following:

    future = asyncio.run_coroutine_threadsafe(coro, loop)
    # Wait for the result with an optional timeout argument
    assert future.result(timeout) == 3

 The problem is that the result method of a future, according to the documentation doesn't take parameters. It's in Section 19.5.3.4 (https://docs.python.org/3.8/library/asyncio-task.html#asyncio.Future.done)

    result()
        Return the result this future represents.


 The same function is used in Section 18.5.9.3 (https://docs.python.org/3/library/asyncio-dev.html#concurrency-and-multithreading)


 This error is present in all Python 3.* docs.

 From the asyncio source code (https://github.com/python/cpython/blob/master/Lib/asyncio/futures.py), we have this in the Future class definition:

class Future:
    """This class is *almost* compatible with concurrent.futures.Future.
    Differences:
    - This class is not thread-safe.
    - result() and exception() do not take a timeout argument and
      raise an exception when the future isn't done yet.

    ....

So this example needs to be reworked, I'd do it if I knew more about asyncio. My ideas involve either using a add_done_callback with a flag or just busy waiting until future.done().

----------
assignee: docs at python
components: Documentation
messages: 314223
nosy: Henrique Fingler, docs at python
priority: normal
severity: normal
status: open
title: asyncio example uses non-existing/documented method
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33117>
_______________________________________

From report at bugs.python.org  Wed Mar 21 17:14:41 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 21 Mar 2018 21:14:41 +0000
Subject: [issue33116] Field is not exposed in dataclasses.__all__
In-Reply-To: <1521665270.67.0.467229070634.issue33116@psf.upfronthosting.co.za>
Message-ID: <1521666881.52.0.467229070634.issue33116@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5931

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33116>
_______________________________________

From report at bugs.python.org  Wed Mar 21 17:27:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Mar 2018 21:27:09 +0000
Subject: [issue33078] Queue with maxsize can lead to deadlocks
In-Reply-To: <1521095814.22.0.467229070634.issue33078@psf.upfronthosting.co.za>
Message-ID: <1521667629.14.0.467229070634.issue33078@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

(Fot the record, PR 6181 was the 3.7 backport of PR 6180.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33078>
_______________________________________

From report at bugs.python.org  Wed Mar 21 17:44:26 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 21:44:26 +0000
Subject: [issue33116] Field is not exposed in dataclasses.__all__
In-Reply-To: <1521665270.67.0.467229070634.issue33116@psf.upfronthosting.co.za>
Message-ID: <1521668666.14.0.467229070634.issue33116@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 4ddc99d15963b0374f9dbfd57f14e6194ad65669 by Eric V. Smith (Miss Islington (bot)) in branch '3.7':
bpo-33116: Add 'Field' to dataclasses.__all__. (GH-6182) (GH-6183)
https://github.com/python/cpython/commit/4ddc99d15963b0374f9dbfd57f14e6194ad65669


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33116>
_______________________________________

From report at bugs.python.org  Wed Mar 21 17:45:50 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 21:45:50 +0000
Subject: [issue33116] Field is not exposed in dataclasses.__all__
In-Reply-To: <1521665270.67.0.467229070634.issue33116@psf.upfronthosting.co.za>
Message-ID: <1521668750.96.0.467229070634.issue33116@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/issue33116>
_______________________________________

From report at bugs.python.org  Wed Mar 21 17:53:39 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Mar 2018 21:53:39 +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: <1521669219.26.0.467229070634.issue32505@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure this is worth preventing. I can certainly make it an error, but since dataclasses ignores anything without a type annotation, I don't think it's a big deal. Basically I'd have to look through all class attributes that are of type Field but aren't in the class's __annotations__.

I cannot find the original conversation that caused me to open this issue. If anyone feels strongly that this case should be an error, let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Wed Mar 21 18:22:43 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Mar 2018 22:22:43 +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: <1521670963.95.0.467229070634.issue32505@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Fine to close as wontfix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Wed Mar 21 19:43:42 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 21 Mar 2018 23:43:42 +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: <1521675822.54.0.467229070634.issue32505@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Some part of the discussion is in https://bugs.python.org/issue32428

I still think it is important to flag things like this as an error:

@dataclass
class C:
    x = field()

This is a big bug magnet. Especially taking into account that attrs behave in the opposite way in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Wed Mar 21 20:00:44 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Mar 2018 00:00:44 +0000
Subject: [issue33110] Adding a done callback to a concurrent.futures Future
 once it has already completed, may raise an exception, contrary to docs
In-Reply-To: <1521562363.32.0.467229070634.issue33110@psf.upfronthosting.co.za>
Message-ID: <1521676844.39.0.467229070634.issue33110@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33110>
_______________________________________

From report at bugs.python.org  Wed Mar 21 20:25:16 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Mar 2018 00:25:16 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521678316.07.0.467229070634.issue33018@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Would you merge this into master?

OK, I played with this a bit and it looks good. There is however a merge conflict now, and a NEWS item is missing. I will leave a comment in the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Wed Mar 21 20:43:38 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Mar 2018 00:43:38 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <1521679418.06.0.467229070634.issue33108@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Maybe, we should update UnicodeData?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Wed Mar 21 21:47:32 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Mar 2018 01:47:32 +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: <1521683252.62.0.467229070634.issue32505@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

But surely when you instantiate this: 
c = C(1)

you'll notice that's an error?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Wed Mar 21 21:59:09 2018
From: report at bugs.python.org (Ma Lin)
Date: Thu, 22 Mar 2018 01:59:09 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <1521683949.61.0.467229070634.issue33108@psf.upfronthosting.co.za>


Ma Lin <malincns at 163.com> added the comment:

There was a discussion about "Latin Capital Letter I with Dot Above"
https://bugs.python.org/issue17252

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Wed Mar 21 22:02:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Mar 2018 02:02:38 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521684158.86.0.467229070634.issue33053@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I am OK with changing '' to the initial resolved working directory for 3.7 as long as we get that change in now, i.e. before the 3.7.0b3 ABI freeze next Monday.  And I agree that we should not attempt to change this behavior for 3.6.x at this stage of its life cycle.

----------
nosy: +ned.deily
priority: normal -> release blocker
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Wed Mar 21 22:05:34 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Mar 2018 02:05:34 +0000
Subject: [issue33117] asyncio example uses non-existing/documented method
In-Reply-To: <1521666406.67.0.467229070634.issue33117@psf.upfronthosting.co.za>
Message-ID: <1521684334.17.0.467229070634.issue33117@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +asvetlov, giampaolo.rodola, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33117>
_______________________________________

From report at bugs.python.org  Thu Mar 22 02:09:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 06:09:55 +0000
Subject: [issue33108] Unicode char 304 in lowercase has len = 2
In-Reply-To: <1521552126.55.0.467229070634.issue33108@psf.upfronthosting.co.za>
Message-ID: <1521698995.93.0.467229070634.issue33108@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Ma Lin.

Closed as a duplicate of issue17252.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Latin Capital Letter I with Dot Above

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33108>
_______________________________________

From report at bugs.python.org  Thu Mar 22 02:38:35 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Mar 2018 06:38:35 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1521700715.5.0.467229070634.issue27212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Cheryl, I think you take this one.  It hasn't been touched in a long time and Nofar is focused on another issue.

----------
assignee: Nofar Schnider -> csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Thu Mar 22 02:40:11 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 22 Mar 2018 06:40:11 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
Message-ID: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>


New submission from Vitaly Kruglikov <vitaly.krug at gmail.com>:

There doesn't appear to be an ordained mechanism for getting notified when a Transport's (or WriteTransport's) write buffer drains to zero (i.e., all output data has been transferred to socket). I don't want to hijack `set_write_buffer_limits()` for this purpose, because that would preclude me from using it for its intended purpose.

I see that transport in selector_events.py has a private method `_make_empty_waiter()`, which is along the lines of what I need, but it's private and is used by `BaseSelectorEventLoop._sendfile_native()`.

Just like `BaseSelectorEventLoop._sendfile_native()`, my app needs equivalent functionality in order to be able to run the loop (`run_until_complete()`) until the transport's write buffer empties out.

----------
components: asyncio
messages: 314236
nosy: asvetlov, vitaly.krug, yselivanov
priority: normal
severity: normal
status: open
title: No clean way to get notified when a Transport's write buffer empties out
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 04:35:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 08:35:47 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1521707747.39.0.467229070634.issue4819@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Mar 22 04:38:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 08:38:26 +0000
Subject: [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1521707906.32.0.467229070634.issue13677@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13677>
_______________________________________

From report at bugs.python.org  Thu Mar 22 04:59:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 08:59:47 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1521709187.5.0.467229070634.issue24565@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Could you please convert your patches to a PR Xavier?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Thu Mar 22 05:19:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 09:19:51 +0000
Subject: [issue25836] Documentation of MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG
 is misleading
In-Reply-To: <1449807235.86.0.17166679506.issue25836@psf.upfronthosting.co.za>
Message-ID: <1521710391.14.0.467229070634.issue25836@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

MAKE_FUNCTION was changed in 3.6, and its documentation was changed accordingly. 3.5 is now in security-only fixes stage.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25836>
_______________________________________

From report at bugs.python.org  Thu Mar 22 05:21:13 2018
From: report at bugs.python.org (Jonathan Huot)
Date: Thu, 22 Mar 2018 09:21:13 +0000
Subject: [issue33119] python sys.argv argument parsing not clear
Message-ID: <1521710473.18.0.467229070634.issue33119@psf.upfronthosting.co.za>


New submission from Jonathan Huot <jonathan.huot at thomsonreuters.com>:

Executing python modules with -m can lead to weird sys.argv parsing.

"Argument parsing" section at https://docs.python.org/3.8/tutorial/interpreter.html#argument-passing mention :

- When -m module is used, sys.argv[0] is set to the full name of the located module.

The word "located" is used, but it doesn't mention anything when the module is not *yet* "located".

For instance, let's see what is the sys.argv for each python files:


$ cat mainmodule/__init__.py
import sys; print("{}: {}".format(sys.argv, __file__))
$ cat mainmodule/submodule/__init__.py
import sys; print("{}: {}".format(sys.argv, __file__))
$ cat mainmodule/submodule/foobar.py
import sys; print("{}: {}".format(sys.argv, __file__))


Then we call "foobar" with -m:

$ python -m mainmodule.submodule.foobar -o -b
['-m', '-o', 'b']: (..)/mainmodule/__init__.py
['-m', '-o', 'b']: (..)/mainmodule/submodule/__init__.py
['(..)/mainmodule/submodule/foobar.py', '-o', 'b']: (..)/mainmodule/submodule/foobar.py
$


We notice that only "-m" is in sys.argv before we found "foobar". This can lead to a lot of troubles when we have meaningful processing in __init__.py which rely on sys.argv to initialize stuff.

IMHO, it either should be the sys.argv intact ['-m', 'mainmodule.submodule.foobar', '-o', '-b'] or empty ['', '-o', '-b'] or  only the latest ['-o', '-b'], but it should not be ['-m', '-o', '-b'] which is very confusing.

----------
assignee: docs at python
components: Documentation
messages: 314239
nosy: Jonathan Huot, docs at python
priority: normal
severity: normal
status: open
title: python sys.argv argument parsing not clear
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/issue33119>
_______________________________________

From report at bugs.python.org  Thu Mar 22 05:34:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 09:34:33 +0000
Subject: [issue26286] dis module: coroutine opcode documentation clarity
In-Reply-To: <1454620080.04.0.670513123841.issue26286@psf.upfronthosting.co.za>
Message-ID: <1521711273.42.0.467229070634.issue26286@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

(2) is already fixed.

SETUP_ASYNC_WITH talks about the same frame blocks as pushed by SETUP_FINALLY, SETUP_EXCEPT, SETUP_LOOP and popped by POP_BLOCK. But unlike to SETUP_FINALLY it pushes a frame block pointing below TOS. This detail needs to be documented.

Do you mind to create a pull request Jim?

----------
nosy: +serhiy.storchaka
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26286>
_______________________________________

From report at bugs.python.org  Thu Mar 22 05:58:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 09:58:00 +0000
Subject: [issue28962] Crash when throwing an exception with a malicious
 __hash__ override
In-Reply-To: <1481646487.87.0.692050241508.issue28962@psf.upfronthosting.co.za>
Message-ID: <1521712680.13.0.467229070634.issue28962@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems it was fixed somewhere between 3.6.3 and 3.6.5+.

Traceback (most recent call last):
  File "baderror.py", line 10, in <module>
    raise e from e
__main__.BadError

3.5 is now in security-only fixes stage, and this doesn't look like a security issue.

----------
nosy: +serhiy.storchaka
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28962>
_______________________________________

From report at bugs.python.org  Thu Mar 22 05:58:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 09:58:11 +0000
Subject: [issue28962] Crash when throwing an exception with a malicious
 __hash__ override
In-Reply-To: <1481646487.87.0.692050241508.issue28962@psf.upfronthosting.co.za>
Message-ID: <1521712691.54.0.467229070634.issue28962@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28962>
_______________________________________

From report at bugs.python.org  Thu Mar 22 06:00:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 10:00:23 +0000
Subject: [issue25782] CPython hangs on error __context__ set to the error
 itself
In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za>
Message-ID: <1521712823.69.0.467229070634.issue25782@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What should we do with this issue? Does it need opening a topic on Python-Dev?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25782>
_______________________________________

From report at bugs.python.org  Thu Mar 22 06:05:59 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 22 Mar 2018 10:05:59 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1521713159.49.0.467229070634.issue24565@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

I will work on it shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Thu Mar 22 06:15:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 10:15:50 +0000
Subject: [issue25828] PyCode_Optimize() (peephole optimizer) doesn't handle
 KeyboardInterrupt correctly
In-Reply-To: <1449648204.19.0.769728792688.issue25828@psf.upfronthosting.co.za>
Message-ID: <1521713750.42.0.467229070634.issue25828@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I can reproduce a crash in 3.5, but not in 3.6. Seems it was fixed in issue30416.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25828>
_______________________________________

From report at bugs.python.org  Thu Mar 22 06:18:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 10:18:19 +0000
Subject: [issue32838] Fix Python versions in the table of magic numbers
In-Reply-To: <1518520184.53.0.467229070634.issue32838@psf.upfronthosting.co.za>
Message-ID: <1521713899.65.0.467229070634.issue32838@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/issue32838>
_______________________________________

From report at bugs.python.org  Thu Mar 22 06:21:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 10:21:05 +0000
Subject: [issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and
 BUILD_TUPLE_UNPACK_WITH_CALL are too long
In-Reply-To: <1492277239.5.0.348724747458.issue30076@psf.upfronthosting.co.za>
Message-ID: <1521714065.71.0.467229070634.issue30076@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30076>
_______________________________________

From report at bugs.python.org  Thu Mar 22 06:46:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 10:46:59 +0000
Subject: [issue23203] Aliasing import of sub-{module,
 package} from the package raises AttributeError on import.
In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za>
Message-ID: <1521715619.72.0.467229070634.issue23203@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is anything left to do with this issue after issue30024?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23203>
_______________________________________

From report at bugs.python.org  Thu Mar 22 07:26:09 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Mar 2018 11:26:09 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521717969.15.0.467229070634.issue33018@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 40472dd42de4f7265d456458cd13ad6894d736db by Ivan Levkivskyi (jab) in branch 'master':
bpo-33018: Improve issubclass() error checking and message. (GH-5944)
https://github.com/python/cpython/commit/40472dd42de4f7265d456458cd13ad6894d736db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 07:26:31 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 22 Mar 2018 11:26:31 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521717991.29.0.467229070634.issue33018@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +5932
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 07:49:28 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 22 Mar 2018 11:49:28 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521719368.95.0.467229070634.issue33018@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 346964ba0586e402610ea886e70bee1294874781 by Miss Islington (bot) in branch '3.7':
bpo-33018: Improve issubclass() error checking and message. (GH-5944)
https://github.com/python/cpython/commit/346964ba0586e402610ea886e70bee1294874781


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 07:59:00 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Mar 2018 11:59:00 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521719940.86.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5933

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Thu Mar 22 07:59:00 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Mar 2018 11:59:00 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521719940.98.0.574204596225.issue33018@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 08:16:39 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Mar 2018 12:16:39 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521720999.51.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Brett or Eric, any chance one of you could run with this for 3.7b3? I already have a startup refactoring related regression that I'm aiming to have fixed before then.

Thanks to Victor's refactoring work, there's at least a clear interception point now where we can treat the empty string differently depending on whether the command line option was `-c`, `-m`, or not specified at all: https://github.com/python/cpython/blob/master/Python/pathconfig.c#L259

As an initial attempt, I think the necessary fix will be along the lines of checking for 'n == 0 && argc > 1 && wcscmp(argv0, L"-m") == 0', and resolving the current working directory in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Thu Mar 22 08:24:45 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Mar 2018 12:24:45 +0000
Subject: [issue23203] Aliasing import of sub-{module,
 package} from the package raises AttributeError on import.
In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za>
Message-ID: <1521721485.75.0.467229070634.issue23203@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Heh, apparently I forgot how IMPORT_FROM currently works some time between 2015 and 2017 :)

I agree this is out of date now, as the requested behaviour was already implemented for 3.7

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23203>
_______________________________________

From report at bugs.python.org  Thu Mar 22 08:52:45 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Mar 2018 12:52:45 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521723165.29.0.467229070634.issue33018@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset f757b72b2524ce3451d2269f0b8a9f0593a7b27f by INADA Naoki in branch 'master':
bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189)
https://github.com/python/cpython/commit/f757b72b2524ce3451d2269f0b8a9f0593a7b27f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 08:52:45 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Mar 2018 12:52:45 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521723165.42.0.714561066657.issue32999@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset f757b72b2524ce3451d2269f0b8a9f0593a7b27f by INADA Naoki in branch 'master':
bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189)
https://github.com/python/cpython/commit/f757b72b2524ce3451d2269f0b8a9f0593a7b27f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Thu Mar 22 08:53:03 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 22 Mar 2018 12:53:03 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521723183.74.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5935

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Thu Mar 22 08:53:03 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 22 Mar 2018 12:53:03 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521723183.87.0.574204596225.issue33018@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5936

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 09:04:23 2018
From: report at bugs.python.org (Viv)
Date: Thu, 22 Mar 2018 13:04:23 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521723863.87.0.467229070634.issue33053@psf.upfronthosting.co.za>


Viv <vovaruzoze at twocowmail.net> added the comment:

Thanks, worked a treat https://www.allcarleasing.co.uk/special-offers/

----------
nosy: +Viv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Thu Mar 22 09:24:01 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 22 Mar 2018 13:24:01 +0000
Subject: [issue32234] Add context management to mailbox.Mailbox
In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za>
Message-ID: <1521725041.54.0.467229070634.issue32234@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

It looks like Barry was ready to merge this PR in December.  Is there anything else that needs to be done for it?  Thanks!

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32234>
_______________________________________

From report at bugs.python.org  Thu Mar 22 09:36:41 2018
From: report at bugs.python.org (Peter)
Date: Thu, 22 Mar 2018 13:36:41 +0000
Subject: [issue33120] infinite loop in inspect.unwrap(unittest.mock.call)
Message-ID: <1521725801.92.0.467229070634.issue33120@psf.upfronthosting.co.za>


New submission from Peter <poslano at gmail.com>:

The following module will eat all available RAM if executed:

import inspect
import unittest.mock
print(inspect.unwrap(unittest.mock.call))

inspect.unwrap has loop protection against functions that wrap themselves, but unittest.mock.call creates new object on demand.

----------
components: Library (Lib)
messages: 314254
nosy: peterdemin
priority: normal
severity: normal
status: open
title: infinite loop in inspect.unwrap(unittest.mock.call)
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33120>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:00:14 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Mar 2018 14:00:14 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521727214.14.0.467229070634.issue33018@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 5d8bb5d07be2a9205e7059090f0ac5360d36b217 by Ivan Levkivskyi (Miss Islington (bot)) in branch '3.7':
bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189) (GH-6190)
https://github.com/python/cpython/commit/5d8bb5d07be2a9205e7059090f0ac5360d36b217


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:00:14 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Mar 2018 14:00:14 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521727214.28.0.714561066657.issue32999@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 5d8bb5d07be2a9205e7059090f0ac5360d36b217 by Ivan Levkivskyi (Miss Islington (bot)) in branch '3.7':
bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189) (GH-6190)
https://github.com/python/cpython/commit/5d8bb5d07be2a9205e7059090f0ac5360d36b217


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:03:17 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Mar 2018 14:03:17 +0000
Subject: [issue33018] Improve issubclass() error checking and message
In-Reply-To: <1520409547.91.0.467229070634.issue33018@psf.upfronthosting.co.za>
Message-ID: <1521727397.34.0.467229070634.issue33018@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I am closing this for now. We can re-open it later if problems will appear in 3.7.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33018>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:08:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 14:08:50 +0000
Subject: [issue17861] put opcode information in one place
In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za>
Message-ID: <1521727730.29.0.467229070634.issue17861@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Currently an explicit `make regen-opcode` and `make regen-opcode-targets` (or just `make regen-all`) are needed for regenerating C files from opcode.py.

Is anything left to do in this issue?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17861>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:14:26 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Mar 2018 14:14:26 +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: <1521728066.58.0.467229070634.issue32505@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> you'll notice that's an error?

Yes, but there are other scenarios, like using `init=False` or updating existing class definition and forgetting to update call sites (which will still work), etc.

What would we lose by not flagging this as an error? I think there are no legitimate use cases for such code, and implementation is straightforward. If you don't have time I can do this myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:15:08 2018
From: report at bugs.python.org (joders)
Date: Thu, 22 Mar 2018 14:15:08 +0000
Subject: [issue33121] recv returning 0 on closed connection not documented
Message-ID: <1521728108.91.0.467229070634.issue33121@psf.upfronthosting.co.za>


New submission from joders <jona.enders at yahoo.com>:

The "Linux Programmer's Manual" states:

When a stream socket peer has performed an orderly shutdown, the return value will be 0 (the traditional "end-of-file" return).

I find that information pretty important which is why I am asking if you might want to add it to the python documentation as well. It would have prevented a bug in my code.

----------
assignee: docs at python
components: Documentation
messages: 314260
nosy: docs at python, joders
priority: normal
severity: normal
status: open
title: recv returning 0 on closed connection not documented
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33121>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:29:38 2018
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen?=)
Date: Thu, 22 Mar 2018 14:29:38 +0000
Subject: [issue33122] ftplib: FTP_TLS seems to have problems with sites that
 close the encrypted channel themselfes
Message-ID: <1521728978.52.0.467229070634.issue33122@psf.upfronthosting.co.za>


New submission from J?rgen <jottbe at sags-per-mail.de>:

Hi,

I'm not quite sure, if you would actually call this a bug, but it is very molesting at least ;o)

I use ftplib.FTP_TLS to connect to a z/OS ftp server. With a minor change it works very well (happy to have found this library).
The problem I have is, that without any change, an exception is raised after every single command I invoke, even though the server sends back an ok message.

The exception is an OSError which is raised while executing conn.unwrap(). It seems the connection is already closed when this is called and thus an exception is raised. But handling this exception outside the FTP_TLS-class makes no sense, because then every command would raise an exception and the "good" exceptions could not be distinguised from the ones that are really searious so easily anymore (I mean: if i get an exception that a connection could not be closed, because someone else closed it before, that's not very serious, is it?).

Suggestions to solve this:
small solution: allow the programmer to decide what to do, by creating subclasses
This is "factor-out" the unwrap logic in a separate method or function, so at least users of the class can overwrite the behavior, without having to rebuild the whole logic of the affected methods.

In my quick solution I created a new method in class FTP:
    def __handleAutoCloseSSL__(self, conn):
        if self.autoCloseModeSSL == 'NONE' or self.autoCloseModeSSL is None or _SSLSocket is None or not isinstance(conn, _SSLSocket):
            # do nothing
            pass
        elif self.autoCloseModeSSL in ('SAFE', 'HIDE'):
            try:
                conn.unwrap()
            except OSError as ex:
                if self.autoCloseModeSSL != 'HIDE':
                    print('Caught exception %s while calling conn.unwrap()' % str(ex))
        else:
            # Standard mode (usally self.autoCloseModeSSL =='STANDARD' but anything else is accepted as well)
            # the original code was:
            #if _SSLSocket is not None and isinstance(conn, _SSLSocket):
            #    conn.unwrap()
            conn.unwrap()

And the class variable:
autoCloseModeSSL = 'STANDARD'

Then I called it from methods (instead of doing conn.unwrap() there directly):
retbinary
retlines
storbinary
storlines

Ok, maybe not that sexy, but it works :o)
And if you don't like the hack with instance variable autoCloseModeSSL, you could just transfer the original conn.unwrap() in an extra method which could then be overwritten by programmers in subclasses. This would already help me very much, because I know that patching a library is not a good idea. Even more if it is a communication library that might be updated from time to time.

----------
components: Library (Lib)
messages: 314261
nosy: jottbe
priority: normal
severity: normal
status: open
title: ftplib: FTP_TLS seems to have problems with sites that close the encrypted channel themselfes
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33122>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:40:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 14:40:18 +0000
Subject: [issue19979] Missing nested scope vars in class scope (bis)
In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za>
Message-ID: <1521729618.79.0.467229070634.issue19979@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a duplicate of issue9226.

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19979>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:43:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 14:43:48 +0000
Subject: [issue30416] constant folding opens compiler to quadratic time hashing
In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za>
Message-ID: <1521729828.25.0.467229070634.issue30416@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +benjamin.peterson
priority: normal -> deferred blocker
versions: +Python 2.7 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30416>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:43:55 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 22 Mar 2018 14:43:55 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521729835.3.0.467229070634.issue33053@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg314252

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:48:04 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Mar 2018 14:48:04 +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: <1521730084.57.0.467229070634.issue32505@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks for the offer. I've already got the code written, I just need to write some tests. I'll get it done real soon now.

----------
components: +Library (Lib)
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 10:54:49 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Thu, 22 Mar 2018 14:54:49 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521730489.77.0.467229070634.issue6083@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

> New changeset a4c85f9b8f58 by Serhiy Storchaka in branch '2.7':
Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple
http://hg.python.org/cpython/rev/a4c85f9b8f58

This test has a problem: though it tests not the ability to set a CPU hard limit, it fails if the hard limit is limited. Perhaps, ignore any exception there? Could you please help me re-write it correctly, so that I can run it on gyle--ALT's builder host--successfully):

    # Issue 6083: Reference counting bug
    def test_setrusage_refcount(self):
        try:
            limits = resource.getrlimit(resource.RLIMIT_CPU)
        except AttributeError:
            self.skipTest('RLIMIT_CPU not available')
        class BadSequence:
            def __len__(self):
                return 2
            def __getitem__(self, key):
                if key in (0, 1):
                    return len(tuple(range(1000000)))
                raise IndexError

        resource.setrlimit(resource.RLIMIT_CPU, BadSequence())

The failure:

[builder at team ~]$ python /usr/lib64/python2.7/test/test_resource.py
test_args (__main__.ResourceTest) ... ok
test_fsize_enforced (__main__.ResourceTest) ... ok
test_fsize_ismax (__main__.ResourceTest) ... ok
test_fsize_toobig (__main__.ResourceTest) ... ok
test_getrusage (__main__.ResourceTest) ... ok
test_setrusage_refcount (__main__.ResourceTest) ... ERROR

======================================================================
ERROR: test_setrusage_refcount (__main__.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/test/test_resource.py", line 117, in test_setrusage_refcount
    resource.setrlimit(resource.RLIMIT_CPU, BadSequence())
ValueError: not allowed to raise maximum limit

----------------------------------------------------------------------
Ran 6 tests in 0.085s

FAILED (errors=1)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/test/test_resource.py", line 123, in <module>
    test_main()
  File "/usr/lib64/python2.7/test/test_resource.py", line 120, in test_main
    test_support.run_unittest(ResourceTest)
  File "/usr/lib64/python2.7/test/support/__init__.py", line 1577, in run_unittest
    _run_suite(suite)
  File "/usr/lib64/python2.7/test/support/__init__.py", line 1542, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/usr/lib64/python2.7/test/test_resource.py", line 117, in test_setrusage_refcount
    resource.setrlimit(resource.RLIMIT_CPU, BadSequence())
ValueError: not allowed to raise maximum limit

[builder at team ~]$

----------
nosy: +imz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 11:22:11 2018
From: report at bugs.python.org (=?utf-8?b?UGF3ZcWC?=)
Date: Thu, 22 Mar 2018 15:22:11 +0000
Subject: [issue23434] support encoded filename in Content-Disposition for HTTP
 in cgi.FieldStorage
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1521732131.94.0.467229070634.issue23434@psf.upfronthosting.co.za>


Pawe? <pawciobiel at gmail.com> added the comment:

I didn't find this and created a duplicate
https://bugs.python.org/issue33027

I've added similar/updated changes
https://github.com/python/cpython/pull/6027

@r.david.murray wouldn't it be wise to do one step at a time rather than implementing full support for RFC6266? Please tell exactly what is your expectations so I can fix the patch if it needs to be fixed.

This is also related to RFC5987
https://tools.ietf.org/html/rfc5987
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition

----------
components: +Unicode
nosy: +ezio.melotti, pawciobiel, vstinner
pull_requests: +5937
stage:  -> patch review
title: RFC6266 support (Content-Disposition for HTTP) -> support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23434>
_______________________________________

From report at bugs.python.org  Thu Mar 22 11:24:51 2018
From: report at bugs.python.org (=?utf-8?b?UGF3ZcWC?=)
Date: Thu, 22 Mar 2018 15:24:51 +0000
Subject: [issue33027] handling filename encoding in Content-Disposition by
 cgi.FieldStorage
In-Reply-To: <1520502570.19.0.467229070634.issue33027@psf.upfronthosting.co.za>
Message-ID: <1521732291.89.0.467229070634.issue33027@psf.upfronthosting.co.za>


Pawe? <pawciobiel at gmail.com> added the comment:

duplicate of https://bugs.python.org/issue23434

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33027>
_______________________________________

From report at bugs.python.org  Thu Mar 22 11:52:55 2018
From: report at bugs.python.org (Chad)
Date: Thu, 22 Mar 2018 15:52:55 +0000
Subject: [issue33082] multiprocessing docs bury very important 'callback=' args
In-Reply-To: <1521139850.07.0.467229070634.issue33082@psf.upfronthosting.co.za>
Message-ID: <1521733975.69.0.467229070634.issue33082@psf.upfronthosting.co.za>


Chad <millchad at amazon.com> added the comment:

On topic: My CLA is signed as of Monday, 19 March. My status here is not updated yet.


pitrou, off-topic: Without callbacks, users who want multiprocessing functions to return something, not just mutate state somewhere else, must gather jobs in a list and continually iterate through them polling to see if each has finished yet and conditionally popping it from the list. It's expensive and ugly and error-prone. Callbacks are really great, you should try them again.

So much better:

pool.apply_async(func, args, callback=when_finished_call_with_result)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33082>
_______________________________________

From report at bugs.python.org  Thu Mar 22 11:59:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 15:59:24 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521734364.32.0.467229070634.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What does resource.getrlimit(resource.RLIMIT_CPU) return?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 12:05:44 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 22 Mar 2018 16:05:44 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1521734744.72.0.467229070634.issue27212@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Thanks, Raymond.  I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Thu Mar 22 12:15:31 2018
From: report at bugs.python.org (Peter)
Date: Thu, 22 Mar 2018 16:15:31 +0000
Subject: [issue33120] infinite loop in inspect.unwrap(unittest.mock.call)
In-Reply-To: <1521725801.92.0.467229070634.issue33120@psf.upfronthosting.co.za>
Message-ID: <1521735331.08.0.467229070634.issue33120@psf.upfronthosting.co.za>


Peter <poslano at gmail.com> added the comment:

I see two options to fix it:

1) add recursion depth check to inspect.wrap
2) define __wrapped__ on mock._Call so it won't go into recursion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33120>
_______________________________________

From report at bugs.python.org  Thu Mar 22 12:42:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 22 Mar 2018 16:42:57 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521736977.93.0.467229070634.issue33118@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

We'll likely add 'write_buffer_drained' callback method to `asyncio.Protocol` in 3.8.  In the meanwhile, the only option would be using `_make_empty_waiter` in 3.7, or set_write_buffer_limits(0, 0).

What's your use case, by the way?

----------
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 12:45:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 16:45:58 +0000
Subject: [issue30953] Fatal python error when jumping into except clause
In-Reply-To: <1500326698.05.0.0587216442362.issue30953@psf.upfronthosting.co.za>
Message-ID: <1521737158.93.0.467229070634.issue30953@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is fixed in 3.8.

Traceback (most recent call last):
  File "issue30953.py", line 15, in <module>
    error()
  File "issue30953.py", line 14, in error
    pass
  File "issue30953.py", line 14, in error
    pass
  File "issue30953.py", line 4, in trace
    frame.f_lineno = 12
ValueError: can't jump into or out of a 'finally' block

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30953>
_______________________________________

From report at bugs.python.org  Thu Mar 22 12:59:08 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Thu, 22 Mar 2018 16:59:08 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521737948.55.0.467229070634.issue6083@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

>>> import resource
>>> resource.getrlimit(resource.RLIMIT_CPU) 
(7200, 7260)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 13:50:57 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 22 Mar 2018 17:50:57 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521741057.48.0.467229070634.issue33118@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

Thank you for following up. My use case is this:

In the Pika AMQP client package, we have a blocking AMQP connection adapter - `BlockingConnection` - wrapped around an asynchronous AMQP connection adapter. Presently, BlockingConnection is wrapped around the asynchronous `SelectConnection` which has a home-grown proprietary IOLoop. I would like to switch BlockingConnection to use an asyncio-based adapter when running on Python3.

SelectConnection's proprietary IOLoop provides a single-stepping run function (poll with a timeout as normally determined by pending callbacks, timers, etc., process all ready events/timers/callbacks, and return). When BlockingConnection needs to send something to the AMQP broker and/or wait for an expected reply, it sends the request (which typically gets queued up in a write buffer) and then runs the proprietary IOLoop's single-stepping method in a loop (thus blocking efficiently on I/O); each time after the single-stepping IOLoop method returns, BlockingConnection checks whether the conditions of interest have been satisfied (e.g., the write buffer size being zero and AMQP Channel.OpenOk has been received).

So, another way that asyncio could help, and certainly simplest for me and my use case, is by providing a single-stepping function in the event loop implementations, such as the single-stepping method that I described at the top of the previous paragraph. E.g., `events.AbstractEventLoop.run_one_step()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 13:51:23 2018
From: report at bugs.python.org (Marat Sharafutdinov)
Date: Thu, 22 Mar 2018 17:51:23 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521741083.89.0.467229070634.issue33115@psf.upfronthosting.co.za>


Marat Sharafutdinov <decaz89 at gmail.com> added the comment:

Does this mean that GC uses most part of CPU time so the loop blocks?

And another question: do you have any plans to optimize the loop so it would be possible to run really lot of tasks in parallel?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Thu Mar 22 13:55:35 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Mar 2018 17:55:35 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521741335.98.0.467229070634.issue33053@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I can't make any promises unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Thu Mar 22 13:56:36 2018
From: report at bugs.python.org (rbu)
Date: Thu, 22 Mar 2018 17:56:36 +0000
Subject: [issue33123] Path.unlink should have a missing_ok parameter
Message-ID: <1521741396.21.0.467229070634.issue33123@psf.upfronthosting.co.za>


New submission from rbu <robert.buchholz at goodpoint.de>:

Similarly to how several pathlib file creation functions have an "exists_ok" parameter, we should introduce "missing_ok" that makes removal functions not raise an exception when a file or directory is already absent.

IMHO, this should cover Path.unlink and Path.rmdir.

Note, Path.resolve() has a "strict" parameter since 3.6 that does the same thing. Naming this of this new parameter tries to be consistent with the "exists_ok" parameter as that is more explicit about what it does (as opposed to "strict").

----------
components: Library (Lib)
messages: 314277
nosy: rbu
priority: normal
severity: normal
status: open
title: Path.unlink should have a missing_ok parameter
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33123>
_______________________________________

From report at bugs.python.org  Thu Mar 22 13:57:50 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 22 Mar 2018 17:57:50 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521741470.58.0.467229070634.issue33118@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

... or `events.AbstractEventLoop.run_one_iteration()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 13:59:29 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 22 Mar 2018 17:59:29 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521741569.24.0.467229070634.issue33118@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Yeah, I think your best option would be to use `set_write_buffer_limits(0, 0)`.  You don't need asyncio flow control anyways, as AMQP protocol is unlikely to generate any pressure on IO buffers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:00:46 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 22 Mar 2018 18:00:46 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521741646.25.0.467229070634.issue33118@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> 'events.AbstractEventLoop.run_one_step()'

This is highly unlikely to ever happen.  It's hard to define what one iteration of an event loop is, and it would be even harder to get that agreement for all frameworks/event loops that are compatible with or based on asyncio.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:00:58 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Mar 2018 18:00:58 +0000
Subject: [issue33123] Path.unlink should have a missing_ok parameter
In-Reply-To: <1521741396.21.0.467229070634.issue33123@psf.upfronthosting.co.za>
Message-ID: <1521741658.01.0.467229070634.issue33123@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5938
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33123>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:06:01 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 22 Mar 2018 18:06:01 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521741961.59.0.467229070634.issue33115@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Does this mean that GC uses most part of CPU time so the loop blocks?

GC stops all Python code in the OS process from running.  Because of the GIL code in threads will obviously be stopped too.  This is true for both CPython and PyPy at this moment.

> And another question: do you have any plans to optimize the loop so it would be possible to run really lot of tasks in parallel?

The only way of doing this is to have a few asyncio OS processes (because of the GIL we can't implement M:N scheduling in a single Python process).  So it's not going to happen in the foreseeable future :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:06:20 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 22 Mar 2018 18:06:20 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521741980.37.0.467229070634.issue33118@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

> 'events.AbstractEventLoop.run_one_step()'

> This is highly unlikely to ever happen.

Sure, I can see how that could be a problem with other underlying implementations, such as Twisted reactor. Just wishful thinking :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:16:21 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 22 Mar 2018 18:16:21 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521742581.84.0.467229070634.issue33118@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

I'll have to settle for `set_write_buffer_limits(0, 0)` for my blocking wrapper case.

I think that 'write_buffer_drained' callback is a good idea, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:26:05 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Thu, 22 Mar 2018 18:26:05 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521743165.25.0.467229070634.issue33118@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

Yet another paradigm is the likes of `GSource` in gnome's glib. GSource "tasks" added to the event loop are polled by the event loop for readiness before the event loop blocks on select/epoll/etc.. The ones that are ready are removed from the loop and their callbacks are dispatched.

I suppose that it would also be difficult to get buy-in for a feature like this from the different frameworks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:39:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 18:39:18 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521743958.34.0.467229070634.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The simplest way is to try passing the limit as a tuple

    resource.setrlimit(resource.RLIMIT_CPU, (1000000, 1000000))

and skip the test if it failed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:47:34 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Thu, 22 Mar 2018 18:47:34 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521744454.53.0.467229070634.issue6083@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

Thanks! I also thought about this simplest way. What about this:

diff --git a/Python/Lib/test/test_resource.py b/Python/Lib/test/test_resource.py
index de29d3b..bec4440 100644
--- a/Python/Lib/test/test_resource.py
+++ b/Python/Lib/test/test_resource.py
@@ -102,16 +102,21 @@ class ResourceTest(unittest.TestCase):
 
     # Issue 6083: Reference counting bug
     def test_setrusage_refcount(self):
+        howmany = 1000000
         try:
             limits = resource.getrlimit(resource.RLIMIT_CPU)
         except AttributeError:
             self.skipTest('RLIMIT_CPU not available')
+        try:
+            resource.setrlimit(resource.RLIMIT_CPU, (howmany, howmany))
+        except _:
+            self.skipTest('Setting RLIMIT_CPU not possible')
         class BadSequence:
             def __len__(self):
                 return 2
             def __getitem__(self, key):
                 if key in (0, 1):
-                    return len(tuple(range(1000000)))
+                    return len(tuple(range(howmany)))
                 raise IndexError
 
         resource.setrlimit(resource.RLIMIT_CPU, BadSequence())

What should I write instead of _?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:48:20 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Thu, 22 Mar 2018 18:48:20 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521744500.43.0.467229070634.issue6083@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

And will the next call be effective (do anything), if we have already set the limit with the testing call?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 14:58:50 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 22 Mar 2018 18:58:50 +0000
Subject: [issue33118] No clean way to get notified when a Transport's write
 buffer empties out
In-Reply-To: <1521700811.42.0.467229070634.issue33118@psf.upfronthosting.co.za>
Message-ID: <1521745130.27.0.467229070634.issue33118@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I suppose that it would also be difficult to get buy-in for a feature like this from the different frameworks?

Maybe :)  Ideally, asyncio programs should not depend on how exactly tasks are scheduled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33118>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:08:06 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Mar 2018 20:08:06 +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: <1521749286.73.0.467229070634.issue32505@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5939
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:23:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Mar 2018 20:23:31 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1521750211.49.0.467229070634.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

LGTM.

> What should I write instead of _?

(ValueError, OSError)

> And will the next call be effective (do anything), if we have already set the limit with the testing call?

This doesn't matter. We test that it doesn't crash when parse arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:28:51 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Mar 2018 20:28:51 +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: <1521750531.43.0.467229070634.issue32505@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 56970b8ce9d23269d20a76f13c80e670c856ba7f by Eric V. Smith in branch 'master':
bpo-32505: dataclasses: raise TypeError if a member variable is of type Field, but doesn't have a type annotation. (GH-6192)
https://github.com/python/cpython/commit/56970b8ce9d23269d20a76f13c80e670c856ba7f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:29:16 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 22 Mar 2018 20:29:16 +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: <1521750556.41.0.467229070634.issue32505@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5940

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:46:11 2018
From: report at bugs.python.org (ppperry)
Date: Thu, 22 Mar 2018 20:46:11 +0000
Subject: [issue30953] Fatal python error when jumping into except clause
In-Reply-To: <1500326698.05.0.0587216442362.issue30953@psf.upfronthosting.co.za>
Message-ID: <1521751571.65.0.467229070634.issue30953@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

... with a bad error message, because there are no finally blocks in the code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30953>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:53:35 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 22 Mar 2018 20:53:35 +0000
Subject: [issue30071] Duck-typing inspect.isfunction()
In-Reply-To: <1492169694.13.0.728047753298.issue30071@psf.upfronthosting.co.za>
Message-ID: <1521752015.26.0.467229070634.issue30071@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

See https://mail.python.org/pipermail/python-ideas/2018-March/049398.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30071>
_______________________________________

From report at bugs.python.org  Thu Mar 22 16:59:08 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 22 Mar 2018 20:59:08 +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: <1521752348.62.0.467229070634.issue32505@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3b4c6b16c597aa2356f5658dd67da7dcd4434038 by Miss Islington (bot) in branch '3.7':
bpo-32505: dataclasses: raise TypeError if a member variable is of type Field, but doesn't have a type annotation. (GH-6192)
https://github.com/python/cpython/commit/3b4c6b16c597aa2356f5658dd67da7dcd4434038


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 17:00:25 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Mar 2018 21:00: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: <1521752425.34.0.467229070634.issue32505@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/issue32505>
_______________________________________

From report at bugs.python.org  Thu Mar 22 18:17:11 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 22 Mar 2018 22:17:11 +0000
Subject: [issue33124] Lazy execution of module bytecode
Message-ID: <1521757031.84.0.467229070634.issue33124@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

This is an experimental patch that implements lazy execution of top-level definitions in modules (functions, classes, imports, global constants).  See Tools/lazy_compile/README.txt for details.

----------
components: Interpreter Core
messages: 314294
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: Lazy execution of module bytecode
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33124>
_______________________________________

From report at bugs.python.org  Thu Mar 22 18:18:49 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 22 Mar 2018 22:18:49 +0000
Subject: [issue33124] Lazy execution of module bytecode
In-Reply-To: <1521757031.84.0.467229070634.issue33124@psf.upfronthosting.co.za>
Message-ID: <1521757129.74.0.467229070634.issue33124@psf.upfronthosting.co.za>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
keywords: +patch
pull_requests: +5941

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33124>
_______________________________________

From report at bugs.python.org  Thu Mar 22 18:45:15 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 22 Mar 2018 22:45:15 +0000
Subject: [issue33124] Lazy execution of module bytecode
In-Reply-To: <1521757031.84.0.467229070634.issue33124@psf.upfronthosting.co.za>
Message-ID: <1521758715.6.0.467229070634.issue33124@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/issue33124>
_______________________________________

From report at bugs.python.org  Thu Mar 22 19:07:20 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Mar 2018 23:07:20 +0000
Subject: [issue33124] Lazy execution of module bytecode
In-Reply-To: <1521757031.84.0.467229070634.issue33124@psf.upfronthosting.co.za>
Message-ID: <1521760040.66.0.467229070634.issue33124@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33124>
_______________________________________

From report at bugs.python.org  Thu Mar 22 19:09:21 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Mar 2018 23:09:21 +0000
Subject: [issue33119] python sys.argv argument parsing not clear
In-Reply-To: <1521710473.18.0.467229070634.issue33119@psf.upfronthosting.co.za>
Message-ID: <1521760161.34.0.467229070634.issue33119@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33119>
_______________________________________

From report at bugs.python.org  Thu Mar 22 19:27:53 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 22 Mar 2018 23:27:53 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1521761273.1.0.467229070634.issue27212@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +patch
pull_requests: +5942
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Thu Mar 22 21:03:32 2018
From: report at bugs.python.org (Steven Noonan)
Date: Fri, 23 Mar 2018 01:03:32 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
Message-ID: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>


New submission from Steven Noonan <steven at uplinklabs.net>:

The Windows 10 ARM64 release is out along with a bunch of ARM64 devices. This version of Windows has full support for building native Win32 applications (this isn't just some rehash of Windows RT). It also can run x86 (but not x86_64) apps under a transparent emulation layer.

I would like to see a native build of Python on Windows 10 ARM64.

I did some very basic work to get it compiling (add 10.0.16299.0 as DefaultWindowsSDKVersion, add WindowsSDKDesktopARM64Support property). But there's still a lot missing: ssl, tk, and ctypes don't build.

ssl/ctypes have some assembly that needs writing/porting.

tk has some kind of build failure with the newer Windows SDK: https://core.tcl.tk/tk/tktview?name=3d34589aa0

----------
components: Windows
messages: 314295
nosy: Steven Noonan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows 10 ARM64 platform support
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Thu Mar 22 21:07:22 2018
From: report at bugs.python.org (Steven Noonan)
Date: Fri, 23 Mar 2018 01:07:22 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1521767242.21.0.467229070634.issue33125@psf.upfronthosting.co.za>


Steven Noonan <steven at uplinklabs.net> added the comment:

Oh, another change I had to make was remove all the BaseAddress elements in the Link sections. The linker complains if these are used (the lower 4GB of memory are apparently reserved for the x86 emulation). Also, from what I was told by someone over at Microsoft, the BaseAddress options don't do anything useful on modern Windows versions unless you build with -fixed as well, because everything gets relocated anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Thu Mar 22 22:26:43 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Mar 2018 02:26:43 +0000
Subject: [issue23434] support encoded filename in Content-Disposition for HTTP
 in cgi.FieldStorage
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1521772003.58.0.467229070634.issue23434@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't read the http rfcs, but my understanding is that they follow the MIME standards, and the email library already has code to do proper parsing and decoding of encoded filenames in Content-Disposition headers.  It should be possible to call that code for this use case (the http libraries already depend on the email libraries, although I'm not sure if cgi itself does currently).  There may be additional considerations involved in fully supporting the http RFCs, but to determine that someone will need to read both and understand them, which is not a small undertaking :)

In the meantime, I'm pretty sure that using the existing mime header parsing code in the email library (see email.headerregistry) will provide better parsing than the only-handles-simple-cases heuristic in your PR.  Granted, I don't think you have to deal with multi-part headers in http, but I vaguely remember that there are other subtleties not handled by a simple split on '.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23434>
_______________________________________

From report at bugs.python.org  Fri Mar 23 03:29:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 07:29:40 +0000
Subject: [issue30953] Fatal python error when jumping into except clause
In-Reply-To: <1500326698.05.0.0587216442362.issue30953@psf.upfronthosting.co.za>
Message-ID: <1521790180.24.0.467229070634.issue30953@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5943
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30953>
_______________________________________

From report at bugs.python.org  Fri Mar 23 03:30:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 07:30:51 +0000
Subject: [issue30953] Fatal python error when jumping into except clause
In-Reply-To: <1500326698.05.0.0587216442362.issue30953@psf.upfronthosting.co.za>
Message-ID: <1521790251.8.0.467229070634.issue30953@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30953>
_______________________________________

From report at bugs.python.org  Fri Mar 23 04:17:04 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 23 Mar 2018 08:17:04 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521793024.77.0.467229070634.issue33115@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The problem of the example is: all 10000 tasks starts in the same moment, than waits for 1 sec each and at the same moment every task clones itself.

Adding a jitter into example can solve the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Fri Mar 23 05:03:55 2018
From: report at bugs.python.org (Marat Sharafutdinov)
Date: Fri, 23 Mar 2018 09:03:55 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521795835.02.0.467229070634.issue33115@psf.upfronthosting.co.za>


Marat Sharafutdinov <decaz89 at gmail.com> added the comment:

Concerning the example adding a jitter is useful, thanks!

But anyway in case there will be something not constant as sleeping for 1 sec is, the problem will continue to appear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Fri Mar 23 05:04:26 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 23 Mar 2018 09:04:26 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521795866.36.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +5944

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Fri Mar 23 05:19:37 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 23 Mar 2018 09:19:37 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521796777.79.0.467229070634.issue32999@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset c65bf3fe4a2bde424b79e350f36b7aaa3f6476f6 by INADA Naoki in branch 'master':
bpo-32999: ast: Convert useless check to assert (GH-6197)
https://github.com/python/cpython/commit/c65bf3fe4a2bde424b79e350f36b7aaa3f6476f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Fri Mar 23 05:20:00 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 09:20:00 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521796800.5.0.467229070634.issue32999@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5945

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Fri Mar 23 05:43:17 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 09:43:17 +0000
Subject: [issue32999] issubclass(obj, abc.ABC) causes a segfault
In-Reply-To: <1520266781.34.0.467229070634.issue32999@psf.upfronthosting.co.za>
Message-ID: <1521798197.03.0.467229070634.issue32999@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c71edab15d023360388da8360700d419b5f48c81 by Miss Islington (bot) in branch '3.7':
bpo-32999: ast: Convert useless check to assert (GH-6197)
https://github.com/python/cpython/commit/c71edab15d023360388da8360700d419b5f48c81


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32999>
_______________________________________

From report at bugs.python.org  Fri Mar 23 05:59:02 2018
From: report at bugs.python.org (Eric Toombs)
Date: Fri, 23 Mar 2018 09:59:02 +0000
Subject: [issue33093] Fatal error on SSL transport
In-Reply-To: <1521308170.69.0.467229070634.issue33093@psf.upfronthosting.co.za>
Message-ID: <1521799142.91.0.467229070634.issue33093@psf.upfronthosting.co.za>


Eric Toombs <ewtoombs at gmail.com> added the comment:

Well, that looks good! Looking forward to 3.6.5!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33093>
_______________________________________

From report at bugs.python.org  Fri Mar 23 07:20:59 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 23 Mar 2018 11:20:59 +0000
Subject: [issue33093] Fatal error on SSL transport
In-Reply-To: <1521308170.69.0.467229070634.issue33093@psf.upfronthosting.co.za>
Message-ID: <1521804059.88.0.467229070634.issue33093@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33093>
_______________________________________

From report at bugs.python.org  Fri Mar 23 07:22:56 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 23 Mar 2018 11:22:56 +0000
Subject: [issue33120] infinite loop in inspect.unwrap(unittest.mock.call)
In-Reply-To: <1521725801.92.0.467229070634.issue33120@psf.upfronthosting.co.za>
Message-ID: <1521804176.31.0.467229070634.issue33120@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

This is a dupe of https://bugs.python.org/issue25532

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33120>
_______________________________________

From report at bugs.python.org  Fri Mar 23 08:19:37 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 23 Mar 2018 12:19:37 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521807577.3.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I cannot reproduce the problem on macOS 10.13.3 with python 3.6 (but haven't spent much time on this).

The combination of GUI code with multiprocessing is a known source of problems on macOS, the system libraries are hostile to that.

Changing the start method from "fork" to "spawn" or "forkserver" should help with this, using multiprocessing.set_start_method(). This should be changed before doing anything that might Apple system frameworks related to GUIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Fri Mar 23 08:34:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 12:34:43 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521808483.84.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 702f8f3611bc49b73772cce2b9b041bd11ff9b35 by Serhiy Storchaka in branch 'master':
bpo-33041: Rework compiling an "async for" loop. (#6142)
https://github.com/python/cpython/commit/702f8f3611bc49b73772cce2b9b041bd11ff9b35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Fri Mar 23 08:35:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 12:35:35 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521808535.53.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b9744e924ca07ba7db977e5958b91cd8db565632 by Serhiy Storchaka in branch '3.7':
bpo-33041: Fixed jumping if the function contains an "async for" loop. (GH-6154)
https://github.com/python/cpython/commit/b9744e924ca07ba7db977e5958b91cd8db565632


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Fri Mar 23 08:46:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 12:46:47 +0000
Subject: [issue30953] Fatal python error when jumping into except clause
In-Reply-To: <1500326698.05.0.0587216442362.issue30953@psf.upfronthosting.co.za>
Message-ID: <1521809207.54.0.467229070634.issue30953@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 397466dfd905b5132f1c831cd9dff3ecc40b3218 by Serhiy Storchaka in branch 'master':
bpo-30953: Improve error messages and add tests for jumping (GH-6196)
https://github.com/python/cpython/commit/397466dfd905b5132f1c831cd9dff3ecc40b3218


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30953>
_______________________________________

From report at bugs.python.org  Fri Mar 23 08:48:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 12:48:12 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521809292.27.0.467229070634.issue33041@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5946

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Fri Mar 23 09:10:04 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 23 Mar 2018 13:10:04 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1521810604.08.0.467229070634.issue33125@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I'd like to see this as well, but just to set expectations, it can't be any earlier than 3.8 at this stage (for upstream support), and we need access to some real hardware to regularly run tests on.

That said, most of the changes you describe are on my list of things to do anyway. If you've done them and would like to submit a pull request (against master) then we'll happily take them now and include them in 3.7. But you'll still need to build the ARM versions yourself.

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Mar 23 09:26:14 2018
From: report at bugs.python.org (Steven Noonan)
Date: Fri, 23 Mar 2018 13:26:14 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1521811574.87.0.467229070634.issue33125@psf.upfronthosting.co.za>


Steven Noonan <steven at uplinklabs.net> added the comment:

I originally tagged this issue against 3.6 just because that's what I was attempting to build. But I'm not super concerned about what release these changes actually land in, I can always backport it to my own builds (and at my own risk).

Even though I'm super interested in seeing these changes done, I'm not sure I'm the right person to do the heavy lifting on this. I don't know if the seemingly undocumented (?) Windows ARM64 ABI matches the well-documented Linux AArch64 ABI, for example. If it does match, that would make porting the asm bits pretty straightforward (mostly just translating GNU assembler AT&T syntax to MASM, I suppose). I could do that. But if it doesn't match then I'd probably need to dig into ARM architecture manuals. Someone else could likely do it in their sleep.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Mar 23 09:45:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 13:45:40 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521812740.03.0.467229070634.issue33041@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 18d7edf32e6832a818621cb8cb3d144928eca232 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-33041: Fixed jumping if the function contains an "async for" loop. (GH-6154). (GH-6199)
https://github.com/python/cpython/commit/18d7edf32e6832a818621cb8cb3d144928eca232


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33041>
_______________________________________

From report at bugs.python.org  Fri Mar 23 09:47:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 13:47:54 +0000
Subject: [issue33041] Issues with "async for"
In-Reply-To: <1520687441.8.0.467229070634.issue33041@psf.upfronthosting.co.za>
Message-ID: <1521812874.98.0.467229070634.issue33041@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/issue33041>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:11:21 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 23 Mar 2018 16:11:21 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1521821481.51.0.467229070634.issue33125@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Ideally, all of the changes necessary in OpenSSL, libffi, and Tcl/Tk will happen upstream and we'll just update to new versions of them.  We have PR 3806 in progress to extract libffi from our repo and treat it just as any other external dependency on Windows, but neither Steve nor I have had a chance to work on it in quite a long time.  That will probably be a prerequisite for properly supporting ARM64 Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:21:29 2018
From: report at bugs.python.org (Steven Downum)
Date: Fri, 23 Mar 2018 16:21:29 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1521822089.85.0.467229070634.issue33125@psf.upfronthosting.co.za>


Change by Steven Downum <devilaether at gmail.com>:


----------
nosy: +steven.downum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:32:47 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Mar 2018 16:32:47 +0000
Subject: [issue33092] The bytecode for f-string formatting is inefficient.
In-Reply-To: <1521289990.47.0.467229070634.issue33092@psf.upfronthosting.co.za>
Message-ID: <1521822767.04.0.467229070634.issue33092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  I would suggest that a simper interpreter with smaller, simpler bytecodes is a worthy goal in itself.

+1 from me.  Though I'm curious about performance changes as well :-)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33092>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:34:26 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Mar 2018 16:34:26 +0000
Subject: [issue33097] concurrent futures Executors accept tasks after
 interpreter shutdown
In-Reply-To: <1521391273.18.0.467229070634.issue33097@psf.upfronthosting.co.za>
Message-ID: <1521822866.17.0.467229070634.issue33097@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tomMoral
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33097>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:35:05 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Mar 2018 16:35:05 +0000
Subject: [issue33097] concurrent futures Executors accept tasks after
 interpreter shutdown
In-Reply-To: <1521391273.18.0.467229070634.issue33097@psf.upfronthosting.co.za>
Message-ID: <1521822905.1.0.467229070634.issue33097@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for spotting this.  I will take a look soon, unless someone beats me to it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33097>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:40:41 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 23 Mar 2018 16:40:41 +0000
Subject: [issue31639] http.server and SimpleHTTPServer hang after a few
 requests
In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za>
Message-ID: <1521823241.16.0.467229070634.issue31639@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 8bcfa02e4b1b65634e526e197588bc600674c80b by Julien Palard in branch 'master':
bpo-31639: Use threads in http.server module. (GH-5018)
https://github.com/python/cpython/commit/8bcfa02e4b1b65634e526e197588bc600674c80b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31639>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:49:06 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Mar 2018 16:49:06 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
Message-ID: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The following C functions are available for C code but not documented:
- PyBuffer_ToContiguous()
- PyBuffer_FromContiguous()
- PyObject_CopyData()

I am not sure how to describe those functions myself.

----------
assignee: docs at python
components: Documentation
messages: 314315
nosy: docs at python, pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Some C buffer protocol APIs not documented
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:49:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 16:49:44 +0000
Subject: [issue31639] http.server and SimpleHTTPServer hang after a few
 requests
In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za>
Message-ID: <1521823784.08.0.467229070634.issue31639@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5947

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31639>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:52:21 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 16:52:21 +0000
Subject: [issue31639] http.server and SimpleHTTPServer hang after a few
 requests
In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za>
Message-ID: <1521823941.39.0.467229070634.issue31639@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5948

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31639>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:52:59 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 23 Mar 2018 16:52:59 +0000
Subject: [issue31639] http.server and SimpleHTTPServer hang after a few
 requests
In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za>
Message-ID: <1521823979.27.0.467229070634.issue31639@psf.upfronthosting.co.za>


Change by Julien Palard <julien+python at palard.fr>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31639>
_______________________________________

From report at bugs.python.org  Fri Mar 23 12:57:13 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Mar 2018 16:57:13 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1521824233.23.0.467229070634.issue33081@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for reporting this.  I agree this is a real issue, but it doesn't exist on Python 3 anymore:

>>> q = multiprocessing.Queue()
>>> q.put(1)
>>> q.get()
1
>>> threading.enumerate()
[<_MainThread(MainThread, started 139978753529600)>, <Thread(QueueFeederThread, started daemon 139978667779840)>]
>>> q.close()
>>> threading.enumerate()
[<_MainThread(MainThread, started 139978753529600)>]
>>> os.getpid()
17318

And in another terminal:

$ ls -la /proc/17318/fd
total 0
dr-x------ 2 antoine antoine  0 mars  23 17:51 .
dr-xr-xr-x 9 antoine antoine  0 mars  23 17:51 ..
lrwx------ 1 antoine antoine 64 mars  23 17:52 0 -> /dev/pts/8
lrwx------ 1 antoine antoine 64 mars  23 17:52 1 -> /dev/pts/8
lrwx------ 1 antoine antoine 64 mars  23 17:51 2 -> /dev/pts/8


I'm uninterested in fixing this on Python 2, so I'm closing.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Fri Mar 23 13:18:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 17:18:04 +0000
Subject: [issue33092] The bytecode for f-string formatting is inefficient.
In-Reply-To: <1521289990.47.0.467229070634.issue33092@psf.upfronthosting.co.za>
Message-ID: <1521825484.48.0.467229070634.issue33092@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I wouldn't say this more efficient. Instead one instruction you would need to execute two instructions.

If I implemented f-string formatting I would add four simple opcodes for str(), repr(), ascii() and format(). But Eric merged them all in the single opcode with complex argument. While this looks more complicated and less extensible, it is more efficient.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33092>
_______________________________________

From report at bugs.python.org  Fri Mar 23 14:18:48 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Fri, 23 Mar 2018 18:18:48 +0000
Subject: [issue32234] Add context management to mailbox.Mailbox
In-Reply-To: <1521725041.54.0.467229070634.issue32234@psf.upfronthosting.co.za>
Message-ID: <CAOy+up4R_2=souHAC2z9VX4gU1KwReQG64v+gCizsirk1OmirA@mail.gmail.com>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

I don't know about something blocking the merge. I sent a message to Barry
on Github the 3th january but perhaps it was a wrong timing (too soon after
new year).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32234>
_______________________________________

From report at bugs.python.org  Fri Mar 23 14:52:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 18:52:41 +0000
Subject: [issue32234] Add context management to mailbox.Mailbox
In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za>
Message-ID: <1521831161.37.0.467229070634.issue32234@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is closing a mailbox in __exit__ the most desirable operation?

In the last example on https://docs.python.org/3/library/mailbox.html#examples inbox is locked and unlocked multiple times. The with statement couldn't be used here.

On https://pymotw.com/3/mailbox/ some examples use the idiom

    mbox = ...
    mbox.lock()
    try:
        ...
    finally:
        mbox.unlock()

and others use the idiom

    mbox = ...
    mbox.lock()
    try:
        ...
    finally:
        mbox.flush()
        mbox.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32234>
_______________________________________

From report at bugs.python.org  Fri Mar 23 15:01:39 2018
From: report at bugs.python.org (Charles)
Date: Fri, 23 Mar 2018 19:01:39 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
Message-ID: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>


New submission from Charles <chdiza at gmail.com>:

On macOS I could build python 2.7.14 with libressl 2.6.4 without any problems.

If I try to build that same version of python with libressl 2.7.0, I get the failure pasted in below.

/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:141:12: error: static declaration of 'X509_NAME_ENTRY_set' follows non-static declaration
static int X509_NAME_ENTRY_set(const X509_NAME_ENTRY *ne)
           ^
/usr/local/ssl/include/openssl/x509.h:1139:6: note: previous declaration is here
int             X509_NAME_ENTRY_set(const X509_NAME_ENTRY *ne);
                ^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:153:25: error: static declaration of 'SSL_CTX_get_default_passwd_cb' follows non-static declaration
static pem_password_cb *SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx)
                        ^
/usr/local/ssl/include/openssl/ssl.h:1368:18: note: previous declaration is here
pem_password_cb *SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx);
                 ^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:158:14: error: static declaration of 'SSL_CTX_get_default_passwd_cb_userdata' follows non-static declaration
static void *SSL_CTX_get_default_passwd_cb_userdata(SSL_CTX *ctx)
             ^
/usr/local/ssl/include/openssl/ssl.h:1370:7: note: previous declaration is here
void *SSL_CTX_get_default_passwd_cb_userdata(SSL_CTX *ctx);
      ^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:163:12: error: static declaration of 'X509_OBJECT_get_type' follows non-static declaration
static int X509_OBJECT_get_type(X509_OBJECT *x)
           ^
/usr/local/ssl/include/openssl/x509_vfy.h:428:5: note: previous declaration is here
int X509_OBJECT_get_type(const X509_OBJECT *a);
    ^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:168:14: error: static declaration of 'X509_OBJECT_get0_X509' follows non-static declaration
static X509 *X509_OBJECT_get0_X509(X509_OBJECT *x)
             ^
/usr/local/ssl/include/openssl/x509_vfy.h:430:7: note: previous declaration is here
X509 *X509_OBJECT_get0_X509(const X509_OBJECT *xo);
      ^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:173:31: error: static declaration of 'X509_STORE_get0_objects' follows non-static declaration
static STACK_OF(X509_OBJECT) *X509_STORE_get0_objects(X509_STORE *store) {
                              ^
/usr/local/ssl/include/openssl/x509_vfy.h:438:24: note: previous declaration is here
STACK_OF(X509_OBJECT) *X509_STORE_get0_objects(X509_STORE *xs);
                       ^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:177:27: error: static declaration of 'X509_STORE_get0_param' follows non-static declaration
static X509_VERIFY_PARAM *X509_STORE_get0_param(X509_STORE *store)
                          ^
/usr/local/ssl/include/openssl/x509_vfy.h:450:20: note: previous declaration is here
X509_VERIFY_PARAM *X509_STORE_get0_param(X509_STORE *ctx);
                   ^
7 errors generated.

----------
assignee: christian.heimes
components: SSL
messages: 314320
nosy: chdiza, christian.heimes
priority: normal
severity: normal
status: open
title: Python 2.7.14 won't build ssl module with Libressl 2.7.0
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Fri Mar 23 15:54:17 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 23 Mar 2018 19:54:17 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521834857.91.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for the report. LibreSSL 2.7 introduced OpenSSL 1.1 API methods. I already know about the issue and have a pending fix for it on my disk. I'll push it as soon as 2.7.1 is out.

2.7.0 is a beta release. The latest stable is 2.6.4.

----------
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:05:53 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 23 Mar 2018 20:05:53 +0000
Subject: [issue32287] Import of _pyio module failed on cygwin
In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za>
Message-ID: <1521835553.28.0.467229070634.issue32287@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
superseder:  -> _pyio module broken on Cygwin / setmode not usable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32287>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:25:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Mar 2018 20:25:41 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1521836741.47.0.467229070634.issue33023@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 6099 changes error message "can't pickle SSLContext objects" to "cannot serialize SSLContext object", right? Wouldn't be better to change the standard error message instead?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:27:25 2018
From: report at bugs.python.org (Charles)
Date: Fri, 23 Mar 2018 20:27:25 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521836845.26.0.467229070634.issue33127@psf.upfronthosting.co.za>


Charles <chdiza at gmail.com> added the comment:

I'm not sure it's a beta release.  I think they just forgot to update on their homepage what the latest stable is.

Nothing on the releases page or the release notes says it's a beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:30:59 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Mar 2018 20:30:59 +0000
Subject: [issue33093] Fatal error on SSL transport
In-Reply-To: <1521308170.69.0.467229070634.issue33093@psf.upfronthosting.co.za>
Message-ID: <1521837059.0.0.467229070634.issue33093@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the report and for the analysis!  Closing as duplicate.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Skip sending/receiving after SSL transport closing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33093>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:31:29 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 20:31:29 +0000
Subject: [issue31639] http.server and SimpleHTTPServer hang after a few
 requests
In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za>
Message-ID: <1521837089.33.0.467229070634.issue31639@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f8d2c3cf5f62f0c259b2bf35c631353d22cf1d08 by Miss Islington (bot) in branch '3.7':
bpo-31639: Use threads in http.server module. (GH-5018)
https://github.com/python/cpython/commit/f8d2c3cf5f62f0c259b2bf35c631353d22cf1d08


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31639>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:39:44 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Mar 2018 20:39:44 +0000
Subject: [issue33122] ftplib: FTP_TLS seems to have problems with sites that
 close the encrypted channel themselfes
In-Reply-To: <1521728978.52.0.467229070634.issue33122@psf.upfronthosting.co.za>
Message-ID: <1521837584.51.0.467229070634.issue33122@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33122>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:40:00 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 23 Mar 2018 20:40:00 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521837600.4.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The homepage is correct. The last stable release is 2.6.4. I know this first hand from a LibreSSL developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Fri Mar 23 16:57:30 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 23 Mar 2018 20:57:30 +0000
Subject: [issue33122] ftplib: FTP_TLS seems to have problems with sites that
 close the encrypted channel themselfes
In-Reply-To: <1521728978.52.0.467229070634.issue33122@psf.upfronthosting.co.za>
Message-ID: <1521838650.53.0.467229070634.issue33122@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Please paste your code and traceback message. Also what's the remote FTP server you're connected to? You should be able to see it in the welcome message (you can set FTP_TLS.debugging to True).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33122>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:08:39 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Mar 2018 21:08:39 +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: <1521839319.51.0.467229070634.issue32387@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Not sure if this has missed the 3.7 train, but bumping this to check if the discussion on distutils-sig ever occurred and what the  result of it was. (Otherwise the PR just needs a news entry and it should be ready.)

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:20:26 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 23 Mar 2018 21:20:26 +0000
Subject: [issue31793] Allow to specialize smart quotes in documentation
 translations
In-Reply-To: <1508060988.99.0.213398074469.issue31793@psf.upfronthosting.co.za>
Message-ID: <1521840026.21.0.467229070634.issue31793@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Reopening as smart quotes is still a source of bugs in Japanese translation, see: https://github.com/python/docsbuild-scripts/issues/32#issuecomment-375801129

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31793>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:22:28 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 23 Mar 2018 21:22:28 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1521840148.27.0.467229070634.issue33114@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Something along the lines of: "For a fixed seed, random.sample(population, k)
> is not guaranteed to return the same samples for different values of k."

In a way, the proposed wording succinctly directly addresses the problem you had.  So, it would seem like a reasonable suggestion.  On the other hand, it would be easy for others who haven't had this problem to have a hard time figuring out what it means (when should they be worried, what should be avoided, why is it a concern at all, what to do about it).

In general, the docs are worded in an affirmative manner (here's what something does, here's what it is for, and here is how to use it correctly).  In this case, the docs already indicate the intended way to address this use case: "the resulting list is in selection order so that all sub-slices will also be valid random samples.  This allows raffle winners (the sample) to be partitioned into grand prize and second place winners (the subslices)."

Perhaps there could be an algorithmic note, "internally, sample() shifts selection algorithms depending on the proportion of the population being sampled".  However, this would be unusual -- we don't usually document implementation details.  Numpy[1] and R[2] make no mention of the internals.  Julia[3] does discuss the algorithms but primarily from an efficiency point-of-view rather than as a usage note.

Perhaps it may be best to leave this alone rather than adding a note that may itself create confusion and worry.  AFAICT, this hasn't come up before in the 15 year history of random.sample(), not even a StackOverflow question.

[1] https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.random.choice.html
[2] https://www.rdocumentation.org/packages/base/versions/3.4.3/topics/sample
[3] http://juliastats.github.io/StatsBase.jl/stable/sampling.html#Sampling-API-1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:26:38 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Mar 2018 21:26:38 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1521840398.19.0.467229070634.issue27428@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:


New changeset 5cbb84106efefd200933aa31e22abf39267d2557 by Brett Cannon (Himanshu Lakhara) in branch 'master':
bpo-27428: Fix WindowsRegistryFinder documentation to list appropriate ABC (GH-6061)
https://github.com/python/cpython/commit/5cbb84106efefd200933aa31e22abf39267d2557


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:27:28 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 23 Mar 2018 21:27:28 +0000
Subject: [issue32358] json.dump: fp must be a text file object
In-Reply-To: <1513578286.44.0.213398074469.issue32358@psf.upfronthosting.co.za>
Message-ID: <1521840448.0.0.467229070634.issue32358@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

This is already documented in the json.dump() documentation:

    The json module always produces str objects, not bytes objects.
    Therefore, fp.write() must support str input.

Note that the traceback you've posted doesn't have anything to do with the json module and it's expected:

    >>> f = open('/tmp/t.json', 'wb')
    >>> f.write('foo')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: a bytes-like object is required, not 'str'

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32358>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:27:50 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 21:27:50 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1521840470.87.0.467229070634.issue27428@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5949

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:28:09 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 23 Mar 2018 21:28:09 +0000
Subject: [issue32362] multiprocessing.connection.Connection misdocumented as
 multiprocessing.Connection
In-Reply-To: <1513592247.3.0.213398074469.issue32362@psf.upfronthosting.co.za>
Message-ID: <1521840489.63.0.467229070634.issue32362@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32362>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:28:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 21:28:44 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1521840524.63.0.467229070634.issue27428@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:40:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Mar 2018 21:40:50 +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: <1521841250.78.0.467229070634.issue32387@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

As far as I know, it has not been discussed elsewhere and I think the potential for breaking third-party distributions is too high to risk making this change this late in the release cycle, independent of Steve's concerns in msg308878.  Unless someone can dispel those concerns prior to the imminent 3.7.0b3 ABI freeze, I think this should be deferred to 3.8.

----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32387>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:41:28 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 21:41:28 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1521841288.58.0.467229070634.issue27428@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 45738ede5ac8507b88b35fb0d6e2806a7b2e2efc by Miss Islington (bot) in branch '3.7':
bpo-27428: Fix WindowsRegistryFinder documentation to list appropriate ABC (GH-6061)
https://github.com/python/cpython/commit/45738ede5ac8507b88b35fb0d6e2806a7b2e2efc


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:44:56 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 23 Mar 2018 21:44:56 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521841496.61.0.467229070634.issue33061@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset ac5602746ed39ca6591e98e062e587121ac71371 by Ivan Levkivskyi in branch '3.7':
bpo-33061: Add missing 'NoReturn' to __all__ in typing.py (GH-6127) (#6162)
https://github.com/python/cpython/commit/ac5602746ed39ca6591e98e062e587121ac71371


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:47:40 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 23 Mar 2018 21:47:40 +0000
Subject: [issue33061] NoReturn missing from __all__ in typing.py
In-Reply-To: <1521222458.47.0.467229070634.issue33061@psf.upfronthosting.co.za>
Message-ID: <1521841660.62.0.467229070634.issue33061@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

The typing repo PR is not merged yet, but I am closing this here, the remainder is tracked in typing repo.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33061>
_______________________________________

From report at bugs.python.org  Fri Mar 23 17:50:14 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 23 Mar 2018 21:50:14 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1521841814.95.0.467229070634.issue27428@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 643a781188539de038745d23d0e8e5a03b781209 by Miss Islington (bot) in branch '3.6':
bpo-27428: Fix WindowsRegistryFinder documentation to list appropriate ABC (GH-6061)
https://github.com/python/cpython/commit/643a781188539de038745d23d0e8e5a03b781209


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Fri Mar 23 18:27:31 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Mar 2018 22:27:31 +0000
Subject: [issue27428] Document WindowsRegistryFinder inherits from
 MetaPathFinder
In-Reply-To: <1467326072.76.0.431868228595.issue27428@psf.upfronthosting.co.za>
Message-ID: <1521844051.05.0.467229070634.issue27428@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27428>
_______________________________________

From report at bugs.python.org  Fri Mar 23 18:53:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Mar 2018 22:53:09 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1521845589.96.0.467229070634.issue33096@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This was initially reported in pydev thread "ttk.Treeview.insert() does not allow to insert item with iid=0" on 2018/3/16.  Igor, you should have mentioned on the thread that you had opened a tracker issue in response.  It was only happenstance that I did not open a duplicate.

I suggested there that 'if iid:' be replaced by 'if iid is not None:' but wondered if passing '"-id" ""' in the tk.call would be a problem.  If so, that would be a reason for the expanded check and suggest 'if iid in (None, ''):" as the replacement.

MRAB responded that '' is the id of the root of the tree.  But that does not tell me if passing a duplicate iid or that particular duplicate is a problem or not.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Fri Mar 23 19:05:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Mar 2018 23:05:42 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1521846342.75.0.467229070634.issue33111@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The examples in the multiprocessing doc all put all multiprocessing calls within a "if __name__ == '__main__':" statement.  I know that this is necessary on Windows, but don't know if or when it helps on other OSes.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Fri Mar 23 19:30:41 2018
From: report at bugs.python.org (Hartmut Goebel)
Date: Fri, 23 Mar 2018 23:30:41 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
Message-ID: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>


New submission from Hartmut Goebel <h.goebel at crazy-compilers.com>:

As of Python 3.7.0b2 _frozen_importlib_external.PathFinder exists twice on sys.meta_path, and it is the same object:

$ python -S
Python 3.7.0b2 (default, Mar 22 2018, 20:09:00) 
[GCC 5.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.meta_path)
[<class '_frozen_importlib.BuiltinImporter'>,
<class '_frozen_importlib.FrozenImporter'>,
<class '_frozen_importlib_external.PathFinder'>,
<class '_frozen_importlib_external.PathFinder'>]
>>> print([id(p) for p in sys.meta_path])
[24427944, 24430216, 24517416, 24517416]
>>>

----------
components: Interpreter Core
messages: 314340
nosy: htgoebel
priority: normal
severity: normal
status: open
title: PathFinder is twice on sys.meta_path
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Fri Mar 23 19:33:17 2018
From: report at bugs.python.org (Alan Du)
Date: Fri, 23 Mar 2018 23:33:17 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
Message-ID: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>


New submission from Alan  Du <ahd2125 at columbia.edu>:

I'd like to request a new option to the `dataclasses.dataclass` decorator to make the `__init__` keyword-only.

The two use-cases I have in mind are:

(1) Using as a dataclass big-bag-of-config. In this scenario, forcing the user to specify the keywords is a lot nicer than passing in a dozen positional parameters.

(2) Having kwarg-only parameters means that inheritance and default parameters play nicely with each other again instead of raising a TypeError.

----------
components: Library (Lib)
messages: 314341
nosy: alan_du, eric.smith
priority: normal
severity: normal
status: open
title: Add kwarg-only option to dataclass
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Fri Mar 23 19:40:13 2018
From: report at bugs.python.org (Alan Du)
Date: Fri, 23 Mar 2018 23:40:13 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1521848413.24.0.467229070634.issue33129@psf.upfronthosting.co.za>


Alan  Du <ahd2125 at columbia.edu> added the comment:

If this would be accepted, I'd be happy to contribute a patch adding a `kwarg_only` option to `dataclass` (although it might take me a while since I'm not super familiar with the Python development workflow). I believe I already have the code change necessary at https://github.com/alanhdu/cpython/commit/fa35b39e5204845690ff774812f882f40b0e5f90 (although it still needs tests and documentation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Fri Mar 23 19:41:44 2018
From: report at bugs.python.org (Alan Du)
Date: Fri, 23 Mar 2018 23:41:44 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1521848504.39.0.467229070634.issue33129@psf.upfronthosting.co.za>


Alan  Du <ahd2125 at columbia.edu> added the comment:

Err... the right link would actually be https://github.com/alanhdu/cpython/tree/bpo-33129.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Fri Mar 23 20:05:44 2018
From: report at bugs.python.org (Vince Reuter)
Date: Sat, 24 Mar 2018 00:05:44 +0000
Subject: [issue33130] functools.reduce signature/docstring discordance
Message-ID: <1521849944.24.0.467229070634.issue33130@psf.upfronthosting.co.za>


New submission from Vince Reuter <vince.reuter at gmail.com>:

The signature for functools.reduce correctly refers to the collection parameter as an iterable, but the docstring refers to it as "sequence," which the input need not be and does not match the parameter name despite being italicized.

----------
assignee: docs at python
components: Documentation
messages: 314344
nosy: docs at python, vreuter
priority: normal
pull_requests: 5951
severity: normal
status: open
title: functools.reduce signature/docstring discordance
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33130>
_______________________________________

From report at bugs.python.org  Fri Mar 23 20:06:52 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Mar 2018 00:06:52 +0000
Subject: [issue33115] Asyncio loop blocks with a lot of parallel tasks
In-Reply-To: <1521647338.78.0.467229070634.issue33115@psf.upfronthosting.co.za>
Message-ID: <1521850012.17.0.467229070634.issue33115@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If the unforeseeable future arrives, someone can reopen or open a new issue.

----------
nosy: +terry.reedy
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33115>
_______________________________________

From report at bugs.python.org  Fri Mar 23 20:07:46 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Mar 2018 00:07:46 +0000
Subject: [issue33117] asyncio example uses non-existing/documented method
In-Reply-To: <1521666406.67.0.467229070634.issue33117@psf.upfronthosting.co.za>
Message-ID: <1521850066.32.0.467229070634.issue33117@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33117>
_______________________________________

From report at bugs.python.org  Fri Mar 23 20:27:08 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 24 Mar 2018 00:27:08 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1521851228.1.0.467229070634.issue33129@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Changing this to 3.8: there's not enough time to add this to 3.7.

----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Fri Mar 23 20:27:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 24 Mar 2018 00:27:22 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1521851242.58.0.467229070634.issue33129@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Fri Mar 23 20:35:22 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Sat, 24 Mar 2018 00:35:22 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1521851722.85.0.467229070634.issue33023@psf.upfronthosting.co.za>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

It would be very helpful to make a statement in SSLContext's documentation to the effect that it's not copyable. This is frankly the first time I run into a non-copyable object.I spend quite a bit of time researching this after implementing a copying strategy that failed. It would have saved me (and others...) so much time is there was a warning in SSLContext documentation about not being able to serialize/copy/deepcopy by design!

Also, making that exception message more generic (ha, I wasn't pickling anything?!) as Serhiy Storchaka suggested would be a welcome addition, but not replacement for documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Fri Mar 23 21:01:39 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 24 Mar 2018 01:01:39 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
In-Reply-To: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>
Message-ID: <1521853299.84.0.467229070634.issue33128@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the report.  git bisect result:

1abcf6700b4da6207fe859de40c6c1bada6b4fec is the first bad commit
commit 1abcf6700b4da6207fe859de40c6c1bada6b4fec
Author: Eric Snow <ericsnowcurrently at gmail.com>
Date:   Tue May 23 21:46:51 2017 -0700

    bpo-22257: Private C-API for core runtime initialization (PEP 432). (#1772)

    (patch by Nick Coghlan)

----------
nosy: +eric.snow, ncoghlan, ned.deily
stage:  -> needs patch
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Fri Mar 23 21:04:08 2018
From: report at bugs.python.org (Ned Deily)
Date: Sat, 24 Mar 2018 01:04:08 +0000
Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence
In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za>
Message-ID: <1521853448.67.0.467229070634.issue22257@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

See Issue33128: PathFinder is twice on sys.meta_path.

Also, is this issue supposed to remain open across releases?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22257>
_______________________________________

From report at bugs.python.org  Fri Mar 23 21:15:22 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Mar 2018 01:15:22 +0000
Subject: [issue33119] python sys.argv argument parsing not clear
In-Reply-To: <1521710473.18.0.467229070634.issue33119@psf.upfronthosting.co.za>
Message-ID: <1521854122.05.0.467229070634.issue33119@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Two of your 3 suggested alternatives could lead to bugs. To use your example:
 python -m mainmodule.submodule.foobar -o -b
is a convenient alternative and abbreviation for
 python .../somedir/mainmodule/submodule/foobar.py -o -b
The two invocations should give equivalent results and to the extent possible the same result.

[What might be different is the form of argv[0].  In the first case, argv[0] will be the "preferred" form of the path to the python file while in the second, it will be whatever is given.  On Windows, the difference might look like 'F:\\Python\\a\\tem2.py' versus 'f:/python/a/tem2.py']

Unless __init__.py does some evil monkeypatching, it cannot affect the main module unless imported directly or indirectly.  So its behavior should be the same whether imported before or after execution of the main module.  This means that argv must be the same either way (except for argv[0]).  So argv[0:2] must be condensed to one arg before executing __init__.  I don't see that '' is an improvement over '-m'.

Command line arguments are intended for the invoked command.  An __init__.py file is never the command unless invoked by its full path: "python somepath/__init__.py".  In such a case, sys.argv access should be within a "__name__ == '__main__':" clause or a function called therein.

----------
nosy: +terry.reedy
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33119>
_______________________________________

From report at bugs.python.org  Fri Mar 23 21:26:54 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Mar 2018 01:26:54 +0000
Subject: [issue33120] infinite loop in inspect.unwrap(unittest.mock.call)
In-Reply-To: <1521725801.92.0.467229070634.issue33120@psf.upfronthosting.co.za>
Message-ID: <1521854814.03.0.467229070634.issue33120@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Peter, please include x.y.z version with reports (and upgrade first if possible ;-).  This was apparently fixed in #25532 last year for current versions.  With 3.6.4 and 3.7.0b2 I get
Traceback (most recent call last):
  File "F:\Python\a\tem2.py", line 3, in <module>
    print(inspect.unwrap(unittest.mock.call))
  File "C:\Programs\Python37\lib\inspect.py", line 515, in unwrap
    raise ValueError('wrapper loop when unwrapping {!r}'.format(f))
ValueError: wrapper loop when unwrapping call

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> infinite loop when running inspect.unwrap over unittest.mock.call

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33120>
_______________________________________

From report at bugs.python.org  Fri Mar 23 21:29:03 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Mar 2018 01:29:03 +0000
Subject: [issue33121] recv returning 0 on closed connection not documented
In-Reply-To: <1521728108.91.0.467229070634.issue33121@psf.upfronthosting.co.za>
Message-ID: <1521854943.54.0.467229070634.issue33121@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please make a specific suggestion for a change in a specific location in the current online version of a particular doc -- the one you wish had been there already.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33121>
_______________________________________

From report at bugs.python.org  Fri Mar 23 23:11:42 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Sat, 24 Mar 2018 03:11:42 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1521861102.05.0.467229070634.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

Mark, you have some good points. I didn't fully think about the implications of my change. I undid the change to _operator_fallbacks.

I updated the tests to expect 1.0 // 1/10 to equal 9.0 and 1.0 % 1/10 to equal 0.09999999999999995. That latter number seems a bit awkward though. Can I expect the result to always come out like that, or could it depend on the hardware the test is run on? If we can't depend on that result, do you have any suggestions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Sat Mar 24 00:19:37 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Mar 2018 04:19:37 +0000
Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence
In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za>
Message-ID: <1521865177.85.0.467229070634.issue22257@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, this is the issue for making the API public, so it will stay open until PEP 432 is actually accepted.

We switched to the pre-implement-changes-as-an-internal-CPython-refactoring approach after we/I realised there was no feasible way to develop and maintain these an out of tree feature branch (with the early pay-off from the change in approach being the feasibility of implementing 3.7 changes like UTF-8 mode).

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22257>
_______________________________________

From report at bugs.python.org  Sat Mar 24 00:25:00 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Mar 2018 04:25:00 +0000
Subject: [issue33119] python sys.argv argument parsing not clear
In-Reply-To: <1521710473.18.0.467229070634.issue33119@psf.upfronthosting.co.za>
Message-ID: <1521865500.67.0.467229070634.issue33119@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is deliberate, and is covered in the documentation at https://docs.python.org/3/using/cmdline.html#cmdoption-m where it says 'If this option is given, the first element of sys.argv will be the full path to the module file (while the module file is being located, the first element will be set to "-m").'

The part in parentheses is the bit that's applicable here.

We've not going to change that, as the interpreter startup relies on checking sys.argv[0] for "-m" and "-c" in order to work out how it's expected to handle sys.path initialization.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33119>
_______________________________________

From report at bugs.python.org  Sat Mar 24 01:19:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 05:19:40 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1521868780.59.0.467229070634.issue33096@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have tested -- omitting the option and passing an empty string are treated different in Tk. Passing a duplicate iid is error. Thus the fix should be just `iid is not None`. But needed tests.

----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sat Mar 24 01:21:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 05:21:38 +0000
Subject: [issue33130] functools.reduce signature/docstring discordance
In-Reply-To: <1521849944.24.0.467229070634.issue33130@psf.upfronthosting.co.za>
Message-ID: <1521868898.08.0.467229070634.issue33130@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ncoghlan, rhettinger
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33130>
_______________________________________

From report at bugs.python.org  Sat Mar 24 01:42:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 05:42:45 +0000
Subject: [issue33006] docstring of filter function is incorrect
In-Reply-To: <1520300191.48.0.467229070634.issue33006@psf.upfronthosting.co.za>
Message-ID: <1521870165.46.0.467229070634.issue33006@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ncoghlan, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33006>
_______________________________________

From report at bugs.python.org  Sat Mar 24 01:56:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 05:56:44 +0000
Subject: [issue31544] gettext.Catalog title is not flagged as a class
In-Reply-To: <1506007626.15.0.9927755066.issue31544@psf.upfronthosting.co.za>
Message-ID: <1521871004.67.0.467229070634.issue31544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0694b6a651ba2a53f6323ffb3b23358f43885815 by Serhiy Storchaka (scoder) in branch '2.7':
bpo-31544: Avoid calling "PyObject_GetAttrString()" (and potentially executing user code) with a live exception set. (GH-3992)
https://github.com/python/cpython/commit/0694b6a651ba2a53f6323ffb3b23358f43885815


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31544>
_______________________________________

From report at bugs.python.org  Sat Mar 24 01:57:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 05:57:41 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1521871061.19.0.467229070634.issue31455@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/issue31455>
_______________________________________

From report at bugs.python.org  Sat Mar 24 01:59:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 05:59:40 +0000
Subject: [issue31544] gettext.Catalog title is not flagged as a class
In-Reply-To: <1506007626.15.0.9927755066.issue31544@psf.upfronthosting.co.za>
Message-ID: <1521871180.21.0.467229070634.issue31544@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg314357

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31544>
_______________________________________

From report at bugs.python.org  Sat Mar 24 02:01:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 06:01:15 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1521871275.55.0.467229070634.issue31455@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

New changeset 0694b6a651ba2a53f6323ffb3b23358f43885815 by Serhiy Storchaka (scoder) in branch '2.7':
bpo-31544: Avoid calling "PyObject_GetAttrString()" (and potentially executing user code) with a live exception set. (GH-3992)
https://github.com/python/cpython/commit/0694b6a651ba2a53f6323ffb3b23358f43885815

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Mar 24 02:48:53 2018
From: report at bugs.python.org (Aaron Ang)
Date: Sat, 24 Mar 2018 06:48:53 +0000
Subject: [issue28677] difficult to parse sentence structure in "When an
 instance attribute is referenced that isn't a data attribute"
In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>
Message-ID: <1521874133.2.0.467229070634.issue28677@psf.upfronthosting.co.za>


Change by Aaron Ang <awz.ang at gmail.com>:


----------
keywords: +patch
pull_requests: +5952
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28677>
_______________________________________

From report at bugs.python.org  Sat Mar 24 03:27:41 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Mar 2018 07:27:41 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
Message-ID: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Paul brought up recently [1] that with pip 10.0.0 due for release next month [2], we'd really prefer to ship that in Python 3.7.0 (such that 3.7 launches with PEP 518/517 pyproject.toml support), rather than shipping with 9.0.x and then upgrading to 10.0.0 in Python 3.7.1.

The timing is such that 10.0.0 won't quite be ready for 3.7.0b3, but it should be released before 3.7.0b4 at the end of April.

[1] https://github.com/pypa/packaging-problems/issues/127#issuecomment-374183609
[2] https://mail.python.org/pipermail/distutils-sig/2018-March/032047.html

----------
messages: 314360
nosy: Marcus.Smith, dstufft, ncoghlan, ned.deily, paul.moore
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Upgrade to pip 10 for Python 3.7
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Sat Mar 24 03:35:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 07:35:44 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
In-Reply-To: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>
Message-ID: <1521876944.66.0.467229070634.issue33131@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Currently the repository contains blobs for pip and setuptools (2 MB total) which are updated with every release of pip and setuptools. This increases the size of the repository by 2 MB several times per year. Wouldn't be better to put them in a separate repository like Tcl/Tk?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Sat Mar 24 03:40:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Mar 2018 07:40:51 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
In-Reply-To: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>
Message-ID: <1521877251.88.0.467229070634.issue33131@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Possibly - we implemented ensurepip the way we did just because it was the easiest option, not because we closely considered all the available approaches.

That would be a separate process improvement issue, though :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Sat Mar 24 06:27:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 10:27:46 +0000
Subject: [issue32996] Improve What's New in 3.7
In-Reply-To: <1520251006.69.0.467229070634.issue32996@psf.upfronthosting.co.za>
Message-ID: <1521887266.2.0.467229070634.issue32996@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Different projects solve the problem with async in different ways. Many of them rename "async" parameter to "async_". Some renames it to "_async" or replace with an opposite parameter "sync". Some projects keep supporting of "async" in older Python versions by using var-keyword parameters, but not all are aware of this possibility. If the preferable way be described in the What's New, it would help porting to 3.7.

Another important language change missed in the What's New is keeping insertion order in dicts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32996>
_______________________________________

From report at bugs.python.org  Sat Mar 24 06:39:43 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 24 Mar 2018 10:39:43 +0000
Subject: [issue32932] better error message when __all__ contains non-str
 objects
In-Reply-To: <1519462308.25.0.467229070634.issue32932@psf.upfronthosting.co.za>
Message-ID: <1521887983.77.0.467229070634.issue32932@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset d8b291a74284307610946f1b5801aa95d7f1e052 by Xiang Zhang in branch 'master':
bpo-32932: More revealing error message when non-str objects in __all__ (GH-5848)
https://github.com/python/cpython/commit/d8b291a74284307610946f1b5801aa95d7f1e052


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32932>
_______________________________________

From report at bugs.python.org  Sat Mar 24 06:41:16 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 24 Mar 2018 10:41:16 +0000
Subject: [issue32932] better error message when __all__ contains non-str
 objects
In-Reply-To: <1519462308.25.0.467229070634.issue32932@psf.upfronthosting.co.za>
Message-ID: <1521888076.83.0.467229070634.issue32932@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/issue32932>
_______________________________________

From report at bugs.python.org  Sat Mar 24 08:32:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 12:32:25 +0000
Subject: [issue33132] Possible refcount issues in the compiler
Message-ID: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are several possible reference leaks in compiler.c. When implicit (in VISIT* or ADDOP_* macros) "return" is occurred between creating a new object and ADDOP_N, there is a possible reference leaks. ADDOP_O followed by Py_DECREF contains a possible reference leaks.

And in compiler_from_import() names can be decrefed twice.

The following PR fixes these issues.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 314365
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible refcount issues in the compiler
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 24 08:34:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 12:34:20 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1521894860.57.0.467229070634.issue33132@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5954
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 24 09:14:00 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Mar 2018 13:14:00 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521897240.96.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

PR has been updated to be mostly complete (just pending docs changes now), but I think I've found a potential issue with the interaction between the way I've currently implemented it and the way _Py_InitializeCore and _Py_InitializeMainInterpreter work.

Specifically, sys.warnoptions and sys._xoptions don't get created until _PySys_EndInit, so that's where I added the code to read the pre-initialization linked lists and move those values into sys.warnoptions and sys._xoptions. The current test is just checking that those sys attribute have the expected contents - it isn't checking that the consequences of those settings have correctly propagated to the warnings filter list.

For the default filters add by `_PyWarnings_Init` at the end of `_Py_InitializeCore`, I think that's fine - we're going to want the embedding application's filters to be add after the default filter list anyway.

However, the code in `_PyInitialize_MainInterpreter` to actually import the warnings module (which then reads `sys.warnoptions`) is guarded by a check for a non-empty config->warnoptions, and that's not going to trip in the case where get_warnoptions() has created a new sys.warnoptions list, and config->warnoptions is still NULL.

Rather than changing the preinit sys module code to be config-aware, I'm thinking that what I'd like to do is:

1. Update the new test case to also check that the most recent 3 entries in the warnings filter list match what we expect
2. Assuming that fails (as I expect it will), change the guard in _Py_InitializeMainInterpreter to check PySys_HasWarnOptions (which will correctly handle the case where config->warnoptions is NULL, but entries have been added to sys.warnoptions by some other mechanism, like PySys_AddWarnOption)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:14:27 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:14:27 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521900867.16.0.467229070634.issue33127@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5955
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:20:51 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:20:51 +0000
Subject: [issue24334] SSLSocket extra level of indirection
In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za>
Message-ID: <1521901251.71.0.467229070634.issue24334@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5956

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24334>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:28:33 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:28:33 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1521901713.95.0.467229070634.issue33023@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Serhiy,
I don't understand what you are trying to tell me. "cannot serialize '%s' object" is used all over the interpreter, e.g. io, pickle, etree, and more. I feel it's the standard message.

Vitaly,
A lot of objects can't be copied. It's the general case for all kinds of objects that hold operating system resources (files, sockets) or wrap external C libraries (bz2, lzma, sqlite, ssl). We generally don't document that an object cannot be pickled, serialized, or copied. If documentation doesn't state that an object is copy-able or doesn't provide a dedicated copy method, than it can't be copied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:36:52 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:36:52 +0000
Subject: [issue24334] SSLSocket extra level of indirection
In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za>
Message-ID: <1521902212.76.0.467229070634.issue24334@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset e42ae915095ebca789cc36f3a336a3331fe35945 by Christian Heimes in branch 'master':
bpo-24334: Remove inaccurate match_hostname call (#6211)
https://github.com/python/cpython/commit/e42ae915095ebca789cc36f3a336a3331fe35945


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24334>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:37:27 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 24 Mar 2018 14:37:27 +0000
Subject: [issue24334] SSLSocket extra level of indirection
In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za>
Message-ID: <1521902247.68.0.467229070634.issue24334@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24334>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:41:39 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:41:39 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521902499.62.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 4ca0739c9d97ac7cd45499e0d31be68dc659d0e1 by Christian Heimes in branch 'master':
bpo-33127: Compatibility patch for LibreSSL 2.7.0 (GH-6210)
https://github.com/python/cpython/commit/4ca0739c9d97ac7cd45499e0d31be68dc659d0e1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:41:47 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 24 Mar 2018 14:41:47 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521902507.93.0.467229070634.issue33127@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:44:24 2018
From: report at bugs.python.org (Stefan Sauer)
Date: Sat, 24 Mar 2018 14:44:24 +0000
Subject: [issue18338] python --version should send output to STDOUT
In-Reply-To: <1372676487.3.0.302989276182.issue18338@psf.upfronthosting.co.za>
Message-ID: <1521902664.73.0.467229070634.issue18338@psf.upfronthosting.co.za>


Stefan Sauer <st.kost at gmail.com> added the comment:

Is there a workaround for python2? The issue is that autotools is checking that installed tools support --help and --version and it expects those to stdout:

bad=0; pid=$$; list="gtkdoc-check gtkdoc-depscan gtkdoc-fixxref gtkdoc-mkdb gtkdoc-mkhtml gtkdoc-mkhtml2 gtkdoc-mkman gtkdoc-mkpdf gtkdoc-rebase gtkdoc-scan gtkdoc-scangobj gtkdocize"; for p in $list; do \
  case '  ' in \
   *" $p "* | *" ../../$p "*) continue;; \
  esac; \
  f=`echo "$p" | sed 's,^.*/,,;s,x,x,'`; \
  for opt in --help --version; do \
    if "/home/ensonic/projects/gnome/gtk-doc/gtk-doc-1.27.1/_inst/bin/$f" $opt >c${pid}_.out \
         2>c${pid}_.err </dev/null \
	 && test -n "`cat c${pid}_.out`" \
	 && test -z "`cat c${pid}_.err`"; then :; \
    else echo "$f does not support $opt" 1>&2; bad=1; fi; \
  done; \
done; rm -f c${pid}_.???; exit $bad
gtkdoc-check does not support --version
gtkdoc-fixxref does not support --version
gtkdoc-mkdb does not support --version
gtkdoc-mkhtml does not support --version
gtkdoc-mkhtml2 does not support --version
gtkdoc-mkman does not support --version
gtkdoc-mkpdf does not support --version
gtkdoc-rebase does not support --version
gtkdoc-scan does not support --version
gtkdoc-scangobj does not support --version
Makefile:637: recipe for target 'installcheck-binSCRIPTS' failed

----------
nosy: +Stefan Sauer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18338>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:53:27 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:53:27 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521903207.92.0.467229070634.issue33127@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5959

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 10:59:18 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 14:59:18 +0000
Subject: [issue24334] SSLSocket extra level of indirection
In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za>
Message-ID: <1521903558.63.0.467229070634.issue24334@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 1a0bb626f4cfd95f7ec406ea7d3f9433def559fc by Christian Heimes (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-24334: Remove inaccurate match_hostname call (GH-6211) (#6212)
https://github.com/python/cpython/commit/1a0bb626f4cfd95f7ec406ea7d3f9433def559fc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24334>
_______________________________________

From report at bugs.python.org  Sat Mar 24 11:00:08 2018
From: report at bugs.python.org (Stefan Sauer)
Date: Sat, 24 Mar 2018 15:00:08 +0000
Subject: [issue18338] python --version should send output to STDOUT
In-Reply-To: <1372676487.3.0.302989276182.issue18338@psf.upfronthosting.co.za>
Message-ID: <1521903608.7.0.467229070634.issue18338@psf.upfronthosting.co.za>


Stefan Sauer <st.kost at gmail.com> added the comment:

Sorry need to find the ticket for argparse ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18338>
_______________________________________

From report at bugs.python.org  Sat Mar 24 11:01:37 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 15:01:37 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521903697.48.0.467229070634.issue33127@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +5960

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 11:04:25 2018
From: report at bugs.python.org (Stefan Sauer)
Date: Sat, 24 Mar 2018 15:04:25 +0000
Subject: [issue18920] argparse version action should print to stdout,
 not stderr
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1521903865.36.0.467229070634.issue18920@psf.upfronthosting.co.za>


Stefan Sauer <st.kost at gmail.com> added the comment:

Is there a workaround for python2? The issue is that autotools is checking that installed tools support --help and --version and it expects those to stdout:

bad=0; pid=$$; list="gtkdoc-check gtkdoc-depscan gtkdoc-fixxref gtkdoc-mkdb gtkdoc-mkhtml gtkdoc-mkhtml2 gtkdoc-mkman gtkdoc-mkpdf gtkdoc-rebase gtkdoc-scan gtkdoc-scangobj gtkdocize"; for p in $list; do \
  case '  ' in \
   *" $p "* | *" ../../$p "*) continue;; \
  esac; \
  f=`echo "$p" | sed 's,^.*/,,;s,x,x,'`; \
  for opt in --help --version; do \
    if "/home/ensonic/projects/gnome/gtk-doc/gtk-doc-1.27.1/_inst/bin/$f" $opt >c${pid}_.out \
         2>c${pid}_.err </dev/null \
         && test -n "`cat c${pid}_.out`" \
         && test -z "`cat c${pid}_.err`"; then :; \
    else echo "$f does not support $opt" 1>&2; bad=1; fi; \
  done; \
done; rm -f c${pid}_.???; exit $bad
gtkdoc-check does not support --version
gtkdoc-fixxref does not support --version
gtkdoc-mkdb does not support --version
gtkdoc-mkhtml does not support --version
gtkdoc-mkhtml2 does not support --version
gtkdoc-mkman does not support --version
gtkdoc-mkpdf does not support --version
gtkdoc-rebase does not support --version
gtkdoc-scan does not support --version
gtkdoc-scangobj does not support --version
Makefile:637: recipe for target 'installcheck-binSCRIPTS' failed

----------
nosy: +Stefan Sauer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18920>
_______________________________________

From report at bugs.python.org  Sat Mar 24 12:17:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 16:17:16 +0000
Subject: [issue18920] argparse version action should print to stdout,
 not stderr
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1521908236.92.0.467229070634.issue18920@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You can implement your own version action which outputs to stdout and use it for -V and --version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18920>
_______________________________________

From report at bugs.python.org  Sat Mar 24 13:37:41 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Sat, 24 Mar 2018 17:37:41 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1521901713.95.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <CALVBdqtf5sY0qjG7mmEXOGYWJLemWYmg5TaFvPogY3dQ2TP5og@mail.gmail.com>


Vitaly Kruglikov <vitaly.krug at gmail.com> added the comment:

Thank you, I'll consider myself having been warned :)

On Sat, Mar 24, 2018, 7:28 AM Christian Heimes <report at bugs.python.org>
wrote:

>
> Christian Heimes <lists at cheimes.de> added the comment:
>
> Serhiy,
> I don't understand what you are trying to tell me. "cannot serialize '%s'
> object" is used all over the interpreter, e.g. io, pickle, etree, and more.
> I feel it's the standard message.
>
> Vitaly,
> A lot of objects can't be copied. It's the general case for all kinds of
> objects that hold operating system resources (files, sockets) or wrap
> external C libraries (bz2, lzma, sqlite, ssl). We generally don't document
> that an object cannot be pickled, serialized, or copied. If documentation
> doesn't state that an object is copy-able or doesn't provide a dedicated
> copy method, than it can't be copied.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33023>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sat Mar 24 13:37:56 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 17:37:56 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521913076.61.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 42bd62bc87a52538c0fc2134b76df316f30997da by Christian Heimes (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-33127: Compatibility patch for LibreSSL 2.7.0 (GH-6210) (GH-6213)
https://github.com/python/cpython/commit/42bd62bc87a52538c0fc2134b76df316f30997da


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 13:38:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 17:38:16 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521913096.57.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset f5befbb0d1526f18eb2b24eabb48c3b761c624a2 by Christian Heimes in branch '3.6':
[3.6] bpo-33127: Compatibility patch for LibreSSL 2.7.0 (GH-6210) (GH-6214)
https://github.com/python/cpython/commit/f5befbb0d1526f18eb2b24eabb48c3b761c624a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 14:16:02 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 24 Mar 2018 18:16:02 +0000
Subject: [issue33133] Don't return implicit optional types by get_type_hints
Message-ID: <1521915362.58.0.467229070634.issue33133@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi <levkivskyi at gmail.com>:

Currently this code

def f(x: int = None):
    pass

get_type_hints(f)

returns {'x': Optional[int]}. I propose to abandon this behaviour. Although there is not yet a definitive decision about this aspect of PEP 484, see https://github.com/python/typing/issues/275, I think at least at runtime we should not do this.

----------
components: Library (Lib)
messages: 314378
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Don't return implicit optional types by get_type_hints
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33133>
_______________________________________

From report at bugs.python.org  Sat Mar 24 14:34:18 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 18:34:18 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521916458.65.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset edd541897b9c28ee0d0f0131746aa5f19665a104 by Christian Heimes in branch '2.7':
[2.7] bpo-33127: Compatibility patch for LibreSSL 2.7.0 (GH-6210) (GH-6215)
https://github.com/python/cpython/commit/edd541897b9c28ee0d0f0131746aa5f19665a104


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 14:40:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Mar 2018 18:40:28 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521916828.02.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I have fixed Python 2.7, 3.6, 3.7, and master branch. Thanks for the report!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sat Mar 24 14:45:22 2018
From: report at bugs.python.org (Garvit Khatri)
Date: Sat, 24 Mar 2018 18:45:22 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1521917122.96.0.467229070634.issue33096@psf.upfronthosting.co.za>


Garvit Khatri <garvitdelhi at gmail.com> added the comment:

I made the changes on my machine and I\in my testing, it breaks on an empty string with an error saying
"Item already exists". If this is expected I would like to submit a patch with tests for the same.

----------
nosy: +garvitdelhi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sat Mar 24 15:24:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 19:24:08 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1521919448.66.0.467229070634.issue33023@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Christian, I thought the reason of adding __getstate__ methods which raise an exception is that the existing error message doesn't satisfy your. What is the other reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sat Mar 24 15:25:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 19:25:37 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1521919537.51.0.467229070634.issue33096@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, this is expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sat Mar 24 16:02:38 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 24 Mar 2018 20:02:38 +0000
Subject: [issue32873] Pickling of typing types
In-Reply-To: <1519037205.03.0.467229070634.issue32873@psf.upfronthosting.co.za>
Message-ID: <1521921758.8.0.467229070634.issue32873@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch
pull_requests: +5961
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32873>
_______________________________________

From report at bugs.python.org  Sat Mar 24 16:42:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Mar 2018 20:42:42 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1521924162.61.0.467229070634.issue33132@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a95d98607efe0c43475b354543e49bf8e240bc6f by Serhiy Storchaka in branch 'master':
bpo-33132: Fix reference counting issues in the compiler. (GH-6209)
https://github.com/python/cpython/commit/a95d98607efe0c43475b354543e49bf8e240bc6f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 24 16:42:53 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 24 Mar 2018 20:42:53 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1521924173.07.0.467229070634.issue33132@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5962

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 24 17:11:21 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 24 Mar 2018 21:11:21 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
Message-ID: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

There's already a table lookup for what action to take when adding __hash__. Change it to a function dispatch table, instead of using strings and testing them.

----------
assignee: eric.smith
components: Library (Lib)
messages: 314385
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: use function dispatch instead of multiple tests for adding __hash__
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 17:27:08 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 24 Mar 2018 21:27:08 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1521926828.62.0.467229070634.issue33132@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 471364b4d977fc31bdf3012912954f24e4867d52 by Miss Islington (bot) in branch '3.7':
bpo-33132: Fix reference counting issues in the compiler. (GH-6209)
https://github.com/python/cpython/commit/471364b4d977fc31bdf3012912954f24e4867d52


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 24 17:53:19 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 24 Mar 2018 21:53:19 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1521928399.24.0.467229070634.issue33126@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I fixed PyBuffer_ToContiguous() in 3.3, PyBuffer_FromContiguous() was broken until #23370.

For a start, here's a doc patch for PyBuffer_ToContiguous().

PyBuffer_FromContiguous() does the opposite and loads a contiguous buffer
into a possibly non-contiguous view.

PyObject_CopyData() copies the data from exporter src to the writable exporter dest.

I have never used the last two functions.

----------
keywords: +patch
Added file: https://bugs.python.org/file47497/issue33126.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Sat Mar 24 18:37:54 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Mar 2018 22:37:54 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1521931074.98.0.467229070634.issue33126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks.  The PyBuffer_ToContiguous() API is weird: why pass `len` if it cannot be anything other than `src->len`?
Also, it would be nice to explain whether the actual buffer data is copied around (with a memory allocation?) or if it's just the Py_buffer struct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Sat Mar 24 19:01:23 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 24 Mar 2018 23:01:23 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
In-Reply-To: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>
Message-ID: <1521932483.34.0.467229070634.issue33134@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 19:34:33 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 24 Mar 2018 23:34:33 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
In-Reply-To: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>
Message-ID: <1521934473.36.0.467229070634.issue33134@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5963
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 21:53:56 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 25 Mar 2018 01:53:56 +0000
Subject: [issue32362] multiprocessing.connection.Connection misdocumented as
 multiprocessing.Connection
In-Reply-To: <1513592247.3.0.213398074469.issue32362@psf.upfronthosting.co.za>
Message-ID: <1521942836.98.0.467229070634.issue32362@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
keywords: +patch
pull_requests: +5964
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32362>
_______________________________________

From report at bugs.python.org  Sat Mar 24 21:54:22 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 25 Mar 2018 01:54:22 +0000
Subject: [issue32362] multiprocessing.connection.Connection misdocumented as
 multiprocessing.Connection
In-Reply-To: <1513592247.3.0.213398074469.issue32362@psf.upfronthosting.co.za>
Message-ID: <1521942862.36.0.467229070634.issue32362@psf.upfronthosting.co.za>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32362>
_______________________________________

From report at bugs.python.org  Sat Mar 24 22:10:17 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 25 Mar 2018 02:10:17 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
In-Reply-To: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>
Message-ID: <1521943817.2.0.467229070634.issue33134@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 01d618c5606a239b03ad1269541eddb6e724775d by Eric V. Smith in branch 'master':
bpo-33134: dataclasses: use function dispatch table for hash, instead of a string lookup which then is tested with if tests. (GH-6222)
https://github.com/python/cpython/commit/01d618c5606a239b03ad1269541eddb6e724775d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 22:11:32 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 02:11:32 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
In-Reply-To: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>
Message-ID: <1521943892.86.0.467229070634.issue33134@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5965

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 22:31:31 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 02:31:31 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
In-Reply-To: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>
Message-ID: <1521945091.91.0.467229070634.issue33134@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9989efbb653e8cbd08e51b4d79d094605c8b23b8 by Miss Islington (bot) in branch '3.7':
bpo-33134: dataclasses: use function dispatch table for hash, instead of a string lookup which then is tested with if tests. (GH-6222)
https://github.com/python/cpython/commit/9989efbb653e8cbd08e51b4d79d094605c8b23b8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 22:32:58 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 25 Mar 2018 02:32:58 +0000
Subject: [issue33134] dataclasses: use function dispatch instead of multiple
 tests for adding __hash__
In-Reply-To: <1521925881.85.0.467229070634.issue33134@psf.upfronthosting.co.za>
Message-ID: <1521945178.19.0.467229070634.issue33134@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/issue33134>
_______________________________________

From report at bugs.python.org  Sat Mar 24 22:41:55 2018
From: report at bugs.python.org (Charles)
Date: Sun, 25 Mar 2018 02:41:55 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521945715.28.0.467229070634.issue33127@psf.upfronthosting.co.za>


Charles <chdiza at gmail.com> added the comment:

FYI, the 'cryptography' package from pypi no longer builds after this fix.  (I applied the patch to the 2.7.14 source code tarball.)  I don't know if that's because of the fix, or because LibreSSL 2.7.X broke 'cryptography' too:

clang -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/slangs/py/include/python2.7 -c build/temp.macosx-10.13-x86_64-2.7/_openssl.c -o build/temp.macosx-10.13-x86_64-2.7/build/temp.macosx-10.13-x86_64-2.7/_openssl.o -Wconversion -Wno-error=sign-conversion
    build/temp.macosx-10.13-x86_64-2.7/_openssl.c:493:10: fatal error: 'openssl/opensslv.h' file not found
    #include <openssl/opensslv.h>
             ^~~~~~~~~~~~~~~~~~~~
    1 error generated.
    error: command 'clang' failed with exit status 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sun Mar 25 00:09:27 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 25 Mar 2018 04:09:27 +0000
Subject: [issue32943] confusing error message for rot13 codec
In-Reply-To: <1519536125.53.0.467229070634.issue32943@psf.upfronthosting.co.za>
Message-ID: <1521950967.95.0.467229070634.issue32943@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset e4ce9fa89cb542dced553710b05de85202bc4715 by Xiang Zhang in branch 'master':
bpo-32943: Fix confusing error message for rot13 codec (GH-5869)
https://github.com/python/cpython/commit/e4ce9fa89cb542dced553710b05de85202bc4715


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32943>
_______________________________________

From report at bugs.python.org  Sun Mar 25 00:10:37 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 04:10:37 +0000
Subject: [issue32943] confusing error message for rot13 codec
In-Reply-To: <1519536125.53.0.467229070634.issue32943@psf.upfronthosting.co.za>
Message-ID: <1521951037.56.0.467229070634.issue32943@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5966

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32943>
_______________________________________

From report at bugs.python.org  Sun Mar 25 00:30:42 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 04:30:42 +0000
Subject: [issue32943] confusing error message for rot13 codec
In-Reply-To: <1519536125.53.0.467229070634.issue32943@psf.upfronthosting.co.za>
Message-ID: <1521952242.04.0.467229070634.issue32943@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 291d5f3e7195659f874fe56b0e3ed717b57597ee by Miss Islington (bot) in branch '3.7':
bpo-32943: Fix confusing error message for rot13 codec (GH-5869)
https://github.com/python/cpython/commit/291d5f3e7195659f874fe56b0e3ed717b57597ee


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32943>
_______________________________________

From report at bugs.python.org  Sun Mar 25 00:33:48 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 25 Mar 2018 04:33:48 +0000
Subject: [issue32943] confusing error message for rot13 codec
In-Reply-To: <1519536125.53.0.467229070634.issue32943@psf.upfronthosting.co.za>
Message-ID: <1521952428.59.0.467229070634.issue32943@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32943>
_______________________________________

From report at bugs.python.org  Sun Mar 25 01:39:44 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 25 Mar 2018 05:39:44 +0000
Subject: [issue33133] Don't return implicit optional types by get_type_hints
In-Reply-To: <1521915362.58.0.467229070634.issue33133@psf.upfronthosting.co.za>
Message-ID: <1521956384.33.0.467229070634.issue33133@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm not sure we should change this ahead of a definitive decision. When you use mypy with the option that forbids it, your program will be invalid, and it doesn't really matter what we do at runtime; but that option is not the default yet, and without that option, mypy treats the type as Optional[int].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33133>
_______________________________________

From report at bugs.python.org  Sun Mar 25 01:48:01 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 05:48:01 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521956881.69.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I added the new test case, and found to my surprise that it didn't fail, even in debug mode (where there aren't any default filters).

The point I had missed was that even though warnoptions can be NULL in CoreConfig, _Py_MainInterpreterConfig_Read ensures that it's never NULL for the main interpreter config (which is what _PySys_EndInit reads), which means that neither we nor any embedding application can currently trigger the code path in get_warnoptions() that lazily creates the warnings list without adding the reference back into the config settings.

We'll need to fix that before we make the new configuration API public, but for now I'm just going to note it in the source code as a "PEP432 TODO".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 02:05:09 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 25 Mar 2018 06:05:09 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1521957909.56.0.467229070634.issue33114@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

There's nothing in the docs I can see that implies `sample(x, n)` is a prefix of what `sample(x, n+1)` would have returned had the latter been called instead.  If so, then - as always - it's "at your own risk" when you rely on behaviors that haven't been specified.  Since the universe of _possible_ behaviors that haven't been specified is immense, I'd rather we didn't even start to list all of them ;-)

Seriously, when the docs don't promise something, it's usually a mistake to assume they just forgot to mention it.  I'd leave the docs alone in this case.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Sun Mar 25 02:10:23 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 06:10:23 +0000
Subject: [issue33135] Define field prefixes for the various config structs
Message-ID: <1521958223.34.0.467229070634.issue33135@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

While working on https://bugs.python.org/issue33042, I found it hard to keep track of which kind of config struct a particular piece of code was referencing.

As a particularly relevant example, we currently have 3 different "warnoptions" fields: the private-to-main one for reading the command line settings, the "wchar_t *" list in the core config, and the "PyObject *" list object in the main interpreter config (which is also the one aliased as sys.warnoptions).

What do you think of adopting a convention where:

* the command line fields all gain a "cmd_" prefix
* the core config fields all gain a "c_" prefix
* the interpreter config fields all gain a "py_" prefix

We'd then have "cmd_warnoptions", "c_warnoptions", and "py_warnoptions" as the field names, and it would be more self-evident which layer we were working at in any particular piece of code.

----------
messages: 314398
nosy: eric.snow, ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Define field prefixes for the various config structs
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33135>
_______________________________________

From report at bugs.python.org  Sun Mar 25 03:06:48 2018
From: report at bugs.python.org (Garvit Khatri)
Date: Sun, 25 Mar 2018 07:06:48 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1521961608.07.0.467229070634.issue33096@psf.upfronthosting.co.za>


Change by Garvit Khatri <garvitdelhi at gmail.com>:


----------
keywords: +patch
pull_requests: +5967
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sun Mar 25 04:17:48 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 08:17:48 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521965868.59.0.467229070634.issue33053@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/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 04:58:24 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Mar 2018 08:58:24 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1521968304.33.0.467229070634.issue33127@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's unrelated. PyCA Cryptography doesn't support LibreSSL 2.7 yet, see https://github.com/pyca/cryptography/pull/4168

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33127>
_______________________________________

From report at bugs.python.org  Sun Mar 25 05:19:22 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Mar 2018 09:19:22 +0000
Subject: [issue33136] Harden ssl module against CVE-2018-8970
Message-ID: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Since 3.7, the ssl module uses X509_VERIFY_PARAM_set1_host() to put the burden of hostname matching on OpenSSL. More specific, it calls X509_VERIFY_PARAM_set1_host(param, server_hostname, 0). The namelen=0 parameter means that OpenSSL handles server_hostname as a NUL-terminated C string.

LibreSSL 2.7.0 added X509_VERIFY_PARAM_set1_host(), but took the implementation from BoringSSL instead of OpenSSL. The BoringSSL implementation doesn't support namelen=0. X509_VERIFY_PARAM_set1_host(param, server_hostname, 0) returns success but doesn't configure the SSL connection for hostname verification. As a result, LibreSSL 2.7.0 doesn't perform any hostname matching. All trusted certificates are accepted for just any arbitrary hostname. This misbehavior left Python 3.7 beta open to man-in-the-middle attack.

LibreSSL 2.7.1 has fixed the issue. To harden the ssl module against, I'm also changing our implementation to use strlen() instead of 0.


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
https://bugs.chromium.org/p/boringssl/issues/detail?id=30
https://bugs.chromium.org/p/chromium/issues/detail?id=824799 (restricted for now)

----------
assignee: christian.heimes
components: SSL
messages: 314400
nosy: christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: Harden ssl module against CVE-2018-8970
type: security
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33136>
_______________________________________

From report at bugs.python.org  Sun Mar 25 05:21:10 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 25 Mar 2018 09:21:10 +0000
Subject: [issue33133] Don't return implicit optional types by get_type_hints
In-Reply-To: <1521915362.58.0.467229070634.issue33133@psf.upfronthosting.co.za>
Message-ID: <1521969670.7.0.467229070634.issue33133@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

OK, let us then keep this issue as a remainder that we need to update the runtime behaviour when the static one changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33133>
_______________________________________

From report at bugs.python.org  Sun Mar 25 06:06:47 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Mar 2018 10:06:47 +0000
Subject: [issue33136] Harden ssl module against CVE-2018-8970
In-Reply-To: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
Message-ID: <1521972407.48.0.467229070634.issue33136@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +5968
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33136>
_______________________________________

From report at bugs.python.org  Sun Mar 25 06:36:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Mar 2018 10:36:16 +0000
Subject: [issue33136] Harden ssl module against CVE-2018-8970
In-Reply-To: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
Message-ID: <1521974176.75.0.467229070634.issue33136@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset d02ac25ab0879f1a6de6937573bf00a16b7bd22e by Christian Heimes in branch 'master':
bpo-33136: Harden ssl module against CVE-2018-8970 (GH-6229)
https://github.com/python/cpython/commit/d02ac25ab0879f1a6de6937573bf00a16b7bd22e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33136>
_______________________________________

From report at bugs.python.org  Sun Mar 25 06:37:32 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 10:37:32 +0000
Subject: [issue33136] Harden ssl module against CVE-2018-8970
In-Reply-To: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
Message-ID: <1521974252.84.0.467229070634.issue33136@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33136>
_______________________________________

From report at bugs.python.org  Sun Mar 25 06:39:18 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 10:39:18 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521974358.24.0.467229070634.issue33053@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch
pull_requests: +5970
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 06:45:41 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 10:45:41 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521974741.07.0.467229070634.issue33042@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5971

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 06:54:03 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 10:54:03 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521975243.23.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

PR posted with the change to use an absolute path for the starting working directory in the "-m" case.

That PR also includes a change to improve the fidelity of the test suite: back when I first wrote test_cmd_line_script, I was mainly focused on testing the runpy aspects, and not the sys.path initialisation aspects, so the way the tests worked didn't really check the latter properly.

The test updates get rid of the launch script that was previously confusing matters, and instead test sys.path[0] initialisation properly (relying on `PYTHONPATH` for the zipimport related cases where just changing the working directory isn't sufficient).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 07:22:54 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 11:22:54 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521976974.73.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It turned out some tests in CPython's own test suite were implicitly relying on the old behaviour where the current working directory automatically ended up on sys.path (see the changes to test_bdb and test_doctest in the updated PR).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 07:27:59 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 25 Mar 2018 11:27:59 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521977279.21.0.467229070634.issue33042@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c6d94c37f4fd863c73fbfbcc918fd23b458b5301 by Miss Islington (bot) in branch '3.7':
bpo-33042: Fix pre-initialization sys module configuration (GH-6157)
https://github.com/python/cpython/commit/c6d94c37f4fd863c73fbfbcc918fd23b458b5301


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 07:28:22 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Mar 2018 11:28:22 +0000
Subject: [issue33136] Harden ssl module against CVE-2018-8970
In-Reply-To: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
Message-ID: <1521977302.64.0.467229070634.issue33136@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 2dd885eaa0d427e84892673c83d697bca5427c8b by Christian Heimes (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-33136: Harden ssl module against CVE-2018-8970 (GH-6229) (GH-6230)
https://github.com/python/cpython/commit/2dd885eaa0d427e84892673c83d697bca5427c8b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33136>
_______________________________________

From report at bugs.python.org  Sun Mar 25 07:37:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 11:37:51 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1521977871.52.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While I've merged an initial fix for this (so it should be working again in 3.7.0b3), I'm not going to close the issue until folks have had a chance to review and comment on the linked list based approach I've taken.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 08:01:28 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 25 Mar 2018 12:01:28 +0000
Subject: [issue33137] line traces may be missed on backward jumps when
 instrumented with dtrace
Message-ID: <1521979288.09.0.467229070634.issue33137@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

In _PyEval_EvalFrameDefault(), the call to maybe_dtrace_line() sets frame->f_lasti to instr_prev and for that reason, in the ensuing call to maybe_call_line_trace(), the call_trace() function with PyTrace_LINE is not called as it should when a backward jump is not to the first instruction of the line.

----------
components: Interpreter Core
messages: 314408
nosy: lukasz.langa, serhiy.storchaka, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: line traces may be missed on backward jumps when instrumented with dtrace
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33137>
_______________________________________

From report at bugs.python.org  Sun Mar 25 08:08:23 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 25 Mar 2018 12:08:23 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1521979703.36.0.467229070634.issue24565@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

A trace function may also be set in extension modules by PyEval_SetTrace() and it may not use f->f_trace. This is another reason why f->f_trace cannot be used in PyFrame_GetLineNumber() to know when f->f_lineno is valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Sun Mar 25 08:27:30 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 25 Mar 2018 12:27:30 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1521980850.4.0.467229070634.issue24565@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Added PR 6233.
One of the GitHub bots failed to link this issue with PR 6233. Maybe this is related to the fact that connections to bpo are currently failing intermitently with the message:

An error occurred during a connection to bugs.python.org. Peer?s certificate has an invalid signature. Error code: SEC_ERROR_BAD_SIGNATURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Sun Mar 25 08:31:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Mar 2018 12:31:37 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1521981097.81.0.467229070634.issue24565@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5972
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:12:42 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 25 Mar 2018 13:12:42 +0000
Subject: [issue32270] subprocess closes redirected fds even if they are in
 pass_fds
In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za>
Message-ID: <1521983562.21.0.467229070634.issue32270@psf.upfronthosting.co.za>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:16:14 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 13:16:14 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521983774.53.0.467229070634.issue33053@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:20:06 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 13:20:06 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521984006.13.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Initial fix has been merged to master, CI runs pending for the backport to 3.7 and a follow-up master branch PR to remove a debugging print I noticed when resolving a test_import conflict in the backport.

I won't get to merging those until some time after work tomorrow (probably 8 pm'ish in UTC+10), so if anyone wanted to merge them before that, it would likely be a good idea :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:43:52 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 13:43:52 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521985432.6.0.467229070634.issue33053@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +5974

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:45:30 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 13:45:30 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521985530.16.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

3.7 CI finished before I logged off for the night, so this is good to go for 3.7.0b3 now :)

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:47:31 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 25 Mar 2018 13:47:31 +0000
Subject: [issue31823] Opaque default value for close_fds argument in
 Popen.__init__
In-Reply-To: <1508445256.4.0.213398074469.issue31823@psf.upfronthosting.co.za>
Message-ID: <1521985651.41.0.467229070634.issue31823@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

The close_fds=<object . . .> in that signature seems fine to me. If you read the documentation, it says the default mode depends on the platform, and on other parameters. However I think the signature at <https://docs.python.org/release/3.6.4/library/subprocess.html#subprocess.Popen> should not show close_fds=True, because that is not necessarily the default on Windows.

It seems the default on Windows was changed to always True in 3.7, making it consistent across platforms and other parameters, thanks to Issue 19764. But the 3.7 documentation is quirky. ?Changed in version 3.2: The default for ?close_fds? was changed from False to what is described above? refers to the 3.7 default when it was meant to refer to the 3.2?3.6 default.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31823>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:47:56 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 13:47:56 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521985676.62.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset a9e5d0e9ef27b14e34631d415e727a07d0f63bef by Nick Coghlan in branch 'master':
bpo-33053: Remove test_cmd_line_script debugging print (GH-6237)
https://github.com/python/cpython/commit/a9e5d0e9ef27b14e34631d415e727a07d0f63bef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 09:50:03 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 13:50:03 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1521985803.39.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Marking as fixed, since this is now the version likely to go out in 3.7.0b3 - if we find further problems with it (beyond the potential enhancement discussed above to make local directory usage opt-in), then those can go in a new issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 10:26:27 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 25 Mar 2018 14:26:27 +0000
Subject: [issue33079] subprocess: document the interaction between
 subprocess.Popen and os.set_inheritable
In-Reply-To: <1521109238.05.0.467229070634.issue33079@psf.upfronthosting.co.za>
Message-ID: <1521987987.85.0.467229070634.issue33079@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

There is no ?open_fds? parameter as far as I know. I presume you meant heritable descriptors are still closed with close_fds=True (not open_fds=False).

Are you sure about the second part? In my experiments on Linux, unless I use ?pass_fds? or one of the ?stdin? etc parameters, a non-heritable descriptor is never passed to the child, no matter what I use for ?close_fds?.

Reading through Issue 6559, the intention of ?pass_fds? seems to be to list extra file descriptors, in addition to 0, 1 and 2 that are normally passed. The documentation says descriptors greater than 2 are closed (due to close_fds=True), but in reality the ?pass_fds? descriptors seem to be always left open, even when they are marked non-heritable.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33079>
_______________________________________

From report at bugs.python.org  Sun Mar 25 10:27:06 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Mar 2018 14:27:06 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1521988026.11.0.467229070634.issue33023@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

That's the only reason for PR 6099. The change makes it more obvious that SSL objects can't be serialized or copied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:02:01 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 16:02:01 +0000
Subject: [issue23388] datetime.strftime('%s') does not take timezone into
 account
In-Reply-To: <1422962642.68.0.522001893601.issue23388@psf.upfronthosting.co.za>
Message-ID: <1521993721.06.0.467229070634.issue23388@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> add cross-platform support for %s strftime-format code

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23388>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:11:58 2018
From: report at bugs.python.org (Alan Du)
Date: Sun, 25 Mar 2018 16:11:58 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1521994318.69.0.467229070634.issue33129@psf.upfronthosting.co.za>


Change by Alan  Du <ahd2125 at columbia.edu>:


----------
keywords: +patch
pull_requests: +5975
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:21:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Mar 2018 16:21:38 +0000
Subject: [issue33138] Improve standard error for uncopyable types
Message-ID: <1521994898.68.0.467229070634.issue33138@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently most extension types are not pickleable and copyable. The default error messages is "can't pickle XXX objects". This is confusing in case of copying because not all know that copying falls back to the pickle protocol (see for example issue33023). The proposed PR changes the default error messages to more neutral "cannot serialize 'XXX' object". This or similar error messages are already used in some classes (files, sockets, compressors/decompressors).

It also removes __getstate__ methods raising an error from non-pickleable extension types. They where added when extension types were pickleable by default (fixed in issue22995). Now they are not needed.

----------
components: Interpreter Core
messages: 314418
nosy: alexandre.vassalotti, christian.heimes, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve standard error for uncopyable types
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33138>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:29:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Mar 2018 16:29:21 +0000
Subject: [issue33023] Unable to copy ssl.SSLContext
In-Reply-To: <1520489361.61.0.467229070634.issue33023@psf.upfronthosting.co.za>
Message-ID: <1521995361.88.0.467229070634.issue33023@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See issue33138.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33023>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:36:59 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 16:36:59 +0000
Subject: [issue15088] PyGen_NeedsFinalizing is public, but undocumented
In-Reply-To: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za>
Message-ID: <1521995819.82.0.467229070634.issue15088@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

What should be done for the PyGen_NeedsFinalizing API?  Does it need to be documented or should it be removed since it's no longer used in the code base?

Thanks!

----------
nosy: +csabella
versions: +Python 3.7, Python 3.8 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15088>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:49:52 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 16:49:52 +0000
Subject: [issue31869] commentary on ssl.PROTOCOL_TLS
In-Reply-To: <1508947295.4.0.213398074469.issue31869@psf.upfronthosting.co.za>
Message-ID: <1521996592.06.0.467229070634.issue31869@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

This was changed for 3.7 and 3.6 in PR1355, but there's no corresponding bpo number for that.  Should the relevant changes be backported to 2.7?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31869>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:50:36 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 16:50:36 +0000
Subject: [issue31869] commentary on ssl.PROTOCOL_TLS
In-Reply-To: <1508947295.4.0.213398074469.issue31869@psf.upfronthosting.co.za>
Message-ID: <1521996636.9.0.467229070634.issue31869@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31869>
_______________________________________

From report at bugs.python.org  Sun Mar 25 12:55:14 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 16:55:14 +0000
Subject: [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1521996914.06.0.467229070634.issue24356@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24356>
_______________________________________

From report at bugs.python.org  Sun Mar 25 13:28:01 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 17:28:01 +0000
Subject: [issue33079] subprocess: document the interaction between
 subprocess.Popen and os.set_inheritable
In-Reply-To: <1521109238.05.0.467229070634.issue33079@psf.upfronthosting.co.za>
Message-ID: <1521998881.09.0.467229070634.issue33079@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +5976
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33079>
_______________________________________

From report at bugs.python.org  Sun Mar 25 13:37:50 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 17:37:50 +0000
Subject: [issue33079] subprocess: document the interaction between
 subprocess.Popen and os.set_inheritable
In-Reply-To: <1521109238.05.0.467229070634.issue33079@psf.upfronthosting.co.za>
Message-ID: <1521999470.36.0.467229070634.issue33079@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I assumed simon meant "close_fds=False" when he wrote open_fds = True.

Regardless, supplying any pass_fds forces close_fds=True behavior.

File descriptors listed in pass_fds are explicitly set inheritable from within the child process prior to calling exec().  See the start of child_exec() within Modules/_posixsubprocess.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33079>
_______________________________________

From report at bugs.python.org  Sun Mar 25 13:44:07 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 17:44:07 +0000
Subject: [issue33079] subprocess: document the interaction between
 subprocess.Popen and os.set_inheritable
In-Reply-To: <1521109238.05.0.467229070634.issue33079@psf.upfronthosting.co.za>
Message-ID: <1521999847.83.0.467229070634.issue33079@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I clarified the docs to mention that the inheritable flag is heeded when close_fds=False in https://github.com/python/cpython/pull/6240/files

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33079>
_______________________________________

From report at bugs.python.org  Sun Mar 25 14:18:51 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 25 Mar 2018 18:18:51 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522001931.97.0.467229070634.issue33126@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Yes, the signatures are weird. In PyBuffer_FromContiguous(), "len" is
the size of "buf" in bytes.

If "buf" contains 6 floats, but "view" only has space for 4, then only
4 are copied into "view".


To avoid that sort of thing, I changed PyBuffer_ToContiguous() to
be more restrictive in 3.3, but kept the len parameter.

In PyBuffer_ToContiguous() it would not matter though if len(buf) > src->len, in which case buf would contain uninitialized bytes at
the end.


TBH, I don't think these functions are used very often. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Sun Mar 25 14:32:25 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 25 Mar 2018 18:32:25 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522002745.87.0.467229070634.issue33126@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

And if view->len > len in PyBuffer_FromContiguous(), then
view will contain uninitialized bytes, which is bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Sun Mar 25 15:01:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 19:01:27 +0000
Subject: [issue32270] subprocess closes redirected fds even if they are in
 pass_fds
In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za>
Message-ID: <1522004487.41.0.467229070634.issue32270@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This bug stems from:

 https://github.com/python/cpython/blob/master/Modules/_posixsubprocess.c#L454

When stdout=fd is passed, that results in c2pwrite=fd.  The stdin/stdout/stderr pipe fds are closed when > 2 without checking to see if they are listed in pass_fds.

https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1306 maps the following:
 stdin -> p2cread
 stdout -> c2pwrite
 stderr -> errwrite

----------
assignee:  -> gregory.p.smith
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Sun Mar 25 15:05:49 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 19:05:49 +0000
Subject: [issue6671] webbrowser doesn't respect xfce default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1522004749.0.0.467229070634.issue6671@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Should this patch be converted to a PR?

----------
nosy: +csabella
versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6671>
_______________________________________

From report at bugs.python.org  Sun Mar 25 15:12:05 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 25 Mar 2018 19:12:05 +0000
Subject: [issue32270] subprocess closes redirected fds even if they are in
 pass_fds
In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za>
Message-ID: <1522005125.01.0.467229070634.issue32270@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Actually I've started to work on this with #32844, but got no feedback. This issue may of course be fixed independently, but the problems with descriptor ownership for fds <= 2 will remain unless all ownership problems are fixed at once.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Sun Mar 25 15:35:31 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 19:35:31 +0000
Subject: [issue32270] subprocess closes redirected fds even if they are in
 pass_fds
In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za>
Message-ID: <1522006531.01.0.467229070634.issue32270@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +5977
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:42:47 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 20:42:47 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1522010567.45.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset bc77eff8b96be4f035e665ab35c1d06e22f46491 by Nick Coghlan in branch 'master':
bpo-33042: Fix pre-initialization sys module configuration (GH-6157)
https://github.com/python/cpython/commit/bc77eff8b96be4f035e665ab35c1d06e22f46491


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:42:53 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 20:42:53 +0000
Subject: [issue25782] CPython hangs on error __context__ set to the error
 itself
In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za>
Message-ID: <1522010573.69.0.467229070634.issue25782@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I believe the original issue is fixed, the original problem and the one Jack followed up with no longer work in modern Python 3.

But there is discussion about possibly doing something better, if anyone is interested in doing that I suggest opening a new Enhancement issue and turning the patches floating around into PRs for discussion.

i'm closing this as the worst reported behavior has been fixed.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25782>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:49:15 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 20:49:15 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1522010955.42.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset d5d9e02dd3c6df06a8dd9ce75ee9b52976420a8b by Nick Coghlan in branch 'master':
bpo-33053: -m now adds *starting* directory to sys.path (GH-6231)
https://github.com/python/cpython/commit/d5d9e02dd3c6df06a8dd9ce75ee9b52976420a8b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:52:43 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Mar 2018 20:52:43 +0000
Subject: [issue33053] Avoid adding an empty directory to sys.path when running
 a module with `-m`
In-Reply-To: <1520855835.03.0.467229070634.issue33053@psf.upfronthosting.co.za>
Message-ID: <1522011163.37.0.467229070634.issue33053@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset ee3784594b33c72c3fdca6a71892d22f14045ab6 by Nick Coghlan in branch '3.7':
bpo-33053: -m now adds *starting* directory to sys.path (GH-6231) (#6236)
https://github.com/python/cpython/commit/ee3784594b33c72c3fdca6a71892d22f14045ab6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:54:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Mar 2018 20:54:51 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1522011291.86.0.467229070634.issue33042@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Would it be possible to not officially allow calling PySys_AddWarnOption() before Py_Initialize()? Fix the bug, but don't promote doing that. I just suggest to revert:

Doc/c-api/init.rst:

+  * :c:func:`PySys_AddWarnOption`
+  * :c:func:`PySys_AddXOption`
+  * :c:func:`PySys_ResetWarnOptions`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:55:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Mar 2018 20:55:11 +0000
Subject: [issue33138] Improve standard error for uncopyable types
In-Reply-To: <1521994898.68.0.467229070634.issue33138@psf.upfronthosting.co.za>
Message-ID: <1522011311.92.0.467229070634.issue33138@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +5978
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33138>
_______________________________________

From report at bugs.python.org  Sun Mar 25 16:59:01 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 25 Mar 2018 20:59:01 +0000
Subject: [issue30416] constant folding opens compiler to quadratic time hashing
In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za>
Message-ID: <1522011541.1.0.467229070634.issue30416@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30416>
_______________________________________

From report at bugs.python.org  Sun Mar 25 17:08:38 2018
From: report at bugs.python.org (Hartmut Goebel)
Date: Sun, 25 Mar 2018 21:08:38 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1522012118.76.0.467229070634.issue33042@psf.upfronthosting.co.za>


Hartmut Goebel <h.goebel at crazy-compilers.com> added the comment:

I can confirm that c6d94c37f4fd863c73fbfbcc918fd23b458b5301 makes the PyInstaller test-case, which war the origin of this bug-report, pass.

Thanks for fixing!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Sun Mar 25 17:10:27 2018
From: report at bugs.python.org (Peter Rounce)
Date: Sun, 25 Mar 2018 21:10:27 +0000
Subject: [issue33139] Bdb doesn't find instruction in linecache after
 pdb.set_trace() following os.chdir("/tmp")
Message-ID: <1522012227.23.0.467229070634.issue33139@psf.upfronthosting.co.za>


New submission from Peter Rounce <p.rounce at cs.ucl.ac.uk>:

In my view there is a fault in python3 pdb in that if you use pdb.set_trace() after using os.chdir() to change the cwd to a directory that does not contain the source code being executed, then there is no instruction output on next or step. This is shown in the following code where I have added print lines to bdb.py file to show the errors.
[The tes program is attached.

    python3 testpdb.py
    # To output a line of code the canonic function in bdp.py is called 
    # to build an absolute path to the source code being executed.

    PRINT --> canonic line 32 - canonic = None
    PRINT --> canonic line 36 - canonic_abs = /home/pythontest/Software/python/3/testpdb.py

    # the following  is printed after the call to linecache and shows
    # the file accessed, the line number in the code and
    # the instruction string returned
    PRINT --> filename: /home/pythontest/Software/python/3/testpdb.py - lineno: 11, line: e=d+5
    
    > /home/pythontest/Software/python/3/testpdb.py(11)<module>()
    -> e=d+5
    (Pdb) c
    # The program is continued and os.chdir("/tmp") is executed.
    # Another pdb.set_trace() has been executed, which creates a new Pdb
    # class instance, and thus a new Bdb instance, where Bdb.fncache
    # used by the canonic function is {}. 
    # The canonic function is passed just the filename 'testpdb.py" and
    # canonic uses os.path.abs to get a full path. Of course this gives 
    # the wrong path to testpdb.py since it just prepends the current
    # cwd, thus:-

    PRINT --> canonic line 32 - canonic = None
    PRINT --> canonic line 36 - canonic_abs = /tmp/testpdb.py

    # the call to linecache in format_cache_entry (line 411) doesn't
    # find the source code so returns an empty string.

    PRINT --> filename: /tmp/testpdb.py - lineno: 15, line: 
    > /tmp/testpdb.py(15)<module>()
    (Pdb) c

Why canonic is using os.path.abs is not clear to me: it seems to be a    mistake, but it is surprising that it has not been found, if this is the
 case. It is interesting to note that linecache itself, when reading from a file with just a filename (and not an absolute path) does not try to guess the path with os.path.abs but looks down the python 'sys.path' to find the full path to the file. 
This would look like a reasonable solution, but it might be better to extend the existing code by checking the full path from the 'os.path.abs' instruction with an os.exists call and if this fails doing a search down 'sys.path'.

The modified code in bdb.py for this solution is:-

        def getfullpath(self, basename) :
            for dirname in sys.path:
                try:
                    fullname = os.path.join(dirname, basename)
                except (TypeError, AttributeError):
                    # Not sufficiently string-like to do anything useful with.
                    continue
                try:
                    stat = os.stat(fullname)
                    break
                except OSError:
                    pass
            else:
                return []
            return fullname

        def canonic(self, filename):
            if filename == "<" + filename[1:-1] + ">":
                return filename
            canonic = self.fncache.get(filename)
            if not canon ic:
                canonicabs = canonic = os.path.abspath(filename)
                canonic = os.path.normcase(canonic)
                # if path does not exists look down sys.path
                if not os.path.exists(canonic) :
                    canonic = self.getfullpath(filename)
                    canonic = os.path.normcase(canonic)
                self.fncache[filename] = canonic
            return canonic

----------
components: Library (Lib)
files: testpdb.py
messages: 314435
nosy: prounce
priority: normal
severity: normal
status: open
title: Bdb doesn't find instruction in linecache after pdb.set_trace() following os.chdir("/tmp")
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file47498/testpdb.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33139>
_______________________________________

From report at bugs.python.org  Sun Mar 25 18:55:36 2018
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 25 Mar 2018 22:55:36 +0000
Subject: [issue33140] shutil.chown on Windows
Message-ID: <1522018536.28.0.467229070634.issue33140@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

shutil.chown is defined in Windows even though it's only written for Unix and only documented as available in Unix. Defining it should be skipped on Windows.

Possibly in 3.8 shutil.chown could be implemented on Windows by calling a new os.set_owner function that supports user/group names and SID strings. It could copy how icacls.exe allows using SDDL aliases and string SIDs that begin with an asterisk (e.g. "*BA" and "*S-1-32-544" for BUILTIN\Administrators). If the string starts with an asterisk, get the SID via ConvertStringSidToSid. Otherwise get the SID via LookupAccountName. Then to modify the file's user and group, try to enable SeRestorePrivilege for the current thread and call Set[Named]SecurityInfo.

----------
components: IO, Library (Lib), Windows
messages: 314436
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: shutil.chown on Windows
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33140>
_______________________________________

From report at bugs.python.org  Sun Mar 25 19:00:21 2018
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 25 Mar 2018 23:00:21 +0000
Subject: [issue33140] shutil.chown on Windows
In-Reply-To: <1522018536.28.0.467229070634.issue33140@psf.upfronthosting.co.za>
Message-ID: <1522018821.73.0.467229070634.issue33140@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Oops, the SID for BUILTIN\Administrators is S-1-5-32-544. I left out the authority ID (5).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33140>
_______________________________________

From report at bugs.python.org  Sun Mar 25 19:22:51 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 23:22:51 +0000
Subject: [issue17994] Change necessary in platform.py to support IronPython
In-Reply-To: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za>
Message-ID: <1522020171.41.0.467229070634.issue17994@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> platform._sys_version does not parse correctly IronPython 2.x version

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17994>
_______________________________________

From report at bugs.python.org  Sun Mar 25 19:29:23 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 25 Mar 2018 23:29:23 +0000
Subject: [issue23952] cgi: Document the 'maxlen' member of the cgi module
In-Reply-To: <1429034285.17.0.254053228622.issue23952@psf.upfronthosting.co.za>
Message-ID: <1522020563.09.0.467229070634.issue23952@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
title: Document the 'maxlen' member of the cgi module -> cgi: Document the 'maxlen' member of the cgi module
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23952>
_______________________________________

From report at bugs.python.org  Sun Mar 25 22:25:49 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 02:25:49 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
Message-ID: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>


New submission from Rick Teachey <ricky at teachey.org>:

Summary: The descriptor `__set_name__` functionality (introduced in Python 3.6) does not seem to be working correctly for `dataclass.Field` objects with a default pointing to a descriptor. I have attached a file demonstrating the trouble.

Details: If I set a `dataclass` class object field to a `dataclass.field` with a descriptor object for the `default` argument, the descriptor's `__set_name__` method is not called during initialization. This is unexpected because descriptors themselves seem to work pretty much flawlessly, otherwise. 

(Bravo on that by the way! Working descriptors isn't mentioned at all in the PEP as a feature but I was very pleased to see them working!!)

System details:
Python 3.7b02
Windows 10
PyCharm Community Edition

btw this is my first ever Python bug report; I hope I did a good job.

----------
files: broken__set_name__.py
messages: 314438
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: descriptor __set_name__ feature broken for dataclass descriptor fields
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47499/broken__set_name__.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Sun Mar 25 23:53:12 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Mar 2018 03:53:12 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522036392.45.0.467229070634.issue33141@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 03:02:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 07:02:08 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522047728.05.0.467229070634.issue33096@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3ab44c0783eebdff687014f7d14d5dec59b6bd39 by Serhiy Storchaka (Garvit Khatri) in branch 'master':
bpo-33096: Fix ttk.Treeview.insert. (GH-6228)
https://github.com/python/cpython/commit/3ab44c0783eebdff687014f7d14d5dec59b6bd39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Mon Mar 26 03:03:30 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 07:03:30 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522047810.56.0.467229070634.issue33096@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5979

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Mon Mar 26 03:05:17 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 07:05:17 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522047917.83.0.467229070634.issue33096@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5980

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Mon Mar 26 04:19:54 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 08:19:54 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522052394.65.0.467229070634.issue33096@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a7b1b847f665aafc22557917cea32ec34c9b4418 by Miss Islington (bot) in branch '3.7':
bpo-33096: Fix ttk.Treeview.insert. (GH-6228)
https://github.com/python/cpython/commit/a7b1b847f665aafc22557917cea32ec34c9b4418


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Mon Mar 26 04:20:12 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 08:20:12 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522052412.73.0.467229070634.issue33096@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 45116d393f713bbe918f16b33a0bba28b15bc96b by Miss Islington (bot) in branch '3.6':
bpo-33096: Fix ttk.Treeview.insert. (GH-6228)
https://github.com/python/cpython/commit/45116d393f713bbe918f16b33a0bba28b15bc96b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Mon Mar 26 04:41:20 2018
From: report at bugs.python.org (qb-cea)
Date: Mon, 26 Mar 2018 08:41:20 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1522053680.12.0.467229070634.issue24132@psf.upfronthosting.co.za>


Change by qb-cea <quentin.bouget at cea.fr>:


----------
keywords: +patch
pull_requests: +5981
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Mon Mar 26 04:52:29 2018
From: report at bugs.python.org (Andreas Jung)
Date: Mon, 26 Mar 2018 08:52:29 +0000
Subject: [issue33142] Fatal Python error: Py_Initialize: Unable to get the
 locale encoding
Message-ID: <1522054349.44.0.467229070634.issue33142@psf.upfronthosting.co.za>


New submission from Andreas Jung <ajung at users.sourceforge.net>:

Unable to build Python 3.6.4 from sources on a fresh Debian system:

@plone /tmp/Python-3.6.4 $ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

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   -I. -I./Include    -DPy_BUILD_CORE \
      -DGITVERSION="\"`LC_ALL=C `\"" \
      -DGITTAG="\"`LC_ALL=C `\"" \
      -DGITBRANCH="\"`LC_ALL=C `\"" \
      -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython3.6m.a
ar rc libpython3.6m.a Modules/getbuildinfo.o
ar rc libpython3.6m.a Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o
ar rc libpython3.6m.a Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o
ar rc libpython3.6m.a Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o   Python/thread.o  Python/frozen.o
ar rc libpython3.6m.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
ar rc libpython3.6m.a Modules/_threadmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o  Modules/timemodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.6m.a
gcc -pthread   -Xlinker -export-dynamic -o python Programs/python.o libpython3.6m.a -lpthread -ldl  -lutil   -lm  
gcc -pthread   -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.6m.a -lpthread -ldl  -lutil   -lm  
./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
        echo "generate-posix-vars failed" ; \
        rm -f ./pybuilddir.txt ; \
        exit 1 ; \
fi
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00007f1757349440 (most recent call first):
Aborted
generate-posix-vars failed
Makefile:575: recipe for target 'pybuilddir.txt' failed
make: *** [pybuilddir.txt] Error 1

----------
messages: 314442
nosy: ajung
priority: normal
severity: normal
status: open
title: Fatal Python error: Py_Initialize: Unable to get the locale encoding
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33142>
_______________________________________

From report at bugs.python.org  Mon Mar 26 04:53:47 2018
From: report at bugs.python.org (Andreas Jung)
Date: Mon, 26 Mar 2018 08:53:47 +0000
Subject: [issue33142] Fatal Python error: Py_Initialize: Unable to get the
 locale encoding on Debian/Python 3.6.4 source build
In-Reply-To: <1522054349.44.0.467229070634.issue33142@psf.upfronthosting.co.za>
Message-ID: <1522054427.71.0.467229070634.issue33142@psf.upfronthosting.co.za>


Change by Andreas Jung <ajung at users.sourceforge.net>:


----------
title: Fatal Python error: Py_Initialize: Unable to get the locale encoding -> Fatal Python error: Py_Initialize: Unable to get the locale encoding on Debian/Python 3.6.4 source build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33142>
_______________________________________

From report at bugs.python.org  Mon Mar 26 04:54:03 2018
From: report at bugs.python.org (Andreas Jung)
Date: Mon, 26 Mar 2018 08:54:03 +0000
Subject: [issue33142] Fatal Python error: Py_Initialize: Unable to get the
 locale encoding on Debian/Python 3.6.4 source build
In-Reply-To: <1522054349.44.0.467229070634.issue33142@psf.upfronthosting.co.za>
Message-ID: <1522054443.67.0.467229070634.issue33142@psf.upfronthosting.co.za>


Change by Andreas Jung <ajung at users.sourceforge.net>:


----------
components: +Installation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33142>
_______________________________________

From report at bugs.python.org  Mon Mar 26 05:06:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 09:06:22 +0000
Subject: [issue31947] names=None case is not handled by EnumMeta._create_
 method
In-Reply-To: <1509880866.58.0.213398074469.issue31947@psf.upfronthosting.co.za>
Message-ID: <1522055182.34.0.467229070634.issue31947@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)
nosy: +barry, eli.bendersky, ethan.furman
stage:  -> patch review
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31947>
_______________________________________

From report at bugs.python.org  Mon Mar 26 05:26:20 2018
From: report at bugs.python.org (Anders Rundgren)
Date: Mon, 26 Mar 2018 09:26:20 +0000
Subject: [issue33143] encode UTF-16 generates unexpected results
Message-ID: <1522056380.43.0.467229070634.issue33143@psf.upfronthosting.co.za>


New submission from Anders Rundgren <anders.rundgren.net at gmail.com>:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> v = '\u20ac'
>>> print (v)
?
>>> v.encode('utf-16')
b'\xff\xfe\xac '
>>> v.encode('utf-16_be')
b' \xac'

I had expected to get pair of bytes with 20 AC for the ? symbol

----------
components: Unicode
messages: 314443
nosy: anders.rundgren.net at gmail.com, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: encode UTF-16 generates unexpected results
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33143>
_______________________________________

From report at bugs.python.org  Mon Mar 26 05:42:57 2018
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen?=)
Date: Mon, 26 Mar 2018 09:42:57 +0000
Subject: [issue33122] ftplib: FTP_TLS seems to have problems with sites that
 close the encrypted channel themselfes
In-Reply-To: <1521728978.52.0.467229070634.issue33122@psf.upfronthosting.co.za>
Message-ID: <1522057377.92.0.467229070634.issue33122@psf.upfronthosting.co.za>


J?rgen <jottbe at sags-per-mail.de> added the comment:

Hi, thanks for tanking care of this issue.
I am mainly working on a windows client and connect to a z/OS host.
Attached you find the ftplib.py I patched to workaround this.

Here is the output of the list command which ends up in an exception (this time from a unix machine, where I still have found the unpatched version of ftplib.py): 

>>> ftplib.FTP_TLS.debugging=True
>>> conn=ftplib.FTP_TLS(host=url, user=user, passwd=passw)
*resp* '220-TCPFT000 IBM FTP CS V2R2 at tcpip06, 11:38:07 on 2018-03-26.\n220 Connection will close if idle for more than 5 minutes.'
*cmd* 'AUTH TLS'
*resp* '234 Security environment established - ready for negotiation'
*cmd* 'USER SBxxxxx'
*resp* '331 Send password please.'
*cmd* 'PASS ********'
*resp* '230 SBxxxxx is logged on.  Working directory is "SBxxxxx.".'
>>> conn.prot_p()
*cmd* 'PBSZ 0'
*resp* '200 Protection buffer size accepted'
*cmd* 'PROT P'
*resp* '200 Data connection protection set to private'
'200 Data connection protection set to private'
>>> conn.retrlines("LIST 'SBxxxxx.SBxxxxx.*'")
*cmd* 'TYPE A'
*resp* '200 Representation type is Ascii NonPrint'
*cmd* 'PASV'
*resp* '227 Entering Passive Mode (53,113,100,193,250,60)'
*cmd* "LIST 'SBxxxxx.SBxxxxx.*'"
*resp* '125 List started OK'
Volume Unit    Referred Ext Used Recfm Lrecl BlkSz Dsorg Dsname
IDV101 3390   2018/03/21 16   68  VB    4092  4096  PS  'SBxxxxx.SBxxxxx.SPUFI.OUT'
Migrated                                                'SBxxxxx.SBxxxxx.SPUFI.SOAOUT'
IDV10T 3390   2018/03/08 13   62  VB    4092  4096  PS  'SBxxxxx.SBxxxxx.SPUFI.WHC'
Migrated                                                'SBxxxxx.SBxxxxx.VI870V'
Migrated                                                'SBxxxxx.SBxxxxx.VI871V'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/ftplib.py", line 484, in retrlines
    conn.unwrap()
  File "/usr/lib/python3.4/ssl.py", line 811, in unwrap
    s = self._sslobj.shutdown()
OSError: [Errno 0] Error

----------
Added file: https://bugs.python.org/file47500/ftplib.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33122>
_______________________________________

From report at bugs.python.org  Mon Mar 26 06:22:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 10:22:29 +0000
Subject: [issue33143] encode UTF-16 generates unexpected results
In-Reply-To: <1522056380.43.0.467229070634.issue33143@psf.upfronthosting.co.za>
Message-ID: <1522059749.39.0.467229070634.issue33143@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

b'\x20' is the same as b' '.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33143>
_______________________________________

From report at bugs.python.org  Mon Mar 26 06:28:57 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 10:28:57 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522060137.7.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

That's a tough one. Because C.d is not set to a descriptor at type creation time (it's set to a Field object), the __set_name__ behavior is never invoked. It's when the @dataclass decorator is called that C.d is set to D().

https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

I'm not sure it's possible to work around this without duplicating some of the type creation code, and even then I'm not convinced it's doable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 06:47:31 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 10:47:31 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522061251.25.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I suppose I could, when overwriting the class member, check for inspect.ismethoddescriptor and call __set_name__ myself.

----------
components: +Library (Lib)
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 08:24:47 2018
From: report at bugs.python.org (Erik Bray)
Date: Mon, 26 Mar 2018 12:24:47 +0000
Subject: [issue20082] Misbehavior of BufferedRandom.write with raw file in
 append mode
In-Reply-To: <1388187192.84.0.682821163597.issue20082@psf.upfronthosting.co.za>
Message-ID: <1522067087.68.0.467229070634.issue20082@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

I keep forgetting about this (given that it's like 5 years old now).  Let me see if I can make a new PR for it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20082>
_______________________________________

From report at bugs.python.org  Mon Mar 26 08:33:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Mar 2018 12:33:51 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1522067631.36.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Harmut, thanks for the status update!

Victor, the problem is that both sys.warnoptions and sys._xoptions get read by Py_Initialize(), so setting them afterwards is essentially pointless - while you do still change the contents of the sys attributes, doing so doesn't have any further effect.

In 3.8, we'll hopefully make an updated version of PEP 432 public, and hence be able to deprecate calling them prior to Py_InitializeCore, and either advise folks to use the the new config structs instead, or else adjust the way that _PySys_BeginInit and _PySys_EndInit work so that the relevant sys module attributes get created in Py_InitializeCore rather than in Py_InitializeMainInterpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 26 08:34:49 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Mar 2018 12:34:49 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1522067689.87.0.467229070634.issue33042@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/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 26 08:50:47 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Mar 2018 12:50:47 +0000
Subject: [issue33042] New 3.7 startup sequence crashes PyInstaller
In-Reply-To: <1520701247.46.0.467229070634.issue33042@psf.upfronthosting.co.za>
Message-ID: <1522068647.16.0.467229070634.issue33042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just noting that while I've closed this issue as fixed, I think we still have quite a bit of work to do to get our handling of these pre-init config settings to a place we're genuinely happy with (or as happy as backwards compatibility constraints permit).

However, the next step in that process is likely to involve at least myself, Victor & Eric getting together in person to discuss it at PyCon US (as I'm pretty sure we'll all be there this year), and deciding on how we'd like PEP 432 to look for Python 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33042>
_______________________________________

From report at bugs.python.org  Mon Mar 26 08:52:59 2018
From: report at bugs.python.org (Anders Rundgren)
Date: Mon, 26 Mar 2018 12:52:59 +0000
Subject: [issue33143] encode UTF-16 generates unexpected results
In-Reply-To: <1522056380.43.0.467229070634.issue33143@psf.upfronthosting.co.za>
Message-ID: <1522068779.29.0.467229070634.issue33143@psf.upfronthosting.co.za>


Anders Rundgren <anders.rundgren.net at gmail.com> added the comment:

Thanx for the superquick response!
I really appreciate it.

I'm obviously a Python n00b

Anders

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33143>
_______________________________________

From report at bugs.python.org  Mon Mar 26 09:49:01 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 13:49:01 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522061251.25.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <CAP0nE65aF-1-WubbFEHcHuKmVu40Xi_uoU3V0MdcYGhC45dRcQ@mail.gmail.com>


Rick Teachey <ricky at teachey.org> added the comment:

hmmm... if I check the C.d class attribute it seems to return the
descriptor instance object (not a field object) before any C instances have
been created. i guess this is just a part of how the dataclass
implementation works.

i didn't realize there's nothing "special" going on with descriptors here-
the descriptors "just work" by virtue of being set to the class attribute
at creation time. interesting.

maybe because of this descriptors should short-circuit the field creation
process entirely? that would be a shame though. having the option of
auto-including a descriptor in the class repr turns out to be very useful
and i'm already playing around with it in a project.

one idea: what if it there were a keyword argument to mark a field as a
descriptor, allowing tje descriptor to be set at type creation? this would
need to disallow init=True, i think. and setting a field default to a
descriptor class would then raise a type error.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler

On Mon, Mar 26, 2018 at 6:47 AM, Eric V. Smith <report at bugs.python.org>
wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> I suppose I could, when overwriting the class member, check for
> inspect.ismethoddescriptor and call __set_name__ myself.
>
> ----------
> components: +Library (Lib)
> versions: +Python 3.8
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33141>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 09:49:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 13:49:48 +0000
Subject: [issue24024] str.__doc__ needs an update
In-Reply-To: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za>
Message-ID: <1522072188.34.0.467229070634.issue24024@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The current docstring is correct. The signature str(object, encoding="utf-8", errors="strict") is not correct, because str(object) is not the same as str(object, encoding="utf-8", errors="strict").

>>> str([1, 2])
'[1, 2]'
>>> str([1, 2], encoding="utf-8", errors="strict")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: decoding to str: need a bytes-like object, list found
>>> str(b'abc')
__main__:1: BytesWarning: str() on a bytes instance
"b'abc'"
>>> str(b'abc', encoding="utf-8", errors="strict")
'abc'

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24024>
_______________________________________

From report at bugs.python.org  Mon Mar 26 10:17:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 14:17:54 +0000
Subject: [issue30100] WeakSet should allow discard and remove on items that
 can't have weak references
In-Reply-To: <1492579230.86.0.379456919312.issue30100@psf.upfronthosting.co.za>
Message-ID: <1522073874.64.0.467229070634.issue30100@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30100>
_______________________________________

From report at bugs.python.org  Mon Mar 26 10:56:22 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 26 Mar 2018 14:56:22 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1522076182.06.0.467229070634.issue24925@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hey Jurjen,

Do you mind converting your patch in a Pull request please?

----------
nosy: +CuriousLearner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:00:28 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 26 Mar 2018 15:00:28 +0000
Subject: [issue33144] random._randbelow optimization
Message-ID: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>


New submission from Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:

Given that the random module goes a long way to ensure optimal performance, I was wondering why the check for a match between the random and getrandbits methods is performed per call of Random._randbelow, when it could also be done at instantiation time (the attached patch uses __init_subclass__ for that purpose and, in my hands, gives 10-25% speedups for calls to methods relying on _randbelow).
Is it really necessary to guard against someone monkey patching the methods rather than using inheritance?

----------
components: Library (Lib)
files: randbelow.patch
keywords: patch
messages: 314455
nosy: rhettinger, wolma
priority: normal
severity: normal
status: open
title: random._randbelow optimization
type: performance
versions: Python 3.8
Added file: https://bugs.python.org/file47501/randbelow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:01:36 2018
From: report at bugs.python.org (Scott Eilerman)
Date: Mon, 26 Mar 2018 15:01:36 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1522076496.27.0.467229070634.issue33114@psf.upfronthosting.co.za>


Scott Eilerman <scott.j.eilerman at gmail.com> added the comment:

Raymond, Tim, thanks for your replies so far. I understand (and for the most part, agree with) your points about not being able to list every behavior, and not wanting to cause uncertainty in users. However, let me argue my case one more time, and if you still disagree, feel free to close this.

1. It is expected (in fact, one might argue it's the entire point) that initializing random.seed() with a fixed value will produce a repeatable set of results for a traditional random number generator. An user expects that calling the following should always produce the same sequence of numbers:

random.seed(22)
random.random()
random.random()
random.random()

2. Based on that behavior for one of the most typical/traditional functions in the random module, a naive user (me) might assume that random.sample() is drawing from its population in a similar manner (i.e. that sequence of returned items, regardless of how many you ask the function to return, is uniquely determined by the seed). While this is certainly an assumption...

2a. This assumption is somewhat validated by the introductory section of the random module docs, which states "Almost all module functions depend on the basic function random()..."

2b. More importantly, an user can "validate" this assumption by doing some simple tests, e.g.:

choices = range(100)
random.seed(22)
random.sample(choices,1)
random.seed(22)
random.sample(choices,2)
random.seed(22)
random.sample(choices,3)
... and so on

Because of the nature of the set/list optimization, it is VERY possible that an user could do due diligence in testing like this (a few different seeds, a few different sets of "choices", testing up to k=10) and never uncover the problematic behavior. You'd pretty much have to set up some loops like I did earlier in this thread, which I don't think many users would do unless the expect to find a problem. Even then, with certain selections of "choices", you might still get the "expected" results.

2c. If you suspected a problem, or really wanted to be sure the function does what you assume it will do, obviously you can open up random.py and take a look. However, I doubt many users do this for every built-in module and function they use; clearly the point of documentation is to avoid this scenario.

3. As Raymond mentioned, this does not appear to be a "common" problem, and perhaps that is enough to not add anything to the docs. However, due to the somewhat elusive nature of the behavior, it could certainly go undetected in many cases, potentially causing problems without anyone noticing. Perhaps I chose a very unorthodox implementation to get the results I desired; I easily could have used random.shuffle() or random.sample(pop, len(pop)) and picked the nth element. However, one could imagine cases in which you have a very large population and you want to optimize by using sample() to get the nth random draw rather than randomizing the entire list, so I don't think it's an entirely unjustified approach.

4. Given the above points, I'd argue that a one-line insertion into the docs would help users steer clear of a hard-to-anticipate, potentially costly pitfall. My suggested language is a more direct identification of the possible consequences, though I agree that it it perhaps too worry-inducing without specifying the "cause" of the problem. Raymond's algorithmic note may be a better choice and would have been enough of an indicator for me to avoid the mistake I made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:02:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 15:02:21 +0000
Subject: [issue31504] Documentation for return value for string.rindex is
 missing when search string is empty
In-Reply-To: <1505721887.17.0.00733091873512.issue31504@psf.upfronthosting.co.za>
Message-ID: <1522076541.01.0.467229070634.issue31504@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31504>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:04:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 15:04:44 +0000
Subject: [issue6986] _json crash on scanner/encoder initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1522076684.48.0.467229070634.issue6986@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7c2d97827fd2ccd72ab7a98427f87fcfe3891644 by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-6986: Add a comment to clarify a test of _json.make_encoder(). (GH-3789)
https://github.com/python/cpython/commit/7c2d97827fd2ccd72ab7a98427f87fcfe3891644


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6986>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:20:48 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 15:20:48 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522077648.71.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Nick Coghlan suggested (on python-dev) to have Field implement __set_name__ and call through to the default value, if it exists.

That approach seems to work fine. I'll generate a PR with tests sometime before today's release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:24:20 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 26 Mar 2018 15:24:20 +0000
Subject: [issue31201] make test: module test that failed doesn't exist
In-Reply-To: <1502707428.17.0.905101363291.issue31201@psf.upfronthosting.co.za>
Message-ID: <1522077860.55.0.467229070634.issue31201@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
title: module test that failed doesn't exist -> make test: module test that failed doesn't exist
type:  -> enhancement
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31201>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:46:04 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 15:46:04 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522079164.36.0.467229070634.issue33141@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Sounds like a relatively easy solution then. Hopefully it makes the beta 3 so I can use it immediately- thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:57:26 2018
From: report at bugs.python.org (Steven Downum)
Date: Mon, 26 Mar 2018 15:57:26 +0000
Subject: [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1522079846.47.0.467229070634.issue24356@psf.upfronthosting.co.za>


Change by Steven Downum <devilaether at gmail.com>:


----------
nosy: +steven.downum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24356>
_______________________________________

From report at bugs.python.org  Mon Mar 26 11:59:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 15:59:23 +0000
Subject: [issue31920] pygettext ignores directories as inputfile argument
In-Reply-To: <1509611840.93.0.213398074469.issue31920@psf.upfronthosting.co.za>
Message-ID: <1522079963.88.0.467229070634.issue31920@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +5982
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31920>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:29:47 2018
From: report at bugs.python.org (Rolf Eike Beer)
Date: Mon, 26 Mar 2018 16:29:47 +0000
Subject: [issue33145] unaligned accesses in siphash24() lead to crashes on
 sparc
Message-ID: <1522081787.81.0.467229070634.issue33145@psf.upfronthosting.co.za>


Change by Rolf Eike Beer <eike at sf-mail.de>:


----------
components: Library (Lib)
nosy: Dakon
priority: normal
pull_requests: 5983
severity: normal
status: open
title: unaligned accesses in siphash24() lead to crashes on sparc
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33145>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:30:48 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 16:30:48 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522081848.91.0.467229070634.issue33141@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

I suppose one downside of that solution is __set_name__ will be called for every Field whether or not it is need. Probably can't be helped without major complications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:34:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 16:34:22 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522082062.48.0.467229070634.issue33141@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +5984
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:40:34 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 26 Mar 2018 16:40:34 +0000
Subject: [issue33146] contextlib.suppress should capture exception for
 inspection and filter on substrings
Message-ID: <1522082434.07.0.467229070634.issue33146@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

I propose the following expansion of the interface of contextlib.suppress. Currently, when entering the context, suppress returns None. Instead, it could return an object that provides some detail about the exception.

Inspiration for an implementation exists in pytest (https://github.com/pytest-dev/pytest/blob/ff3d13ed0efab6692a07059b1d61c53eec6e0412/_pytest/python_api.py#L627), capturing the commonly-encountered use-cases, where one wishes to capture, suppress, and then act on a subset of exceptions, allowing others to raise normally.

In [py-181](https://github.com/pytest-dev/py/pull/181), I suggest exposing this functionality generally, but others had an instinct similar to mine - that perhaps the stdlib should be providing this interface.

In addition to saving the exception for inspection, the pytest implementation also allows a "message" to be supplied (for those exceptions where only some subset of the class of Exception is suppressed).

I present this concept here for consideration and feedback. Can contextlib.suppress be expanded with such an interface?

----------
components: Library (Lib)
messages: 314461
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: contextlib.suppress should capture exception for inspection and filter on substrings
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33146>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:45:21 2018
From: report at bugs.python.org (Paul Hoffman)
Date: Mon, 26 Mar 2018 16:45:21 +0000
Subject: [issue33147] Update references for RFC 3548 to RFC 4648
Message-ID: <1522082721.06.0.467229070634.issue33147@psf.upfronthosting.co.za>


New submission from Paul Hoffman <phoffman at proper.com>:

serhiy-storchaka asked me to open an issue about whether Python implements RFC 4648. As far as I can tell it does, correctly, for the parts of RFC 4648 covered in the doc. My PR was about simply updating a reference to an RFC that was made obsolete.

----------
messages: 314462
nosy: paulehoffman
priority: normal
pull_requests: 5985
severity: normal
status: open
title: Update references for RFC 3548 to RFC 4648

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33147>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:45:38 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 16:45:38 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522082738.06.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't expect there to be too much usage of Field objects, so I'm not so worried about it.

If you can, try out the code in the PR. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:52:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Mar 2018 16:52:24 +0000
Subject: [issue33145] unaligned accesses in siphash24() lead to crashes on
 sparc
Message-ID: <1522083144.27.0.467229070634.issue33145@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Actually this looks like a duplicate of issue28055.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> pyhash's siphash24 assumes alignment of the data pointer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33145>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:54:10 2018
From: report at bugs.python.org (Paul Hoffman)
Date: Mon, 26 Mar 2018 16:54:10 +0000
Subject: [issue33147] Update references for RFC 3548 to RFC 4648
In-Reply-To: <1522082721.06.0.467229070634.issue33147@psf.upfronthosting.co.za>
Message-ID: <1522083250.77.0.467229070634.issue33147@psf.upfronthosting.co.za>


Paul Hoffman <phoffman at proper.com> added the comment:

I signed the contributor agreement form on 2017-06-23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33147>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:55:43 2018
From: report at bugs.python.org (Rolf Eike Beer)
Date: Mon, 26 Mar 2018 16:55:43 +0000
Subject: [issue28055] pyhash's siphash24 assumes alignment of the data pointer
In-Reply-To: <1473463742.19.0.416387824738.issue28055@psf.upfronthosting.co.za>
Message-ID: <1522083343.94.0.467229070634.issue28055@psf.upfronthosting.co.za>


Change by Rolf Eike Beer <eike at sf-mail.de>:


----------
pull_requests: +5986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28055>
_______________________________________

From report at bugs.python.org  Mon Mar 26 12:57:12 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 16:57:12 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522083432.07.0.467229070634.issue33141@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Eric, looking at the PR; note that if you do this for the __set_name__ check:

    if inspect.ismethoddescriptor(self.default):

...an object like the one below will not get its __set_name__ called, even though PEP 487 says it should:

class D:
	def __set_name__(self, o, n):
		self.name = n

class C:
	d: int = D()

if __name__ == "__main__":
	print(f"C.d.name = {C.d.name}") # __set_name__ was called
	assert inspect.ismethoddescriptor(C.d) # Error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:00:40 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 17:00:40 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522083640.8.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Yes, I noticed the same thing. I'll remove the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:03:21 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 17:03:21 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522083801.17.0.467229070634.issue33141@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Yeah and I think lines 2709-2712 of TestDescriptors also needs removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:05:19 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 17:05:19 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522083919.02.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I've updated the PR.

I left those lines in, and added a different test. After all, it does need to work with real descriptors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:09:15 2018
From: report at bugs.python.org (Rick Teachey)
Date: Mon, 26 Mar 2018 17:09:15 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522084155.83.0.467229070634.issue33141@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Looks great to me. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:29:19 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 17:29:19 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522085359.0.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset de7a2f04d6b9427d568fcb43b6f512f9b4c4bd84 by Eric V. Smith in branch 'master':
bpo-33141: Have dataclasses.Field pass through __set_name__ to any default argument. (GH-6260)
https://github.com/python/cpython/commit/de7a2f04d6b9427d568fcb43b6f512f9b4c4bd84


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:29:42 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 17:29:42 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522085382.23.0.467229070634.issue33141@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5987

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:40:00 2018
From: report at bugs.python.org (Rolf Eike Beer)
Date: Mon, 26 Mar 2018 17:40:00 +0000
Subject: [issue28055] pyhash's siphash24 assumes alignment of the data pointer
In-Reply-To: <1473463742.19.0.416387824738.issue28055@psf.upfronthosting.co.za>
Message-ID: <1522086000.6.0.467229070634.issue28055@psf.upfronthosting.co.za>


Rolf Eike Beer <eike at sf-mail.de> added the comment:

So, what is the problem with this? Either the compiler knows that unaligned accesses are no problem and optimizes them away anyway, or it is kept because it would crash otherwise. I can confirm that no sparc version >= 3.5 (have not tried older) survives the test suite on Gentoo Sparc (64 bit kernel, 32 bit userspace) without memcpy().

----------
nosy: +Dakon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28055>
_______________________________________

From report at bugs.python.org  Mon Mar 26 13:55:15 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 17:55:15 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522086915.96.0.467229070634.issue33141@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c6147acd2ce5fa9e344f179b539f3b21b9ae1a6d by Miss Islington (bot) in branch '3.7':
bpo-33141: Have dataclasses.Field pass through __set_name__ to any default argument. (GH-6260)
https://github.com/python/cpython/commit/c6147acd2ce5fa9e344f179b539f3b21b9ae1a6d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 14:14:56 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Mar 2018 18:14:56 +0000
Subject: [issue33141] descriptor __set_name__ feature broken for dataclass
 descriptor fields
In-Reply-To: <1522031149.18.0.467229070634.issue33141@psf.upfronthosting.co.za>
Message-ID: <1522088096.63.0.467229070634.issue33141@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks for the bug report.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33141>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:16:07 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Mon, 26 Mar 2018 19:16:07 +0000
Subject: [issue1704621] interpreter crash when multiplying large lists
Message-ID: <1522091767.31.0.467229070634.issue1704621@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

Hi!

This is broken for tuples (but not for lists, as in the example here) in 2.7.14 for me. Should we reopen this issue and fix it better?

[builder at localhost ~]$ python
Python 2.7.14 (default, Nov  7 2017, 17:07:17) 
[GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [0] * 2**20
>>> x *= 2**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> x = [0,0,0,0,0,0] * 2**20
>>> x *= 2**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> x = ('a', 'b')
>>> x = ('a', 'b') * 2**20
>>> x *= 2**20
Segmentation fault
[builder at localhost ~]$ python --version
Python 2.7.14
[builder at localhost ~]$ python
Python 2.7.14 (default, Nov  7 2017, 17:07:17) 
[GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize
2147483647
>>> sys.maxint
2147483647
>>> 
[builder at localhost ~]$ python RPM/BUILD/Python-2.7.14/Lib/test/test_tuple.py
test_addmul (__main__.TupleTest) ... ok
test_bigrepeat (__main__.TupleTest) ... Segmentation fault
[builder at localhost ~]$

----------
nosy: +imz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1704621>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:21:03 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 26 Mar 2018 19:21:03 +0000
Subject: [issue1704621] interpreter crash when multiplying large lists
Message-ID: <1522092063.45.0.467229070634.issue1704621@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

@imz Please file a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1704621>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:36:01 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Mar 2018 19:36:01 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1522092961.38.0.467229070634.issue4819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Given that Misc/cheatsheet doesn't exist any more in the Python 3 repo, and Python 2 is nearing end-of-life, I suspect this should just be closed.

----------
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:47:01 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Mar 2018 19:47:01 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
In-Reply-To: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>
Message-ID: <1522093621.2.0.467229070634.issue33128@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +3.7regression
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:49:38 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 26 Mar 2018 19:49:38 +0000
Subject: [issue32844] subprocess may incorrectly redirect a low fd to stderr
 if another low fd is closed
In-Reply-To: <1518642648.87.0.467229070634.issue32844@psf.upfronthosting.co.za>
Message-ID: <1522093778.08.0.467229070634.issue32844@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 0e7144b064a19493a146af94175a087b3888c37b by Gregory P. Smith (Alexey Izbyshev) in branch 'master':
bpo-32844: Fix a subprocess misredirection of a low fd (GH5689)
https://github.com/python/cpython/commit/0e7144b064a19493a146af94175a087b3888c37b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32844>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:49:52 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 19:49:52 +0000
Subject: [issue32844] subprocess may incorrectly redirect a low fd to stderr
 if another low fd is closed
In-Reply-To: <1518642648.87.0.467229070634.issue32844@psf.upfronthosting.co.za>
Message-ID: <1522093792.41.0.467229070634.issue32844@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5988

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32844>
_______________________________________

From report at bugs.python.org  Mon Mar 26 15:50:46 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 19:50:46 +0000
Subject: [issue32844] subprocess may incorrectly redirect a low fd to stderr
 if another low fd is closed
In-Reply-To: <1518642648.87.0.467229070634.issue32844@psf.upfronthosting.co.za>
Message-ID: <1522093846.36.0.467229070634.issue32844@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5989

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32844>
_______________________________________

From report at bugs.python.org  Mon Mar 26 16:14:12 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 20:14:12 +0000
Subject: [issue32844] subprocess may incorrectly redirect a low fd to stderr
 if another low fd is closed
In-Reply-To: <1518642648.87.0.467229070634.issue32844@psf.upfronthosting.co.za>
Message-ID: <1522095252.11.0.467229070634.issue32844@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 05455637f3ba9bacd459700f4feab783e5967d69 by Miss Islington (bot) in branch '3.7':
bpo-32844: Fix a subprocess misredirection of a low fd (GH5689)
https://github.com/python/cpython/commit/05455637f3ba9bacd459700f4feab783e5967d69


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32844>
_______________________________________

From report at bugs.python.org  Mon Mar 26 16:43:26 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Mar 2018 20:43:26 +0000
Subject: [issue33146] contextlib.suppress should capture exception for
 inspection and filter on substrings
In-Reply-To: <1522082434.07.0.467229070634.issue33146@psf.upfronthosting.co.za>
Message-ID: <1522097006.66.0.467229070634.issue33146@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

What kind useful information to you expect to get before an exception is raised?

For example:

    with suppress(FileNotFoundError) as e:
         os.remove(somefile)

What could *e* possibly be that would be useful.  AFAICT, all we know at the time of __enter__ is the exception class.  No new information was created by the context manager call.

Ideally, it would be great is this API were to remain simple.  User code would likely be more clear if any other logic were done outside the context manager rather than happening indirectly and inexplicitly in the suppress call.  To me, "suppress" means suppress -- it doesn't mean capture and analyze that which is ignored.  So, at first glance, this seems like a mix of feature creep and mission creep.

----------
nosy: +ncoghlan, rhettinger
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33146>
_______________________________________

From report at bugs.python.org  Mon Mar 26 16:43:48 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 20:43:48 +0000
Subject: [issue32844] subprocess may incorrectly redirect a low fd to stderr
 if another low fd is closed
In-Reply-To: <1518642648.87.0.467229070634.issue32844@psf.upfronthosting.co.za>
Message-ID: <1522097028.91.0.467229070634.issue32844@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 57db13e582ad269d6e067fe934122207cc992739 by Miss Islington (bot) in branch '3.6':
bpo-32844: Fix a subprocess misredirection of a low fd (GH5689)
https://github.com/python/cpython/commit/57db13e582ad269d6e067fe934122207cc992739


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32844>
_______________________________________

From report at bugs.python.org  Mon Mar 26 17:03:06 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 26 Mar 2018 21:03:06 +0000
Subject: [issue32844] subprocess may incorrectly redirect a low fd to stderr
 if another low fd is closed
In-Reply-To: <1518642648.87.0.467229070634.issue32844@psf.upfronthosting.co.za>
Message-ID: <1522098186.0.0.467229070634.issue32844@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32844>
_______________________________________

From report at bugs.python.org  Mon Mar 26 18:01:20 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 26 Mar 2018 22:01:20 +0000
Subject: [issue32873] Pickling of typing types
In-Reply-To: <1519037205.03.0.467229070634.issue32873@psf.upfronthosting.co.za>
Message-ID: <1522101680.97.0.467229070634.issue32873@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 834940375ae88bc95794226dd8eff1f25fba1cf9 by Ivan Levkivskyi in branch 'master':
bpo-32873: Treat type variables and special typing forms as immutable by copy and pickle (GH-6216)
https://github.com/python/cpython/commit/834940375ae88bc95794226dd8eff1f25fba1cf9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32873>
_______________________________________

From report at bugs.python.org  Mon Mar 26 18:02:33 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 22:02:33 +0000
Subject: [issue32873] Pickling of typing types
In-Reply-To: <1519037205.03.0.467229070634.issue32873@psf.upfronthosting.co.za>
Message-ID: <1522101753.46.0.467229070634.issue32873@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5990

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32873>
_______________________________________

From report at bugs.python.org  Mon Mar 26 18:29:14 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 26 Mar 2018 22:29:14 +0000
Subject: [issue32873] Pickling of typing types
In-Reply-To: <1519037205.03.0.467229070634.issue32873@psf.upfronthosting.co.za>
Message-ID: <1522103354.69.0.467229070634.issue32873@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d0e04c82448c750d4dc27f2bddeddea74bd353ff by Miss Islington (bot) in branch '3.7':
bpo-32873: Treat type variables and special typing forms as immutable by copy and pickle (GH-6216)
https://github.com/python/cpython/commit/d0e04c82448c750d4dc27f2bddeddea74bd353ff


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32873>
_______________________________________

From report at bugs.python.org  Mon Mar 26 18:37:31 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 26 Mar 2018 22:37:31 +0000
Subject: [issue32873] Pickling of typing types
In-Reply-To: <1519037205.03.0.467229070634.issue32873@psf.upfronthosting.co.za>
Message-ID: <1522103851.0.0.467229070634.issue32873@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32873>
_______________________________________

From report at bugs.python.org  Mon Mar 26 18:50:43 2018
From: report at bugs.python.org (Vitaly Kruglikov)
Date: Mon, 26 Mar 2018 22:50:43 +0000
Subject: [issue33148] RuntimeError('Event loop is closed') after cancelling
 getaddrinfo and closing loop
Message-ID: <1522104643.31.0.467229070634.issue33148@psf.upfronthosting.co.za>


New submission from Vitaly Kruglikov <vitaly.krug at gmail.com>:

I see this exception on the terminal:
```
exception calling callback for <Future at 0x10722ee48 state=finished returned list>
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/futures.py", line 414, in _call_set_state
    dest_loop.call_soon_threadsafe(_set_state, destination, source)
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 620, in call_soon_threadsafe
    self._check_closed()
  File "/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 357, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
```

When executing this code:
```
import asyncio

while True:
    loop = asyncio.new_event_loop()

    coro = loop.getaddrinfo('www.google.com', 80)

    task = asyncio.ensure_future(coro, loop=loop)

    task.cancel()

    loop.call_soon_threadsafe(loop.stop)

    loop.run_forever()

    loop.close()
```

Shouldn't a cancelled operation go away (or at least pretend to go away) cleanly?

----------
components: asyncio
messages: 314484
nosy: asvetlov, vitaly.krug, yselivanov
priority: normal
severity: normal
status: open
title: RuntimeError('Event loop is closed') after cancelling getaddrinfo and closing loop
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33148>
_______________________________________

From report at bugs.python.org  Mon Mar 26 19:57:24 2018
From: report at bugs.python.org (Isaac Elliott)
Date: Mon, 26 Mar 2018 23:57:24 +0000
Subject: [issue33149] Parser stack overflows
Message-ID: <1522108643.61.0.467229070634.issue33149@psf.upfronthosting.co.za>


New submission from Isaac Elliott <isaace71295 at gmail.com>:

python3's parser stack overflows on deeply-nested expressions, for example:

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

or

aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa(aa()))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

These are both minimal examples, so if you remove one level of nesting from either then python3 will behave normally.

----------
messages: 314485
nosy: Isaac Elliott
priority: normal
severity: normal
status: open
title: Parser stack overflows
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33149>
_______________________________________

From report at bugs.python.org  Mon Mar 26 20:20:40 2018
From: report at bugs.python.org (Isaac Elliott)
Date: Tue, 27 Mar 2018 00:20:40 +0000
Subject: [issue33149] Parser stack overflows
In-Reply-To: <1522108643.61.0.467229070634.issue33149@psf.upfronthosting.co.za>
Message-ID: <1522110040.69.0.467229070634.issue33149@psf.upfronthosting.co.za>


Isaac Elliott <isaace71295 at gmail.com> added the comment:

Because of the way recursive descent parsing works,

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[

is actually the minimal input required to reproduce this in python3.

In python2, the bug is still present, but requires a slightly deeper nesting:

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33149>
_______________________________________

From report at bugs.python.org  Mon Mar 26 20:54:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 00:54:27 +0000
Subject: [issue33114] random.sample() behavior is unexpected/unclear from docs
In-Reply-To: <1521643977.18.0.467229070634.issue33114@psf.upfronthosting.co.za>
Message-ID: <1522112067.98.0.467229070634.issue33114@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>  However, let me argue my case one more time, and if you still disagree, feel free to close this.

Thank you for expressing your ideas so clearly.  However, I'm going to go with Tim's recommendation and leave the docs as is.

At this point, you already have a complete understanding of what the tool does and how to use it, so there isn't anything at stake other than a feeling a vindication for a bug that is already resolved.  Looking to the needs of other users, I think we're best off not even bringing up non-guaranteed implementation details and instead follow the example of Numpy and R.  Thanks again for the suggestion, but we'll respectfully decline this time around.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33114>
_______________________________________

From report at bugs.python.org  Mon Mar 26 20:55:18 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 27 Mar 2018 00:55:18 +0000
Subject: [issue33148] RuntimeError('Event loop is closed') after cancelling
 getaddrinfo and closing loop
In-Reply-To: <1522104643.31.0.467229070634.issue33148@psf.upfronthosting.co.za>
Message-ID: <1522112118.77.0.467229070634.issue33148@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Yeah, getaddrinfo isn't actually cancellable (because it's a blocking call that has to be run in a thread), but it's side-effect-free so if the user requests that it be cancelled then it's safe to return immediately while it keeps running in the background, and asyncio does so. But if we've already decided to discard the result then it's better to do that silently, like you say.

When trio hits this case, it does silently throw away the result: https://github.com/python-trio/trio/blob/aebb42888dd0978c3b74f8c9cdf8aec2ce2cbd73/trio/_threads.py#L372-L377
It's a little bit more obvious in trio's case because there we 100% know that if the call to `trio.run` has finished, then there's no-one listening for the result, and that the user has explicitly requested this behavior. In asyncio's case, I guess in *theory* someone could still be hoping the Future's done callback will be invoked even after the loop is closed. This seems unlikely though... and in general when the loop is closed then every other registered callback is silently discarded, so doing that for run_in_executor seems fine too.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33148>
_______________________________________

From report at bugs.python.org  Mon Mar 26 21:25:45 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 01:25:45 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522113945.43.0.467229070634.issue33144@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> it could also be done at instantiation time (the attached patch
> uses __init_subclass__ for that purpose 

FWIW, a 10-25% speedup is only possible because the remaining code is already somewhat fast.  All that is being proposed is removing couple of lines that elsewhere would be considered somewhat thin:

        random = self.random
        if type(random) is BuiltinMethod \
           or type(getrandbits) is Method:

Overall, the idea of doing the check only once at instantiation time seems promising.  That said, I have unspecific general worries about using __init_subclass__ and patching the subclass.  Perhaps Serhiy, Tim, or Mark will have thoughts on whether this sort of self-patching is something we want to be doing in the standard library, whether it would benefit PyPy, and whether it has risks to existing code, to debugging and testing, and to future maintenance.

If I were the one to go the route of making a single pre-check, my instinct would be to just set a flag in __init__, so that the above code would simplify to:

        if self._valid_getrandbits:
            ...

----------
assignee:  -> rhettinger
nosy: +mark.dickinson, serhiy.storchaka, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Mon Mar 26 21:29:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 01:29:36 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1522114176.36.0.467229070634.issue27212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset da1734c58d2f97387ccc9676074717d38b044128 by Raymond Hettinger (Cheryl Sabella) in branch 'master':
bpo-27212: Modify islice recipe to consume initial values preceding start (GH-6195)
https://github.com/python/cpython/commit/da1734c58d2f97387ccc9676074717d38b044128


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Mon Mar 26 21:30:51 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 27 Mar 2018 01:30:51 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1522114251.58.0.467229070634.issue27212@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Mon Mar 26 21:31:43 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 27 Mar 2018 01:31:43 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1522114303.9.0.467229070634.issue27212@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Mon Mar 26 22:23:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 02:23:36 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1522117416.81.0.467229070634.issue27212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset f328caf4caafd4521c356af8cb8a299f27603c90 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-27212: Modify islice recipe to consume initial values preceding start (GH-6195) (#GH-6266)
https://github.com/python/cpython/commit/f328caf4caafd4521c356af8cb8a299f27603c90


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Mon Mar 26 22:24:04 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 02:24:04 +0000
Subject: [issue27212] Doc for itertools,
 'islice()' implementation have unwanted behavior for recipe
 'consume()'
In-Reply-To: <1465018426.98.0.63725897135.issue27212@psf.upfronthosting.co.za>
Message-ID: <1522117444.91.0.467229070634.issue27212@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c8698cff7ccc8dc730c58523c7ef4113ea8d3049 by Raymond Hettinger (Miss Islington (bot)) in branch '3.6':
bpo-27212: Modify islice recipe to consume initial values preceding start (GH-6195) (GH-6267)
https://github.com/python/cpython/commit/c8698cff7ccc8dc730c58523c7ef4113ea8d3049


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27212>
_______________________________________

From report at bugs.python.org  Mon Mar 26 22:39:48 2018
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Tue, 27 Mar 2018 02:39:48 +0000
Subject: [issue33150] Signature error for methods of class
 configparser.Interpolation
Message-ID: <1522118388.18.0.467229070634.issue33150@psf.upfronthosting.co.za>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

I am not sure whether this is already covered by an issue, it is present in 3.6.2 and 3.6.4.

The class Interpolation in the configparser module causes an exception:

  File "/opt/python/python-3.6.4/lib/python3.6/configparser.py", line 1123, in _join_multiline_values
    name, val)
TypeError: before_read() missing 1 required positional argument: 'value'


This is due to the missing 'parser' parameter at the call of 'Interploation.xyz()' methods, also the case for several other method calls.


class Interpolation:
    """Dummy interpolation that passes the value through with no changes."""

    def before_read(self, parser, section, option, value):
        return value

   ...

Same for derived classes see e.g.

   class BasicInterpolation(Interpolation):
   ...

   class ExtendedInterpolation(Interpolation):
   ...

A work around seems to be:

- defining a dummy with changed signatures as parameter 'interpolation'

----------
components: Argument Clinic, Build, asyncio
messages: 314493
nosy: acue, asvetlov, larry, yselivanov
priority: normal
severity: normal
status: open
title: Signature error for methods of class configparser.Interpolation
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33150>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:10:18 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 27 Mar 2018 03:10:18 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522120218.25.0.467229070634.issue33144@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I don't see anything objectionable about the class optimizing the implementation of a private method.

I'll note that there's a speed benefit beyond just removing the two type checks in the common case:  the optimized `_randbelow()` also avoids populating its locals with 5 unused formal arguments (which are just "a trick" to change what would otherwise have been global accesses into local accesses).  So it actually makes the method implementation cleaner & clearer too.

But it's really the speed that matters here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:24:05 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 03:24:05 +0000
Subject: [issue30100] WeakSet should allow discard and remove on items that
 can't have weak references
In-Reply-To: <1492579230.86.0.379456919312.issue30100@psf.upfronthosting.co.za>
Message-ID: <1522121045.77.0.467229070634.issue30100@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> my original motivating case was objects that are hashable but not weakly referenceable.  

It is probably not good design to extend discard() to handle types that aren't handled by the other methods.  To me, it isn't at all surprising that the business of a WeakSet is to handle objects that are both hashable and weak referenceable.  Muddying those waters may do more harm than good.  My recommendation is to decline the feature request.

One other thought.  As the Python world starts to encourage type annotations and static type checking, one benefit we would hope for is code with cleaner matches between the caller and callee signatures.  Accordingly, we shouldn't encourage people to write code with odd signatures:
  
    x : thing_that_cant_possibly_be_in_the_weakset
    some_weakset.discard(x)  # Someday, we might hope this would be flagged

----------
status: pending -> open
type:  -> enhancement
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30100>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:30:38 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 03:30:38 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522121438.26.0.467229070634.issue33144@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> the optimized `_randbelow()` also avoids populating its locals 
> with 5 unused formal arguments

Yes, that clean-up would be nice as well :-)

Any thoughts on having __init__ set a flag versus using __init__subclass__ to backpatch the subclass?  To me, the former looks like plain python and latter doesn't seem like something that would normally be done in the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:30:58 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 03:30:58 +0000
Subject: [issue33149] Parser stack overflows
In-Reply-To: <1522108643.61.0.467229070634.issue33149@psf.upfronthosting.co.za>
Message-ID: <1522121458.78.0.467229070634.issue33149@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
superseder:  -> s_push: parser stack overflow MemoryError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33149>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:31:28 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 03:31:28 +0000
Subject: [issue33149] Parser stack overflows
In-Reply-To: <1522108643.61.0.467229070634.issue33149@psf.upfronthosting.co.za>
Message-ID: <1522121488.64.0.467229070634.issue33149@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Duplicate of issue3971

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33149>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:31:35 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 03:31:35 +0000
Subject: [issue33149] Parser stack overflows
In-Reply-To: <1522108643.61.0.467229070634.issue33149@psf.upfronthosting.co.za>
Message-ID: <1522121495.76.0.467229070634.issue33149@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33149>
_______________________________________

From report at bugs.python.org  Mon Mar 26 23:41:05 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 27 Mar 2018 03:41:05 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522122065.47.0.467229070634.issue33144@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I'm the wrong guy to ask about that.  Since I worked at Zope Corp, my natural inclination is to monkey-patch everything - but knowing full well that will offend everyone else ;-)

That said, this optimization seems straightforward to me:  two distinct method implementations for two very different approaches that have nothing in common besides the method name & signature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Tue Mar 27 00:16:30 2018
From: report at bugs.python.org (Ethan Welty)
Date: Tue, 27 Mar 2018 04:16:30 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1522124190.16.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ethan Welty <ethan.welty at gmail.com> added the comment:

Terry Reedy: I just tried your suggestion of a main clause (code below) and it made no difference.

```
import _tkinter
import numpy as np
# multiprocessing.set_start_method("spawn")
import multiprocessing

def parallel_matmul(x):
    R = np.random.randn(3, 3)
    return np.matmul(R, x)

if __name__ == '__main__':
    pool = multiprocessing.Pool(4)
    results = pool.map(parallel_matmul, [np.random.randn(3, 5000) for i in range(2)])
```

Ronald Oussoren: Good to know that perhaps upgrading to the latest OSX would resolve this issue. I tried 'spawn' and 'forkserver' with multiprocessing.set_start_method() (see above) but both result in an endless stream of errors (with or without importing a graphics backend), although that may be my not knowing how to properly use them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Tue Mar 27 00:47:44 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Mar 2018 04:47:44 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
Message-ID: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Found a bug when trying to read a resource from a subpackage in a zip file.  I was actually surprised we didn't have a test for this AFAICT, and when I added one, it did fail.

I have a PR coming soon.

----------
assignee: barry
components: Library (Lib)
messages: 314500
nosy: barry, brett.cannon
priority: normal
severity: normal
status: open
title: importlib.resources breaks on subdirectories
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 01:29:10 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Mar 2018 05:29:10 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
In-Reply-To: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>
Message-ID: <1522128550.68.0.467229070634.issue33151@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

is_resource() from zip submodules is also affected

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 01:30:49 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Mar 2018 05:30:49 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
In-Reply-To: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>
Message-ID: <1522128649.85.0.467229070634.issue33151@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
keywords: +patch
pull_requests: +5993
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 03:04:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 07:04:37 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522134277.84.0.467229070634.issue33144@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think this is excellent application of __init_subclass__. It is common to patch an instance method in __init__, but this can create a reference loop if patch it by other instance method. In this case the choice doesn't depend on arguments of __init__, and can be done at class creation time.

I like the idea in general, but have comments about the implementation.

__init_subclass__ should take **kwargs and pass it to super().__init_subclass__(). type(cls.random) is not the same as type(self.random). I would use the condition `cls.random is _random.Random.random` instead, or check if the method is in cls.__dict__.

This will break the case when random or getrandbits methods are patched after class creation or per instance, but I think we have no need to support this.

We could support also the following cases:

1.
    class Rand1(Random):
        def random(self): ...
        # _randbelow should use random()

    class Rand2(Rand1):
        def getrandbits(self): ...
        # _randbelow should use getrandbits()
        # this is broken in the current patch

2.
    class Rand1(Random):
        def getrandbits(self): ...
        # _randbelow should use getrandbits()

    class Rand2(Rand1):
        def random(self): ...
        # _randbelow should use random()
        # this is broken in the current code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Tue Mar 27 03:07:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 07:07:49 +0000
Subject: [issue33150] Signature error for methods of class
 configparser.Interpolation
In-Reply-To: <1522118388.18.0.467229070634.issue33150@psf.upfronthosting.co.za>
Message-ID: <1522134469.73.0.467229070634.issue33150@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33150>
_______________________________________

From report at bugs.python.org  Tue Mar 27 03:18:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 07:18:01 +0000
Subject: [issue33146] contextlib.suppress should capture exception for
 inspection and filter on substrings
In-Reply-To: <1522082434.07.0.467229070634.issue33146@psf.upfronthosting.co.za>
Message-ID: <1522135081.12.0.467229070634.issue33146@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not sure that contextlib.suppress() should be added at first place.

    try:
        os.remove(somefile)
    except FileNotFoundError:
        pass

is a tiny bit longer, but is more explicit, doesn't depend on the other module, works in all Python versions that have this exception, and is easily extensible.

    try:
        os.remove(somefile)
    except FileNotFoundError as e:
        # what do you want to do with e?
        pass

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33146>
_______________________________________

From report at bugs.python.org  Tue Mar 27 04:05:41 2018
From: report at bugs.python.org (Windson Yang)
Date: Tue, 27 Mar 2018 08:05:41 +0000
Subject: [issue33152] clean code
Message-ID: <1522137941.19.0.467229070634.issue33152@psf.upfronthosting.co.za>


New submission from Windson Yang <wiwindson at gmail.com>:

https://github.com/python/cpython/blob/master/Lib/timeit.py#L202

use a list comprehension instead

----------
components: Distutils
messages: 314504
nosy: Windson Yang, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: clean code
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33152>
_______________________________________

From report at bugs.python.org  Tue Mar 27 04:08:10 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Mar 2018 08:08:10 +0000
Subject: [issue33152] clean code
In-Reply-To: <1522137941.19.0.467229070634.issue33152@psf.upfronthosting.co.za>
Message-ID: <1522138090.05.0.467229070634.issue33152@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +5994
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33152>
_______________________________________

From report at bugs.python.org  Tue Mar 27 05:03:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 09:03:59 +0000
Subject: [issue33124] Lazy execution of module bytecode
In-Reply-To: <1521757031.84.0.467229070634.issue33124@psf.upfronthosting.co.za>
Message-ID: <1522141439.8.0.467229070634.issue33124@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Function definitions usually are cheap, as well as global constants definitions (unless they use complex comprehensions or call heavy functions for initialization). Creating a class is an order or more slower than creating a function. Creating enums and namedtuples is an order or two slower than creating a plain class.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33124>
_______________________________________

From report at bugs.python.org  Tue Mar 27 05:18:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 09:18:28 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1522142308.79.0.467229070634.issue31550@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If the reason of this change was making the error message more consistent with other error messages in classic classes (at the cost of larger dereference with Python 3), it LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Tue Mar 27 05:38:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 09:38:18 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1522143498.03.0.467229070634.issue33014@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with David about the docstring. But I think that no changes are needed in the module documentation. David's wording would contain two links (for iskeyword() and for keyword), and many links distract the attention.

We already spent for this issue more time than it deserves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Tue Mar 27 06:10:51 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Tue, 27 Mar 2018 10:10:51 +0000
Subject: [issue33153] interpreter crash when multiplying large tuples
Message-ID: <1522145451.62.0.467229070634.issue33153@psf.upfronthosting.co.za>


New submission from Ivan Zakharyaschev <imz at altlinux.org>:

The issue https://bugs.python.org/msg314475 has arisen for tuples (but not for lists, as in the example there) in 2.7.14 for me. How should we fix it in a better way?

This bug is not reproducible in python 3.5.4.

[builder at localhost ~]$ python
Python 2.7.14 (default, Nov  7 2017, 17:07:17) 
[GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [0] * 2**20
>>> x *= 2**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> x = [0,0,0,0,0,0] * 2**20
>>> x *= 2**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> x = ('a', 'b')
>>> x = ('a', 'b') * 2**20
>>> x *= 2**20
Segmentation fault
[builder at localhost ~]$ python --version
Python 2.7.14
[builder at localhost ~]$ python
Python 2.7.14 (default, Nov  7 2017, 17:07:17) 
[GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize
2147483647
>>> sys.maxint
2147483647
>>> 
[builder at localhost ~]$ python RPM/BUILD/Python-2.7.14/Lib/test/test_tuple.py
test_addmul (__main__.TupleTest) ... ok
test_bigrepeat (__main__.TupleTest) ... Segmentation fault
[builder at localhost ~]$

----------
components: Interpreter Core
messages: 314508
nosy: imz
priority: normal
severity: normal
status: open
title: interpreter crash when multiplying large tuples
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33153>
_______________________________________

From report at bugs.python.org  Tue Mar 27 06:11:49 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Tue, 27 Mar 2018 10:11:49 +0000
Subject: [issue1704621] interpreter crash when multiplying large lists
Message-ID: <1522145509.27.0.467229070634.issue1704621@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

New issue filed: https://bugs.python.org/issue33153

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1704621>
_______________________________________

From report at bugs.python.org  Tue Mar 27 06:12:54 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Tue, 27 Mar 2018 10:12:54 +0000
Subject: [issue33153] interpreter crash when multiplying large tuples
In-Reply-To: <1522145451.62.0.467229070634.issue33153@psf.upfronthosting.co.za>
Message-ID: <1522145574.65.0.467229070634.issue33153@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

I meant the old issue https://bugs.python.org/issue1704621 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33153>
_______________________________________

From report at bugs.python.org  Tue Mar 27 06:54:43 2018
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Tue, 27 Mar 2018 10:54:43 +0000
Subject: [issue33154] subprocess.Popen ResourceWarning should have
 activation-deactivation flags
Message-ID: <1522148083.75.0.467229070634.issue33154@psf.upfronthosting.co.za>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

The subprocess call *subprocess.Popen* in Python3.6 was added a number of resource warnings, including subprocess run-state and open files. This is a very good facility for debugging, but causes a lot of trouble for programs relying on subprocesses via the STDIO/STDERR interface. The STDIO/STDERR interfaces are very common when shell utilities are incorporated into high level Python programs.

The other issue is the unit testing of command line tools as black-box tests, these solely rely on the STDOUT and STDERR interface. I am currently finishing a subprocess test package with common code for Python2.7 and Python3.5+, so facing some trouble with IO filtering. Examples are attached.

A system call should process the common IO interfaces of the called subprocesses by default without any additional output. So a call flag and/or an environment variable should be introduced in addition, which allows the activation and deactivation of these messages.
The default should be *deactive*.

----------
components: Library (Lib)
files: python3-output.txt
messages: 314511
nosy: acue, martin.panter, pitrou, python-dev, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: subprocess.Popen ResourceWarning should have activation-deactivation flags
type: resource usage
versions: Python 3.6
Added file: https://bugs.python.org/file47502/python3-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33154>
_______________________________________

From report at bugs.python.org  Tue Mar 27 06:58:13 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Mar 2018 10:58:13 +0000
Subject: [issue33153] interpreter crash when multiplying large tuples
In-Reply-To: <1522145451.62.0.467229070634.issue33153@psf.upfronthosting.co.za>
Message-ID: <1522148293.51.0.467229070634.issue33153@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Would you paste traceback?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33153>
_______________________________________

From report at bugs.python.org  Tue Mar 27 06:59:31 2018
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Tue, 27 Mar 2018 10:59:31 +0000
Subject: [issue33154] subprocess.Popen ResourceWarning should have
 activation-deactivation flags
In-Reply-To: <1522148083.75.0.467229070634.issue33154@psf.upfronthosting.co.za>
Message-ID: <1522148371.63.0.467229070634.issue33154@psf.upfronthosting.co.za>


Arno-Can Uestuensoez <acue.opensource at gmail.com> added the comment:

See also 
issue26741 - subprocess.Popen should emit a ResourceWarning in destructor if ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33154>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:05:02 2018
From: report at bugs.python.org (daniel hahler)
Date: Tue, 27 Mar 2018 11:05:02 +0000
Subject: [issue16482] pdb.set_trace() clobbering traceback on error
In-Reply-To: <1353002125.56.0.265106335805.issue16482@psf.upfronthosting.co.za>
Message-ID: <1522148702.7.0.467229070634.issue16482@psf.upfronthosting.co.za>


daniel hahler <python-bugs at thequod.de> added the comment:

Just for reference: https://github.com/python/cpython/pull/6233 is about fixing this.

----------
keywords: +patch
nosy: +blueyed
pull_requests: +5995
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16482>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:12:36 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 27 Mar 2018 11:12:36 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1522149156.63.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

@ezwelty: The import of multiprocessing and the call to set_start_method should be at the very start of the code, before other imports, to avoid the annoying Apple behavior I mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:20:30 2018
From: report at bugs.python.org (Mads Jensen)
Date: Tue, 27 Mar 2018 11:20:30 +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: <1522149630.89.0.467229070634.issue31853@psf.upfronthosting.co.za>


Mads Jensen <mje at inducks.org> added the comment:

There are lots of legacy calls in the form of ClassName.method, which should be replaced with super().method.

----------
components: +email -SSL
nosy: +barry, r.david.murray
pull_requests: +5996

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:22:48 2018
From: report at bugs.python.org (Mads Jensen)
Date: Tue, 27 Mar 2018 11:22:48 +0000
Subject: [issue33155] Use super().method instead in Logging
Message-ID: <1522149768.39.0.467229070634.issue33155@psf.upfronthosting.co.za>


New submission from Mads Jensen <mje at inducks.org>:

There are lots of legacy calls in the form of ClassName.method, which should be replaced with super().method. This is an issue in many modules; I've been asked to create a report for each module that the PR touches.

----------
components: Library (Lib)
messages: 314517
nosy: madsjensen
priority: normal
severity: normal
status: open
title: Use super().method instead in Logging

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33155>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:23:37 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Mar 2018 11:23:37 +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: <1522149817.28.0.467229070634.issue31853@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Why *should*?

Legacy ParentClass.method() call is faster than super().method() call, because there are no temporary proxy object.

I don't think there are enough reason to replace all legacy parent calls.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:24:10 2018
From: report at bugs.python.org (Mads Jensen)
Date: Tue, 27 Mar 2018 11:24:10 +0000
Subject: [issue33156] Use super().method instead in email classes.
Message-ID: <1522149849.99.0.467229070634.issue33156@psf.upfronthosting.co.za>


New submission from Mads Jensen <mje at inducks.org>:

There are lots of legacy calls in the form of ClassName.method, which should be replaced with super().method.

----------
components: email
messages: 314519
nosy: barry, madsjensen, r.david.murray
priority: normal
pull_requests: 5997
severity: normal
status: open
title: Use super().method instead in email classes.
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33156>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:30:25 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 27 Mar 2018 11:30:25 +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: <1522150225.58.0.467229070634.issue31853@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

The only time this should matter semantically is if someone is trying to subclass SSLSocket and use multiple inheritance. This is something that people *really* shouldn't do.

It also potentially makes it harder to backport ssl changes to 2.7.

I'm not really seeing the advantages here...

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:36:40 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 27 Mar 2018 11:36:40 +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: <1522150600.56.0.467229070634.issue31853@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I agree

Also this ticket was closed a couple of months ago and is about the SSL module. Your PR is about a different module. Although I think that recycling is generally a good idea, it doesn't apply to ticket numbers.

----------
components: +SSL -email

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:38:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 11:38:24 +0000
Subject: [issue33155] Use super().method instead in Logging
In-Reply-To: <1522149768.39.0.467229070634.issue33155@psf.upfronthosting.co.za>
Message-ID: <1522150704.52.0.467229070634.issue33155@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +vinay.sajip
type:  -> enhancement
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33155>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:39:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 11:39:03 +0000
Subject: [issue33156] Use super().method instead in email classes.
In-Reply-To: <1522149849.99.0.467229070634.issue33156@psf.upfronthosting.co.za>
Message-ID: <1522150743.12.0.467229070634.issue33156@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33156>
_______________________________________

From report at bugs.python.org  Tue Mar 27 07:48:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 11:48:25 +0000
Subject: [issue33153] interpreter crash when multiplying large tuples
In-Reply-To: <1522145451.62.0.467229070634.issue33153@psf.upfronthosting.co.za>
Message-ID: <1522151305.09.0.467229070634.issue33153@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

tuplerepeat() in Objects/tupleobject.c uses a questionable check that relies on signed integer overflow. It is a matter of time when this rifle will shoot in the foot. But I didn't expected issues with old good gcc 6.3. Was the interpreter compiled with non-standard options or ran on non-x86 platform?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33153>
_______________________________________

From report at bugs.python.org  Tue Mar 27 08:03:34 2018
From: report at bugs.python.org (David CARLIER)
Date: Tue, 27 Mar 2018 12:03:34 +0000
Subject: [issue32569] Blake2 module, memory clearance update
In-Reply-To: <1516101232.18.0.467229070634.issue32569@psf.upfronthosting.co.za>
Message-ID: <1522152214.23.0.467229070634.issue32569@psf.upfronthosting.co.za>


David CARLIER <devnexen at gmail.com> added the comment:

Little update it has been accepted and merged today :

https://github.com/BLAKE2/libb2/commit/620681a3b15c4d7239b9323b9da5ea208a959d3d

----------
nosy: +David CARLIER2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Mar 27 09:11:29 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 27 Mar 2018 13:11:29 +0000
Subject: [issue33146] contextlib.suppress should capture exception for
 inspection and filter on substrings
In-Reply-To: <1522082434.07.0.467229070634.issue33146@psf.upfronthosting.co.za>
Message-ID: <1522156289.15.0.467229070634.issue33146@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I wouldn't expand the scope of contextlib.suppress, since it has a pretty clear purpose: pretend the exception never happened. (This was even clearer with the original "ignored" name, before I was talked into changing it to use the current more technically correct, but far less intuitive, name - a decision I still regret).

However, when writing tests, or otherwise introspecting thrown exceptions (i.e. in programs about programs), it's not uncommon for me to want a construct like:

    with catch(FileNotFoundError) as err:
        os.remove(somefile)

    if err.caught is not None:
        ...

The benefit over the try/catch form is similar to the benefits of suppress:

1. Up front declaration that that kind of exception isn't going to escape and execution will continue after the suite
2. More efficient use of vertical whitespace (one extra line instead of three)

In this case, we could also end up expanding the API to provide a better building block for testing tools like "assertRaises" and "assertRaisesRegex" by accepting a "filter" callback argument that receives the caught exception, and can either return False to suppress it, True to reraise it, or explicitly raise a different exception to replace it. (That suggested callback API is deliberately similar to an __exit__ implementation that only accepts the exception value, rather than the full type/value/traceback triple).

(The simpler name may mean that folks end up preferring catch() to suppress() even when they don't need the result of __enter__. I'd be OK with that outcome).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33146>
_______________________________________

From report at bugs.python.org  Tue Mar 27 09:41:30 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Mar 2018 13:41:30 +0000
Subject: [issue33014] Clarify str.isidentifier docstring;
 fix keyword.iskeyword docstring
In-Reply-To: <1520351440.06.0.467229070634.issue33014@psf.upfronthosting.co.za>
Message-ID: <1522158090.07.0.467229070634.issue33014@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think my wording would be an improvement to the docs as well.  You could link just the keyword function if you are worried about too many links, since that would keep the link count the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33014>
_______________________________________

From report at bugs.python.org  Tue Mar 27 09:47:28 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Mar 2018 13:47:28 +0000
Subject: [issue33156] Use super().method instead in email classes.
In-Reply-To: <1522149849.99.0.467229070634.issue33156@psf.upfronthosting.co.za>
Message-ID: <1522158448.68.0.467229070634.issue33156@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thank you for wanting to improve Python, but unless this is actually causing a problem for someone, there is a greater chance of introducing a bug by making such changes than the benefit of the "cleanup".  So we generally don't accept such patches.  If we modify the code for other reasons (ie: we might already be introducing new bugs), then we make such changes.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33156>
_______________________________________

From report at bugs.python.org  Tue Mar 27 10:18:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 14:18:48 +0000
Subject: [issue32861] urllib.robotparser: incomplete __str__ methods
In-Reply-To: <1518828766.79.0.467229070634.issue32861@psf.upfronthosting.co.za>
Message-ID: <1522160328.35.0.467229070634.issue32861@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The default entry was moved out of entries added in issue523041, but RobotFileParser.__str__ was not updated. Support for "Crawl-delay" and "Request-Rate" was added in issue16099, but Entry.__str__ was not updated. This looks like bugs to me, and I think the fix should be backported.

But two unnecessary trailing newlines should be kept for compatibility in maintained versions. I think we can get rid of them in 3.8 (unless Senthil has other opinion).

----------
nosy: +serhiy.storchaka
versions: +Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32861>
_______________________________________

From report at bugs.python.org  Tue Mar 27 10:41:15 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Mar 2018 14:41:15 +0000
Subject: [issue33149] Parser stack overflows
In-Reply-To: <1522108643.61.0.467229070634.issue33149@psf.upfronthosting.co.za>
Message-ID: <1522161675.89.0.467229070634.issue33149@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33149>
_______________________________________

From report at bugs.python.org  Tue Mar 27 10:53:47 2018
From: report at bugs.python.org (Ethan Welty)
Date: Tue, 27 Mar 2018 14:53:47 +0000
Subject: [issue33111] Merely importing tkinter breaks parallel code
 (multiprocessing, sharedmem)
In-Reply-To: <1521573656.32.0.467229070634.issue33111@psf.upfronthosting.co.za>
Message-ID: <1522162427.17.0.467229070634.issue33111@psf.upfronthosting.co.za>


Ethan Welty <ethan.welty at gmail.com> added the comment:

@ronaldoussoren: The order of the imports made no difference. Even with the call at the top, I got endless errors with both 'spawn' and 'forkserver', with or without importing a graphics backend. Only 'fork' works, and only if a graphics package is not imported.

** HOWEVER **

Setting method='spawn' or 'forkserver' and force=True at top, or calling multiprocessing.set_start_method in __main__ does work (when run as scripts from command line). It's a shame to have to give up the convenience of 'fork', but this is a start.

```
import multiprocessing
multiprocessing.set_start_method("spawn", force=True)
import numpy as np
# import _tkinter

def parallel_matmul(x):
    R = np.random.randn(3, 3)
    return np.matmul(R, x)

if __name__ == '__main__':
    # multiprocessing.set_start_method("spawn", force=False)
    pool = multiprocessing.Pool(4)
    results = pool.map(parallel_matmul, [np.random.randn(3, 5000) for i in range(2)])
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33111>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:02:40 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 15:02:40 +0000
Subject: [issue33152] Use list comprehension in timeit module instead of loop
 with append
In-Reply-To: <1522137941.19.0.467229070634.issue33152@psf.upfronthosting.co.za>
Message-ID: <1522162960.28.0.467229070634.issue33152@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
title: clean code -> Use list comprehension in timeit module instead of loop with append

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33152>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:10:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 15:10:39 +0000
Subject: [issue33152] Use list comprehension in timeit module instead of loop
 with append
In-Reply-To: <1522137941.19.0.467229070634.issue33152@psf.upfronthosting.co.za>
Message-ID: <1522163439.3.0.467229070634.issue33152@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

We usually do not do such kind of changes due to the risk of introducing new bugs (as your PR demonstrated). Only when other changes are applied to the module, the surrounded code can be cleaned up. Or the maintainer of the module can do this if he decided that it is a time for modernization.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33152>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:15:51 2018
From: report at bugs.python.org (yemiteliyadu)
Date: Tue, 27 Mar 2018 15:15:51 +0000
Subject: [issue33157] Strings beginning with underscore not removed from lists
 - feature or bug?
Message-ID: <1522163751.07.0.467229070634.issue33157@psf.upfronthosting.co.za>


New submission from yemiteliyadu <rmethent-openid at yahoo.com>:

Strings beginning with underscore not removed from lists
Reproducible as shown below:

Python 3.6.4 |Anaconda custom (64-bit)| (default, Jan 16 2018, 12:04:33) 
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> test = ["a","_a","b","_b"]
>>> for i in test: print(i)
... 
a
_a
b
_b
>>> for i in test: test.remove(i)
... 
>>> test
['_a', '_b']
>>> 

Is this a feature or a bug?
A search through the docs did not show any mention of this.

----------
messages: 314530
nosy: yemiteliyadu
priority: normal
severity: normal
status: open
title: Strings beginning with underscore not removed from lists - feature or bug?
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33157>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:24:21 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Mar 2018 15:24:21 +0000
Subject: [issue33157] Strings beginning with underscore not removed from lists
 - feature or bug?
In-Reply-To: <1522163751.07.0.467229070634.issue33157@psf.upfronthosting.co.za>
Message-ID: <1522164261.92.0.467229070634.issue33157@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

It's just the right behavior. You are modifying the list while iterating over it. It has no business of underscore.

>>> test = ['_a', 'a', '_b', 'b']
>>> for i in test: test.remove(i)
>>> test
['a', 'b']

----------
nosy: +xiang.zhang
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33157>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:29:00 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Mar 2018 15:29:00 +0000
Subject: [issue33157] Strings beginning with underscore not removed from lists
 - feature or bug?
In-Reply-To: <1522163751.07.0.467229070634.issue33157@psf.upfronthosting.co.za>
Message-ID: <1522164540.59.0.467229070634.issue33157@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

You may refer to stackoverflow for an explanation, for example, https://stackoverflow.com/questions/6260089/strange-result-when-removing-item-from-a-list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33157>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:33:44 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 27 Mar 2018 15:33:44 +0000
Subject: [issue33157] Strings beginning with underscore not removed from lists
 - feature or bug?
In-Reply-To: <1522163751.07.0.467229070634.issue33157@psf.upfronthosting.co.za>
Message-ID: <1522164824.54.0.467229070634.issue33157@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

In addition to Xiang Zhang's comments, this is neither a feature nor a bug, but a misunderstanding. This has nothing to do with strings or underscores:

py> L = [1, 2, 3, 4, 5]
py> for item in L:
...     L.remove(item)
...
py> L
[2, 4]


When you modify a list as you iterate over it, the results can be unexpected. Don't do it.

If you *must* modify a list that you are iterating over, you must do so backwards, so that you are only removing items from the end, not the beginning of the list:

py> L = [1, 2, 3, 4, 5]
py> for i in range(len(L)-1, -1, -1):
...     L.remove(L[i])
...
py> L
[]


But don't do that: it is nearly always must faster to make a copy of the list containing only the items you wish to keep, then assign back to the list using slicing. A list comprehension makes this an easy one-liner:

py> L = [1, 2, 3, 4, 5]
py> L[:] = [x for x in L if x > 4]
py> L
[5]

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33157>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:34:59 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 27 Mar 2018 15:34:59 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522134277.84.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <e22fe8f2-ae7b-315f-cd43-d452f3c21e1b@biologie.uni-freiburg.de>


Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> added the comment:

Serhiy:

> I like the idea in general, but have comments about the implementation.
> 
> __init_subclass__ should take **kwargs and pass it to super().__init_subclass__(). type(cls.random) is not the same as type(self.random). I would use the condition `cls.random is _random.Random.random` instead, or check if the method is in cls.__dict__.
> 
> This will break the case when random or getrandbits methods are patched after class creation or per instance, but I think we have no need to support this.
> 

My bad, sorry, and thanks for catching all these issues!

You're absolutely right about the class type checks not being equivalent 
to the original ones at the instance level.
Actually, this is due to the fact that I first moved the checks out of 
_randbelow and into __init__ just as Raymond would have done and tested 
this, but then I realized that __init_subclass__ looked just like the 
right place and moved them again - this time without testing on derived 
classes again.
 From a quick experiment it looks like types.MethodDescriptorType would 
be the correct type to check cls.random against and types.FunctionType 
would need to be checked against cls.getrandbits, but that starts to 
look rather esoteric to me - so you are probably right that something 
with a cls.__dict__ check or the alternative suggestion of `cls.random 
is _random.Random.random` are better solutions, indeed.

> We could support also the following cases:
> 
> 1.
>      class Rand1(Random):
>          def random(self): ...
>          # _randbelow should use random()
> 
>      class Rand2(Rand1):
>          def getrandbits(self): ...
>          # _randbelow should use getrandbits()
>          # this is broken in the current patch
> 

Right, hadn't thought of this situation.

> 2.
>      class Rand1(Random):
>          def getrandbits(self): ...
>          # _randbelow should use getrandbits()
> 
>      class Rand2(Rand1):
>          def random(self): ...
>          # _randbelow should use random()
>          # this is broken in the current code
> 

May be worth fixing, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:39:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 15:39:31 +0000
Subject: [issue31550] Inconsistent error message for TypeError with
 subscripting
In-Reply-To: <1506051158.28.0.318471298874.issue31550@psf.upfronthosting.co.za>
Message-ID: <1522165171.12.0.467229070634.issue31550@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marked as closed for the reasons listed.

Thank you for the suggestion, but we're going to decline.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31550>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:41:21 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 15:41:21 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522165281.73.0.467229070634.issue33144@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Wolfgang, can you submit this as a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Tue Mar 27 11:46:52 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 27 Mar 2018 15:46:52 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522165612.52.0.467229070634.issue33144@psf.upfronthosting.co.za>


Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> added the comment:

Thanks, Raymond. I'll do that once I've addressed Serhiy's points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Tue Mar 27 12:17:09 2018
From: report at bugs.python.org (Samwyse)
Date: Tue, 27 Mar 2018 16:17:09 +0000
Subject: [issue33158] Add fileobj property to csv reader and writer objects
Message-ID: <1522167429.73.0.467229070634.issue33158@psf.upfronthosting.co.za>


New submission from Samwyse <samwyse at gmail.com>:

Many objects have properties that allow access to the arguments used to create them.  In particular, file objects have a name property that returns the name used when opening a file.  A fileobj property would be convenient, as you otherwise, for example, need to pass an extra argument to routines that need both the csv object and the underlying file object.  Adopting this enhancement would also provide consistency with the dialect constructer argument, which is available as an object property.

Changing the fileobj while the csv object is in use would open a can of worms, so this should be a read-only property.

Optionally, the fileobj property could be reflected in the DictReader and DictWriter classes, but the value would be accessible via the .reader and .writer properties of those classes.

----------
components: Library (Lib)
messages: 314538
nosy: samwyse
priority: normal
severity: normal
status: open
title: Add fileobj property to csv reader and writer objects
type: enhancement
versions: Python 2.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33158>
_______________________________________

From report at bugs.python.org  Tue Mar 27 12:53:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 16:53:40 +0000
Subject: [issue32742] zipfile extractall needlessly re-wraps ZipInfo instances
In-Reply-To: <1517497853.08.0.467229070634.issue32742@psf.upfronthosting.co.za>
Message-ID: <1522169620.75.0.467229070634.issue32742@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is an obscure behavior change introduced by this PR. Technically a ZIP file can contain several entries with the same name. Currently extractall() will extract the last of them multiple times.  The result doesn't differ from when extract it only once, there is just a waste of time. After merging this PR extractall() will extract different entries to the same location. If one of the is a directory, and other is a file, extractall() will fail.

I'm not sure it can be considered a valid ZIP file, but currently the zipfile module supports it.

On other hand, what is the benefit of using `self.infolist()` instead of `self.namelist()`?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32742>
_______________________________________

From report at bugs.python.org  Tue Mar 27 12:59:43 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Mar 2018 16:59:43 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
In-Reply-To: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>
Message-ID: <1522169983.42.0.467229070634.issue33151@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 30e507dff465a31901d87df791a2bac40dc88530 by Barry Warsaw in branch 'master':
bpo-33151: Handle submodule resources (GH-6268)
https://github.com/python/cpython/commit/30e507dff465a31901d87df791a2bac40dc88530


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 13:00:05 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 27 Mar 2018 17:00:05 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
In-Reply-To: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>
Message-ID: <1522170005.04.0.467229070634.issue33151@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +5998

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 13:15:12 2018
From: report at bugs.python.org (Mads Jensen)
Date: Tue, 27 Mar 2018 17:15:12 +0000
Subject: [issue33155] Use super().method instead in Logging
In-Reply-To: <1522149768.39.0.467229070634.issue33155@psf.upfronthosting.co.za>
Message-ID: <1522170912.79.0.467229070634.issue33155@psf.upfronthosting.co.za>


Change by Mads Jensen <mje at inducks.org>:


----------
keywords: +patch
pull_requests: +5999
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33155>
_______________________________________

From report at bugs.python.org  Tue Mar 27 13:17:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 17:17:55 +0000
Subject: [issue33158] Add fileobj property to csv reader and writer objects
In-Reply-To: <1522167429.73.0.467229070634.issue33158@psf.upfronthosting.co.za>
Message-ID: <1522171075.57.0.467229070634.issue33158@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> A fileobj property would be convenient, as you otherwise, for example, need to pass an extra argument to routines that need both the csv object and the underlying file object.

But you should already have this object for creating csv.reader() or csv.writer().

Even if keep the argument of the constructor as an instance attribute, there is a problem with naming this attribute. csv.reader works not only with files. It accepts arbitrary iterable.

>>> it = iter(['Spam, Spam, Spam, Spam, Spam, Baked Beans', 'Spam, Lovely Spam, Wonderful Spam'])
>>> list(csv.reader(it))
[['Spam', ' Spam', ' Spam', ' Spam', ' Spam', ' Baked Beans'], ['Spam', ' Lovely Spam', ' Wonderful Spam']]

The dialect property is not a copy of the dialect constructer argument.

----------
nosy: +serhiy.storchaka
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33158>
_______________________________________

From report at bugs.python.org  Tue Mar 27 13:25:34 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Mar 2018 17:25:34 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
In-Reply-To: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>
Message-ID: <1522171534.25.0.467229070634.issue33151@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset fd1b8f87b3e63495cadd37c8f1b90191b46ee52a by Barry Warsaw (Miss Islington (bot)) in branch '3.7':
bpo-33151: Handle submodule resources (GH-6268) (GH-6270)
https://github.com/python/cpython/commit/fd1b8f87b3e63495cadd37c8f1b90191b46ee52a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 13:25:51 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 27 Mar 2018 17:25:51 +0000
Subject: [issue33151] importlib.resources breaks on subdirectories
In-Reply-To: <1522126064.63.0.467229070634.issue33151@psf.upfronthosting.co.za>
Message-ID: <1522171551.29.0.467229070634.issue33151@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33151>
_______________________________________

From report at bugs.python.org  Tue Mar 27 14:28:30 2018
From: report at bugs.python.org (triccare triccare)
Date: Tue, 27 Mar 2018 18:28:30 +0000
Subject: [issue13829] exception error in _scproxy.so when called after fork
In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>
Message-ID: <1522175310.28.0.467229070634.issue13829@psf.upfronthosting.co.za>


triccare triccare <triccare at gmail.com> added the comment:

I have run into this bug which can be reliably reproduced by importing tkinter.

However, I have found another workaround if one does not want to deal with the environmental variable and may point to a possible bug fix. Before forking, any use of `urlopen` alleviates the bug. This is demonstrated in the attached example.

Example works under Python 3.6.4 and Mac OS 10.12.6

----------
nosy: +triccare triccare
Added file: https://bugs.python.org/file47503/debug_urlopen.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13829>
_______________________________________

From report at bugs.python.org  Tue Mar 27 14:30:07 2018
From: report at bugs.python.org (Mike Edmunds)
Date: Tue, 27 Mar 2018 18:30:07 +0000
Subject: [issue25257] In subject line email library inserts unwanted space
 after a thousands comma in a number
In-Reply-To: <1443464392.64.0.380133301442.issue25257@psf.upfronthosting.co.za>
Message-ID: <1522175407.81.0.467229070634.issue25257@psf.upfronthosting.co.za>


Mike Edmunds <medmunds at gmail.com> added the comment:

Here's a workaround for Python 2.7:

```
class HeaderBugWorkaround(email.header.Header):
    def encode(self, splitchars=' ', **kwargs):  # only split on spaces, rather than splitchars=';, '
        return email.header.Header.encode(self, splitchars, **kwargs)

# and then...

msg['Subject'] = HeaderBugWorkaround(subject, 'utf-8', header_name='Subject')

```

(If you have the option, you're almost certainly better off moving to Python 3 for anything email related. But if you're maintaining code that has to be Python 2.7 compatible, this might help.)

----------
nosy: +medmunds

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25257>
_______________________________________

From report at bugs.python.org  Tue Mar 27 14:43:40 2018
From: report at bugs.python.org (Bob Hossley)
Date: Tue, 27 Mar 2018 18:43:40 +0000
Subject: [issue25257] In subject line email library inserts unwanted space
 after a thousands comma in a number
In-Reply-To: <1522175407.81.0.467229070634.issue25257@psf.upfronthosting.co.za>
Message-ID: <58318807-1fe1-7cbd-f07d-b3809f197199@ieee.org>


Bob Hossley <bhossley at ieee.org> added the comment:

Mike,

Thank you.

I moved to Python 3 some time ago.  I confirm that Python 3 does not
have the problem.  But I can't conveniently verify your workaround for
Python 2.

Regards,
Bob
bhossley at ieee.org

On 2018-03-27 11:30 AM, Mike Edmunds wrote:
> 
> Mike Edmunds <medmunds at gmail.com> added the comment:
> 
> Here's a workaround for Python 2.7:
> 
> ```
> class HeaderBugWorkaround(email.header.Header):
>     def encode(self, splitchars=' ', **kwargs):  # only split on spaces, rather than splitchars=';, '
>         return email.header.Header.encode(self, splitchars, **kwargs)
> 
> # and then...
> 
> msg['Subject'] = HeaderBugWorkaround(subject, 'utf-8', header_name='Subject')
> 
> ```
> 
> (If you have the option, you're almost certainly better off moving to Python 3 for anything email related. But if you're maintaining code that has to be Python 2.7 compatible, this might help.)
> 
> ----------
> nosy: +medmunds
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue25257>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25257>
_______________________________________

From report at bugs.python.org  Tue Mar 27 15:29:07 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Mar 2018 19:29:07 +0000
Subject: [issue33155] Use super().method instead in Logging
In-Reply-To: <1522149768.39.0.467229070634.issue33155@psf.upfronthosting.co.za>
Message-ID: <1522178947.62.0.467229070634.issue33155@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33155>
_______________________________________

From report at bugs.python.org  Tue Mar 27 15:32:44 2018
From: report at bugs.python.org (skreft)
Date: Tue, 27 Mar 2018 19:32:44 +0000
Subject: [issue33159] Implement PEP 473
Message-ID: <1522179164.75.0.467229070634.issue33159@psf.upfronthosting.co.za>


New submission from skreft <skreft at gmail.com>:

Implement PEP 473.

----------
messages: 314546
nosy: skreft
priority: normal
severity: normal
status: open
title: Implement PEP 473
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33159>
_______________________________________

From report at bugs.python.org  Tue Mar 27 15:35:14 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Mar 2018 19:35:14 +0000
Subject: [issue33159] Implement PEP 473
In-Reply-To: <1522179164.75.0.467229070634.issue33159@psf.upfronthosting.co.za>
Message-ID: <1522179314.02.0.467229070634.issue33159@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +6000
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33159>
_______________________________________

From report at bugs.python.org  Tue Mar 27 16:30:14 2018
From: report at bugs.python.org (Matthias Urlichs)
Date: Tue, 27 Mar 2018 20:30:14 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522182614.57.0.467229070634.issue32850@psf.upfronthosting.co.za>


Matthias Urlichs <smurf at smurf.noris.de> added the comment:

Apparently this patch has not been applied yet. Is there a reason for that, besides "it's obviously correct so there must be something wrong with it"? ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 16:38:51 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 27 Mar 2018 20:38:51 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522183131.54.0.467229070634.issue32850@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

We generally prefer pull requests on github over patches on the bug tracker. Please follow the guidelines for contributing to CPython, https://devguide.python.org/pullrequest/

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:07:48 2018
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 27 Mar 2018 21:07:48 +0000
Subject: [issue33160] Negative values in positional access inside formatting
Message-ID: <1522184868.7.0.467229070634.issue33160@psf.upfronthosting.co.za>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

This works fine:

>>> "{[0]}".format([1, 2, 3])
'1'

This should work too:

>>> "{[-1]}".format([1, 2, 3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers or slices, not str

----------
messages: 314549
nosy: facundobatista
priority: normal
severity: normal
status: open
title: Negative values in positional access inside formatting
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33160>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:13:54 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Mar 2018 21:13:54 +0000
Subject: [issue33160] Negative values in positional access inside formatting
In-Reply-To: <1522184868.7.0.467229070634.issue33160@psf.upfronthosting.co.za>
Message-ID: <1522185234.64.0.467229070634.issue33160@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +eric.smith
type:  -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33160>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:16:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Mar 2018 21:16: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: <1522185417.45.0.467229070634.issue32517@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 8534d53333e4e918be82b041754ecd89af519e5b by Ned Deily in branch 'master':
bpo-32517: fix test_read_pty_output() hangs on macOS 10.13.2+ (GH-6037) (GH-6113)
https://github.com/python/cpython/commit/8534d53333e4e918be82b041754ecd89af519e5b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:17:32 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Mar 2018 21:17:32 +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: <1522185452.05.0.467229070634.issue32517@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 6a2539c43412567a4c693da8e7fdf5e73191fd16 by Ned Deily in branch '3.7':
bpo-32517: re-enable test_read_pty_output on macOS (GH-6112)
https://github.com/python/cpython/commit/6a2539c43412567a4c693da8e7fdf5e73191fd16


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:19:53 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Mar 2018 21:19:53 +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: <1522185593.43.0.467229070634.issue32517@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:43:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Mar 2018 21:43:24 +0000
Subject: [issue33160] Negative values in positional access inside formatting
In-Reply-To: <1522184868.7.0.467229070634.issue33160@psf.upfronthosting.co.za>
Message-ID: <1522187004.3.0.467229070634.issue33160@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Should str.format allow negative indexes when used for __getitem__ access?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33160>
_______________________________________

From report at bugs.python.org  Tue Mar 27 17:56:38 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 27 Mar 2018 21:56:38 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522187798.6.0.467229070634.issue32850@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Yes, a PR would be better... also, the two versions of the patch appear to be identical?

CC'ing Antoine and Victor b/c they seem to have written this dangling_threads checking stuff and I'm not sure I understand it :-).

As some extra background: this is in Python's internal testing code, but @smurfix is hitting it because he's working on a third-party asyncio event loop implementation, and re-using test.asyncio to test it. I'm not sure what specifically is causing this to happen, though I guess it has something to do with how trio / trio-asyncio are using threads.

[1] https://github.com/python-trio/trio-asyncio

----------
nosy: +pitrou, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:01:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Mar 2018 22:01:11 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522188071.82.0.467229070634.issue32850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Lib/test/support/__init__.py::threading_cleanup() complains about dangling threads even if the reference in question would be cleaned up by the garbage collector.

It's a deliberate choice. It helped me to find real bugs. For example, I found a very old reference cycle in socket.create_connection().

The error message ("dangling threads") doesn't help, but it means that "something is wrong" in your test.

Sadly, sometimes you have to explicitly do something like "self.thread = None" in your test.

I wrote an article to explain these things:
https://vstinner.github.io/contrib-cpython-2017q3-part2.html

Instead of calling support.gc_collect(), I suggest to write documentation, maybe as a comment in support.threading_cleanup()?, explaining the warning and how to fix it. Maybe with a link to this issue? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:04:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Mar 2018 22:04:17 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522188257.77.0.467229070634.issue32850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> This is not useful, esp. when the list of referrers to the "dangling" thread looks like this: (...)

I wrote the test.bisect tool to help to debug dangling threads issues.

Sadly, sometimes the warning can occur randomly because of race conditions, and it can be painful to reproduce the bug, and to fix the root issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:21:27 2018
From: report at bugs.python.org (Matthias Urlichs)
Date: Tue, 27 Mar 2018 22:21:27 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522189287.84.0.467229070634.issue32850@psf.upfronthosting.co.za>


Matthias Urlichs <smurf at smurf.noris.de> added the comment:

> It's a deliberate choice. It helped me to find real bugs. For example, I found a very old reference cycle in socket.create_connection().

Fair enough; I will change the patch to complain before gc'ing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:21:59 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 22:21:59 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
In-Reply-To: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>
Message-ID: <1522189319.27.0.467229070634.issue33128@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

It seems that the problem is that `_Py_InitializeEx_Private` calls  `_Py_InitializeCore` and `_Py_InitializeMainInterpreter`. The first one calls at the end `initimport` that in turns calls `importlib._install_external_importers` that sets the PathFinder. Then, `_Py_InitializeMainInterpreter` calls  `initexternalimport` that in turns calls again `importlib._install_external_importers` and therefore we end with two PathFinders in sys.meta_path.

I think the solution is removing the call to initexternalimport in `_Py_InitializeMainInterpreter` as it has been alreade initialized by `_Py_InitializeCore`.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:33:56 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 22:33:56 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
In-Reply-To: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>
Message-ID: <1522190036.18.0.467229070634.issue33128@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The same problem happens in `new_interpreter` as far as I understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:34:22 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 27 Mar 2018 22:34:22 +0000
Subject: [issue32850] Run gc_collect() before complaining about dangling
 threads
In-Reply-To: <1518703352.66.0.467229070634.issue32850@psf.upfronthosting.co.za>
Message-ID: <1522190062.82.0.467229070634.issue32850@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

@Victor: So to make sure I understand, the point of the check is to complain about reference cycles involving thread objects, because when those happen in the stdlib you consider them bugs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32850>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:35:59 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 27 Mar 2018 22:35:59 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
In-Reply-To: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>
Message-ID: <1522190159.5.0.467229070634.issue33128@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +6001
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:37:22 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Tue, 27 Mar 2018 22:37:22 +0000
Subject: [issue33153] interpreter crash when multiplying large tuples
In-Reply-To: <1522145451.62.0.467229070634.issue33153@psf.upfronthosting.co.za>
Message-ID: <1522190242.94.0.467229070634.issue33153@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

The traceback:

[builder at localhost ~]$ python -c 'x = ("a", "b") * 2**20; x *= 2**20'
Segmentation fault (core dumped)
[builder at localhost ~]$ gdb python core.23284 
GNU gdb (GDB) 7.9-alt4 (ALT)
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-alt-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...Reading symbols from /usr/lib/debug/usr/bin/python2.7.debug...done.
done.

warning: core file may not match specified executable file.
[New LWP 23284]
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Core was generated by `python -c x = ("a", "b") * 2**20; x *= 2**20'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  tuplerepeat (a=0xf694301c, n=1048576) at Objects/tupleobject.c:503
503	            *p = items[j];
(gdb) bt
#0  tuplerepeat (a=0xf694301c, n=1048576) at Objects/tupleobject.c:503
#1  0xf7546d47 in sequence_repeat (n=0x80a83ac, seq=0xf694301c, repeatfunc=0xf75b24a0 <tuplerepeat>) at Objects/abstract.c:1210
#2  PyNumber_InPlaceMultiply (v=0xf694301c, w=0x80a83ac) at Objects/abstract.c:1374
#3  0xf7602ff8 in PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:1653
#4  0xf7608fee in PyEval_EvalCodeEx (co=0xf71a8ba8, globals=0xf7240714, locals=0xf7240714, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3589
#5  0xf760916e in PyEval_EvalCode (co=0xf71a8ba8, globals=0xf7240714, locals=0xf7240714) at Python/ceval.c:669
#6  0xf762c508 in run_mod (arena=0x8068320, flags=0xffa1a82c, locals=0xf7240714, globals=0xf7240714, filename=0xf765fec9 "<string>", mod=<optimized out>) at Python/pythonrun.c:1376
#7  PyRun_StringFlags (str=0x804b160 "x = (\"a\", \"b\") * 2**20; x *= 2**20\n", start=257, globals=0xf7240714, locals=0xf7240714, flags=0xffa1a82c) at Python/pythonrun.c:1339
#8  0xf762e160 in PyRun_SimpleStringFlags (command=0x804b160 "x = (\"a\", \"b\") * 2**20; x *= 2**20\n", flags=0xffa1a82c) at Python/pythonrun.c:974
#9  0xf764498e in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:589
#10 0x080484f7 in main (argc=3, argv=0xffa1a974) at Modules/python.c:20
(gdb) quit
[builder at localhost ~]$ 

It was built like this -- http://git.altlinux.org/tasks/archive/done/_188/193020/build/100/i586/log :

i586-alt-linux-gcc -pthread -c -fno-strict-aliasing -pipe -Wall -g -O3 -march=i586 -mtune=generic -DNDEBUG -pipe -Wall -g -O3 -march=i586 -mtune=generic  -I. -IInclude -I./Include  -fPIC -DPy_BUILD_CORE -o Objects/tupleobject.o Objects/tupleobject.c

The same happens with gcc7-7.3.1-alt3 here -- http://git.altlinux.org/tasks/202598/build/100/i586/log .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33153>
_______________________________________

From report at bugs.python.org  Tue Mar 27 18:39:18 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Tue, 27 Mar 2018 22:39:18 +0000
Subject: [issue33153] interpreter crash when multiplying large tuples
In-Reply-To: <1522145451.62.0.467229070634.issue33153@psf.upfronthosting.co.za>
Message-ID: <1522190358.15.0.467229070634.issue33153@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

It was run in i586 chroot on x86_64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33153>
_______________________________________

From report at bugs.python.org  Tue Mar 27 20:30:38 2018
From: report at bugs.python.org (qb-cea)
Date: Wed, 28 Mar 2018 00:30:38 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1522197038.85.0.467229070634.issue24132@psf.upfronthosting.co.za>


qb-cea <quentin.bouget at cea.fr> added the comment:

Hi all,

I made a pull request proposing a fix for this issue. There is still quite a lot to be done:
 - I exposed some variables (and probably methods too) that used to be hidden;
 - I did not update the documentation;
 - I did not add a proper test.

I will try to fix those by the end of the week.

The patch mainly consists of two things:
 - having Path (resp. PurePath) be a variable pointing at either (Pure)PosixPath or (Pure)WindowsPath, depending on the platform (like Kevin Norris suggested);
 - introducing two new abstract classes _PurePath and ConcretePath from which PurePosixPath, PureWindowsPath and PosixPath, WindowsPath classes inherit;
 - removing the _Flavor classes, and redistributing their method to platform-specific classes.

Ideally I would like _PurePath to become a public class, but I could not come up with a proper name. Any feedback is more than welcome =]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Tue Mar 27 20:47:21 2018
From: report at bugs.python.org (Ekin Dursun)
Date: Wed, 28 Mar 2018 00:47:21 +0000
Subject: [issue33161] Refactor of pathlib's _WindowsBehavior.gethomedir
Message-ID: <1522198041.64.0.467229070634.issue33161@psf.upfronthosting.co.za>


New submission from Ekin Dursun <ekindursun at gmail.com>:

At line 245, default value for drv is provided with KeyError handling, but it is better to use dict's get method.

----------
components: Library (Lib), Windows
messages: 314562
nosy: onlined, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Refactor of pathlib's _WindowsBehavior.gethomedir
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33161>
_______________________________________

From report at bugs.python.org  Tue Mar 27 21:08:02 2018
From: report at bugs.python.org (Ekin Dursun)
Date: Wed, 28 Mar 2018 01:08:02 +0000
Subject: [issue33161] Refactor of pathlib's _WindowsBehavior.gethomedir
In-Reply-To: <1522198041.64.0.467229070634.issue33161@psf.upfronthosting.co.za>
Message-ID: <1522199282.57.0.467229070634.issue33161@psf.upfronthosting.co.za>


Change by Ekin Dursun <ekindursun at gmail.com>:


----------
keywords: +patch
pull_requests: +6002
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33161>
_______________________________________

From report at bugs.python.org  Wed Mar 28 01:39:18 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 05:39:18 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522215558.61.0.467229070634.issue32872@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +6003

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 01:56:16 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 05:56:16 +0000
Subject: [issue33142] Fatal Python error: Py_Initialize: Unable to get the
 locale encoding on Debian/Python 3.6.4 source build
In-Reply-To: <1522054349.44.0.467229070634.issue33142@psf.upfronthosting.co.za>
Message-ID: <1522216576.93.0.467229070634.issue33142@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Since python3.6 is regularly built with various Debian releases, this seems unlikely to be a problem in Python itself.  Suggest you verify that no venv or virtualenv is in use or that PYTHON* environment variables are set or that no modifications provided by Debian are the cause.  If you can reproduce with a stock Python 3.6.4 (3.6.5 shortly) tarball from python.org, please feel free to reopen and show the exact steps used to build, i.e. tar, configure, and make commands.

----------
nosy: +ned.deily
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33142>
_______________________________________

From report at bugs.python.org  Wed Mar 28 01:57:15 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 05:57:15 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522216635.71.0.467229070634.issue32872@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset e52ac045972a4f75d7f52e4ee0d6de128259134d by Ned Deily in branch 'master':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276)
https://github.com/python/cpython/commit/e52ac045972a4f75d7f52e4ee0d6de128259134d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 01:57:43 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 05:57:43 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522216663.57.0.467229070634.issue32872@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 01:58:24 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 05:58:24 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522216704.82.0.467229070634.issue32872@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 02:39:21 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 06:39:21 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522219161.54.0.467229070634.issue32872@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset d2d5bd8bc4f58b572702d572dc8491f0a50144e6 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276) (#6277)
https://github.com/python/cpython/commit/d2d5bd8bc4f58b572702d572dc8491f0a50144e6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 02:43:54 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 06:43:54 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522219434.12.0.467229070634.issue32872@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset a93662cf8fb98e41f2b7e7c032b680eee834d290 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276) (GH-6278)
https://github.com/python/cpython/commit/a93662cf8fb98e41f2b7e7c032b680eee834d290


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 02:46:54 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 06:46:54 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522219614.2.0.467229070634.issue32872@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
priority: release blocker -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 03:14:34 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 07:14:34 +0000
Subject: [issue32745] ctypes string pointer fields should accept embedded null
 characters
In-Reply-To: <1517514890.15.0.467229070634.issue32745@psf.upfronthosting.co.za>
Message-ID: <1522221274.61.0.467229070634.issue32745@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The change mentioned was made in GH-2462 for Issue13617 and was released in 3.6.3 (and 3.5.4 now in security-fix-only mode).

----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, ned.deily, serhiy.storchaka
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32745>
_______________________________________

From report at bugs.python.org  Wed Mar 28 03:28:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 07:28:10 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522222090.89.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +6006
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 28 03:44:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 07:44:50 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522223090.5.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset df532ab752680f6e359672c2cd40bec8ac848628 by Ned Deily in branch 'master':
bpo-32726: Do not force IDLE.app to launch in 32-bit mode. (GH-6279)
https://github.com/python/cpython/commit/df532ab752680f6e359672c2cd40bec8ac848628


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 28 03:46:13 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 07:46:13 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522223173.6.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 28 03:47:00 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 07:47:00 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522223220.19.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:02:50 2018
From: report at bugs.python.org (Nikunj jain)
Date: Wed, 28 Mar 2018 08:02:50 +0000
Subject: [issue33162] TimedRotatingFileHandler in logging module
Message-ID: <1522224170.9.0.467229070634.issue33162@psf.upfronthosting.co.za>


New submission from Nikunj jain <nikunjj46 at gmail.com>:

Currently the TimedRotatingFileHandler in Python, when rotates the log file, invents a new file extension by adding the new date in the end of the file name. It would be really good if a prefix option could be provided which instead of adding the new date in end, will add it in the beginning.

----------
messages: 314569
nosy: Nikunj jain
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler in logging module
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33162>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:13:33 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:13:33 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
Message-ID: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at python.org>:

pip and setuptools were updated in the following commits:

PR 6184 d93b5161af12291f3f98a260c90cc2975ea9e9cd for master (3.8.0)
PR 6185 8f46176f0e19d31d8642735e535183a39c5e0bdc for 3.7 (3.7.0rc3)
PR 6186 560ea272b01acaa6c531cc7d94331b2ef0854be6 for 3.6 (3.6.5)
PR 6187 1ce4e5bee6df476836f799456f2caf77cd13dc97 for 2.7 (2.7.15)

Need to add NEWS entries for them (to follow).

----------
components: Build
messages: 314570
nosy: dstufft, ned.deily
priority: normal
severity: normal
status: open
title: Upgrade pip to 9.0.3 and setuptools to v39.0.1
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:16:32 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:16:32 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522224992.26.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 39c0ef5171e1cdcc2ed59685a81b194e9bfe3809 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-32726: Do not force IDLE.app to launch in 32-bit mode. (GH-6280)
https://github.com/python/cpython/commit/39c0ef5171e1cdcc2ed59685a81b194e9bfe3809


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:22:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:22:40 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522225360.56.0.467229070634.issue33163@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +6009
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:40:35 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:40:35 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522226435.52.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset fb3d3b7a65d8c0521a88c87e17a7554c5ec439d9 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-32726: Do not force IDLE.app to launch in 32-bit mode. (GH-6279) (#6281)
https://github.com/python/cpython/commit/fb3d3b7a65d8c0521a88c87e17a7554c5ec439d9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:46:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:46:38 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522226798.17.0.467229070634.issue33163@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset c0518cde7a8404f310cd3495e77e612820ecad4f by Ned Deily in branch 'master':
bpo-33163: Upgrade pip to 9.0.3 and setuptools to v39.0.1. (GH-6282)
https://github.com/python/cpython/commit/c0518cde7a8404f310cd3495e77e612820ecad4f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:47:57 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 08:47:57 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522226877.16.0.467229070634.issue33163@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:48:48 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 08:48:48 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522226928.28.0.467229070634.issue33163@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6011

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:49:27 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:49:27 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522226967.93.0.467229070634.issue33163@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset b9172b9630eeefc6dea1409b5bf4180b27fc359f by Ned Deily (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-33163: Upgrade pip to 9.0.3 and setuptools to v39.0.1. (GH-6283)
https://github.com/python/cpython/commit/b9172b9630eeefc6dea1409b5bf4180b27fc359f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:49:47 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 08:49:47 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522226987.85.0.467229070634.issue33163@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6012

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:52:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:52:09 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522227129.83.0.467229070634.issue33163@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 9dad016784848a53d9f2557292025f7a4104c5a5 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-33163: Upgrade pip to 9.0.3 and setuptools to v39.0.1. (GH-6285)
https://github.com/python/cpython/commit/9dad016784848a53d9f2557292025f7a4104c5a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 04:55:32 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 08:55:32 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522227332.79.0.467229070634.issue33163@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 7f48a426fc69d144d4242517ef40eff01c1fd483 by Ned Deily (Miss Islington (bot)) in branch '2.7':
bpo-33163: Upgrade pip to 9.0.3 and setuptools to v39.0.1. (GH-6284)
https://github.com/python/cpython/commit/7f48a426fc69d144d4242517ef40eff01c1fd483


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 05:00:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 09:00:13 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522227613.39.0.467229070634.issue33163@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 05:01:09 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 09:01:09 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
In-Reply-To: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>
Message-ID: <1522227669.04.0.467229070634.issue33131@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

BTW, when updating the bundled wheels, please remember to use an issue (like this one) and include a NEWS entry using blurb; in other words, don't use the "skip news" label on PRs.  That way the change will be documented in the Misc/NEWS and docs changelog.html for the release(s).  See, for example, Issue33163, which added NEWS entries after the fact.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Wed Mar 28 05:04:44 2018
From: report at bugs.python.org (David Carlier)
Date: Wed, 28 Mar 2018 09:04:44 +0000
Subject: [issue33164] Blake 2 module update
Message-ID: <1522227884.31.0.467229070634.issue33164@psf.upfronthosting.co.za>


Change by David Carlier <dcarlier at afilias.info>:


----------
components: Extension Modules
nosy: David Carlier
priority: normal
pull_requests: 6013
severity: normal
status: open
title: Blake 2 module update
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Wed Mar 28 05:05:21 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Mar 2018 09:05:21 +0000
Subject: [issue33165] Add stacklevel parameter to logging APIs
Message-ID: <1522227921.35.0.467229070634.issue33165@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

warnings.warn() offers a stacklevel parameter to make it easier to write helper functions that generate warnings - by passing "stacklevel=2", you can ensure the warning is attributed to the caller of the helper function, rather than to the helper function itself.

There isn't currently a similarly clear way to write helper functions that emit logging messages - if the format includes "pathname", "filename", "module", "function", or "lineno", then those will always report the location of the helper function, rather than the caller of the helper function.

It would be convenient if logging.debug() et al accepted a "stacklevel" parameter the same way the warnings module does (although this may require some adjustments to the Logger.findCaller method API)

----------
components: Library (Lib)
messages: 314578
nosy: ncoghlan, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: Add stacklevel parameter to logging APIs
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33165>
_______________________________________

From report at bugs.python.org  Wed Mar 28 05:07:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Mar 2018 09:07:54 +0000
Subject: [issue32745] ctypes string pointer fields should accept embedded null
 characters
In-Reply-To: <1517514890.15.0.467229070634.issue32745@psf.upfronthosting.co.za>
Message-ID: <1522228074.38.0.467229070634.issue32745@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a regression. Eryk's solution LGTM. Do you mind to create a PR?

But u"foo\0bar" is not terminated by two NULL characters. If this is used in real code, it contains a bug. And the getter of this field will return the string only to the first null character. More work is needed for making this more reliable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32745>
_______________________________________

From report at bugs.python.org  Wed Mar 28 05:44:42 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 09:44:42 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522230282.76.0.467229070634.issue33166@psf.upfronthosting.co.za>


Change by yanir hainick <yanirh at gmail.com>:


----------
components: Windows
nosy: paul.moore, steve.dower, tim.golden, yanirh, zach.ware
priority: normal
severity: normal
status: open
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 06:01:51 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 10:01:51 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522231311.9.0.467229070634.issue33166@psf.upfronthosting.co.za>


yanir hainick <yanirh at gmail.com> added the comment:

wrong number of cpu's is reported on some specific platforms.

***

first platform:
server with X4 Intel Xeon E5-4620 (8 physical, 16 logical), running 
a 64bit Windows Server 2012 R2 Standard.
results:
os.cpu_count() reports 64 units
psutil.cpu_count(logical=False) reports 32 units
psutil.cpu_count(logical=True) reports 64 units

multiprocessing using concurrent.futures able to fully utilize the server;

***

second platform:
server with X2 Intel Xeon Gold 6138 (20 physical, 40 logical), running a 64bit Windows Server 2016 Standard.
results:
os.cpu_count() reports 128 units
psutil.cpu_count(logical=False) reports 20 units
psutil.cpu_count(logical=True) reports 40 units

multiprocessing using concurrent.futures able to utilize only 1/4 of the server's power;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 06:19:33 2018
From: report at bugs.python.org (Christophe BAL)
Date: Wed, 28 Mar 2018 10:19:33 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1522197038.85.0.467229070634.issue24132@psf.upfronthosting.co.za>
Message-ID: <bdca49c6-527d-f971-6cc4-ec72a348d45b@gmail.com>


Christophe BAL <projetmbc at gmail.com> added the comment:

Hello.

What about AbstractPath instead of _PurePath ?

Le 28/03/2018 ? 02:30, qb-cea a ?crit?:
> qb-cea <quentin.bouget at cea.fr> added the comment:
>
> Hi all,
>
> I made a pull request proposing a fix for this issue. There is still quite a lot to be done:
>   - I exposed some variables (and probably methods too) that used to be hidden;
>   - I did not update the documentation;
>   - I did not add a proper test.
>
> I will try to fix those by the end of the week.
>
> The patch mainly consists of two things:
>   - having Path (resp. PurePath) be a variable pointing at either (Pure)PosixPath or (Pure)WindowsPath, depending on the platform (like Kevin Norris suggested);
>   - introducing two new abstract classes _PurePath and ConcretePath from which PurePosixPath, PureWindowsPath and PosixPath, WindowsPath classes inherit;
>   - removing the _Flavor classes, and redistributing their method to platform-specific classes.
>
> Ideally I would like _PurePath to become a public class, but I could not come up with a proper name. Any feedback is more than welcome =]
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue24132>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Wed Mar 28 07:18:44 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 11:18:44 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522235924.68.0.467229070634.issue33166@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> os.cpu_count() reports 128 units
> psutil.cpu_count(logical=False) reports 20 units
> psutil.cpu_count(logical=True) reports 40 units

You mean os.cpu_count() reports *more* CPUs than exist on the machine? How can that happen?

----------
nosy: +giampaolo.rodola, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 07:48:46 2018
From: report at bugs.python.org (Matt Eaton)
Date: Wed, 28 Mar 2018 11:48:46 +0000
Subject: [issue33167] RFC Documentation Updates to urllib.parse.rst
Message-ID: <1522237726.19.0.467229070634.issue33167@psf.upfronthosting.co.za>


New submission from Matt Eaton <agnosticdev at gmail.com>:

A recent patch that I worked on resulted in an agreement that there could be a use case for a new URL API to be added to urllib.parse.  See: https://bugs.python.org/issue33034

In my research to develop this new API I have been looking at the documentation for urllib.parse -https://docs.python.org/3/library/urllib.parse.html and thought that the descriptions for the RFC documents could use an update to better reflect the meaning of the document.

----------
assignee: docs at python
components: Documentation
messages: 314584
nosy: agnosticdev, docs at python
priority: normal
severity: normal
status: open
title: RFC Documentation Updates to urllib.parse.rst
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/issue33167>
_______________________________________

From report at bugs.python.org  Wed Mar 28 07:53:07 2018
From: report at bugs.python.org (Matt Eaton)
Date: Wed, 28 Mar 2018 11:53:07 +0000
Subject: [issue33167] RFC Documentation Updates to urllib.parse.rst
In-Reply-To: <1522237726.19.0.467229070634.issue33167@psf.upfronthosting.co.za>
Message-ID: <1522237987.99.0.467229070634.issue33167@psf.upfronthosting.co.za>


Change by Matt Eaton <agnosticdev at gmail.com>:


----------
keywords: +patch
pull_requests: +6014
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33167>
_______________________________________

From report at bugs.python.org  Wed Mar 28 07:58:11 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 11:58:11 +0000
Subject: [issue33164] Blake 2 module update
Message-ID: <1522238291.57.0.467229070634.issue33164@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33164>
_______________________________________

From report at bugs.python.org  Wed Mar 28 08:19:32 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 12:19:32 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522239572.25.0.467229070634.issue33166@psf.upfronthosting.co.za>


yanir hainick <yanirh at gmail.com> added the comment:

Yup.
Attaching a screenshot.

----------
Added file: https://bugs.python.org/file47504/Screenshot.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 08:56:42 2018
From: report at bugs.python.org (Jon Janzen)
Date: Wed, 28 Mar 2018 12:56:42 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1522241802.14.0.467229070634.issue26707@psf.upfronthosting.co.za>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

Ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26707>
_______________________________________

From report at bugs.python.org  Wed Mar 28 09:09:05 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Mar 2018 13:09:05 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522242545.14.0.467229070634.issue33166@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The difference between os.cpu_count() and psutil.cpu_count() is because one uses GetMaximumProcessorCount() and the other dwNumberOfProcessors.

This is tracked as a bug in psutil bug tracker but it's not fixed yet:
https://github.com/giampaolo/psutil/issues/771

As for Python this is where it was discussed and changed:
https://bugs.python.org/issue30581
https://github.com/python/cpython/commit/c67bae04780f9d7590f9f91b4ee5f31c5d75b3c3

In summary: psutil is wrong and you should rely on os.cpu_count().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 09:20:40 2018
From: report at bugs.python.org (Joachim Trouverie)
Date: Wed, 28 Mar 2018 13:20:40 +0000
Subject: [issue29612] TarFile.extract() suffers from hard links inside tarball
In-Reply-To: <1487671846.82.0.103027933595.issue29612@psf.upfronthosting.co.za>
Message-ID: <1522243240.86.0.467229070634.issue29612@psf.upfronthosting.co.za>


Joachim Trouverie <joachim.trouverie at linoame.fr> added the comment:

Anyone for a review ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29612>
_______________________________________

From report at bugs.python.org  Wed Mar 28 09:33:33 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 13:33:33 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522244013.81.0.467229070634.issue33166@psf.upfronthosting.co.za>


yanir hainick <yanirh at gmail.com> added the comment:

Maybe i'm missing something, and would appreciate clarification.

Perhaps psutil is wrong, but it gives an answer that has something to do with the actual situation.

On platform 2, i have 2 Intel Xeon Gold 6138, each with 20 physical processors, 40 logicals.

you are saying i need to rely on os.cpu_count(), which outputs '128'. Can you elaborate on this?

Moreover, when attempting to parallelize on the processors, i reach 25% utilization, which suggests Python 'sees' only one processor group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 09:37:21 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Mar 2018 13:37:21 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522244241.7.0.467229070634.issue33166@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Oh! So both os.cpu_count() and psutil.cpu_count() are wrong? How do you determine the actual number of logical/physical CPUs on your machine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:06:57 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 14:06:57 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522246017.42.0.467229070634.issue33166@psf.upfronthosting.co.za>


yanir hainick <yanirh at gmail.com> added the comment:

Yes. Both are wrong, and os.cpu_count() is completely off.
Regarding how to determine the number of physical/logical cores in my machine - well, not sure what you mean by that. I've attached a screenshot of Windows' system information. Also used 'cpu-z'.

It seems like aside from the os.cpu_count() issue, Python itself has some problem - it 'sees' only 1 CPU group. It is evident from the fact the when parallelizing, utilization level is only 25%.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:12:01 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 14:12:01 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522246321.27.0.467229070634.issue33166@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Let's not conflate different issues.  The parallelization issue is distinct from the os.cpu_count() issue (and I'm skeptical Python is at fault there).

----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:21:21 2018
From: report at bugs.python.org (Christoph Reiter)
Date: Wed, 28 Mar 2018 14:21:21 +0000
Subject: [issue33168] distutils build/build_ext and --debug
Message-ID: <1522246881.58.0.467229070634.issue33168@psf.upfronthosting.co.za>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

The distutils "build" and "build_ext" commands provide a "--debug" option to enable building with debug information. But this option doesn't have any affect because the default CFLAGS contain "-g" (python3-config --cflags) so debug information is always included and "-g0" isn't passed if debug is False.

Is this intentional?

----------
components: Distutils
messages: 314593
nosy: dstufft, eric.araujo, lazka
priority: normal
severity: normal
status: open
title: distutils build/build_ext and --debug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33168>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:27:04 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Mar 2018 14:27:04 +0000
Subject: [issue30891] importlib: _find_and_load() race condition on
 sys.modules[name] check
In-Reply-To: <1499679864.46.0.419806460775.issue30891@psf.upfronthosting.co.za>
Message-ID: <1522247224.0.0.467229070634.issue30891@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yeah, what's wrong with zipimport?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30891>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:30:18 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Mar 2018 14:30:18 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
Message-ID: <1522247418.61.0.467229070634.issue33169@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

See https://github.com/python/mypy/pull/4811. To summarize, importlib.invalidate_caches() doesn't clear the negative cache in sys.path_importer_cache.

Could be related to https://bugs.python.org/issue30891?

----------
messages: 314595
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: importlib.invalidate_caches() doesn't clear all caches
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:33:36 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 14:33:36 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522247616.78.0.467229070634.issue33166@psf.upfronthosting.co.za>


yanir hainick <yanirh at gmail.com> added the comment:

Ok, no problem.
Just to be sure i'm doing the right thing - this thread will be dedicated to the os.cpu_count() issue, and i'll open a new issue on the parallelization problem.

makes sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:34:11 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 14:34:11 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522247651.8.0.467229070634.issue33166@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just to be sure i'm doing the right thing - this thread will be dedicated to the os.cpu_count() issue, and i'll open a new issue on the parallelization problem.

Exactly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:49:06 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 28 Mar 2018 14:49:06 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522248546.12.0.467229070634.issue33144@psf.upfronthosting.co.za>


Change by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
pull_requests: +6015
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:51:28 2018
From: report at bugs.python.org (Maxim Avanov)
Date: Wed, 28 Mar 2018 14:51:28 +0000
Subject: [issue33170] New type based on int() created with typing.NewType is
 not consistent
Message-ID: <1522248688.28.0.467229070634.issue33170@psf.upfronthosting.co.za>


New submission from Maxim Avanov <maxim.avanov at gmail.com>:

>From my understanding of the docs section on new types, https://docs.python.org/3/library/typing.html#newtype the new type based on 
 int() should just pass the value into the base constructor. However,

```
PercentDiscount = NewType('PercentDiscount', int)

>>> PercentDiscount(50) == int(50)
True

>>> int('50') == int(50)
True

>>> PercentDiscount('50') == PercentDiscount(50)
False
```

----------
components: Library (Lib)
messages: 314598
nosy: avanov
priority: normal
severity: normal
status: open
title: New type based on int() created with typing.NewType is not consistent
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33170>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:53:13 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Mar 2018 14:53:13 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522248792.99.0.467229070634.issue33166@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

By re-reading
https://bugs.python.org/issue30581 and
https://github.com/giampaolo/psutil/issues/771#issuecomment-264457333 I now remember why I haven't fixed this issue in psutil yet: because the whole thing (MS APIs and doc basically) is confusing.

GetMaximumProcessorCount (now used by os.cpu_count()) returns "the maximum number of logical processors that a processor group or the system CAN have", not the actual number. That would explain why in OP's case os.cpu_count() returns 128 instead of 40.

As per https://bugs.python.org/issue30581#msg295255 dwNumberOfProcessors wasn't good because it doesn't take multiple processor groups into account (hence the number may be too small) and GetLogicalProcessorInformationEx may be the way to go. This is based on the assumption that os.cpu_count() should report the number of CPUs in the system (including the non-usable ones, like in case of process groups).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:56:29 2018
From: report at bugs.python.org (yanir hainick)
Date: Wed, 28 Mar 2018 14:56:29 +0000
Subject: [issue33171] multiprocessing won't utilize all of platform resources
Message-ID: <1522248989.15.0.467229070634.issue33171@psf.upfronthosting.co.za>


New submission from yanir hainick <yanirh at gmail.com>:

I'm using either multiprocessing package or concurrent.futures for some embarrassingly parallel application.

I performed a simple test: basically making n_jobs calls for a simple function - 'sum(list(range(n)))', with n large enough so that the operation is a few seconds long - where n_jobs > n_logical_cores.

Tried it on two platforms:

first platform:
server with X4 Intel Xeon E5-4620 (8 physical, 16 logical), running 
a 64bit Windows Server 2012 R2 Standard.

***

second platform:
server with X2 Intel Xeon Gold 6138 (20 physical, 40 logical), running a 64bit Windows Server 2016 Standard.

***

first platform reaches 100% utilization.
second platform reaches 25% utilization.

----------
components: Windows
messages: 314600
nosy: paul.moore, steve.dower, tim.golden, yanirh, zach.ware
priority: normal
severity: normal
status: open
title: multiprocessing won't utilize all of platform resources
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33171>
_______________________________________

From report at bugs.python.org  Wed Mar 28 10:57:43 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 28 Mar 2018 14:57:43 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522249063.63.0.467229070634.issue33144@psf.upfronthosting.co.za>


Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> added the comment:

So, the PR implements the behaviour suggested by Serhiy as his cases 1 and 2.
Case 2 changes *existing* behaviour because before it was sufficient to have a user-defined getrandbits anywhere in the inheritance tree, while with the PR it has to be more recent (or be defined within the same class) as the random method.
I'm not 100% sold on this particular aspect so if you think the old behaviour is better, then that's fine with me. In most real situations it would not make a difference anyway (or do people build complex inheritance hierarchies on top of random.Random?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:01:18 2018
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 28 Mar 2018 15:01:18 +0000
Subject: [issue33144] random._randbelow optimization
In-Reply-To: <1522076428.25.0.467229070634.issue33144@psf.upfronthosting.co.za>
Message-ID: <1522249278.63.0.467229070634.issue33144@psf.upfronthosting.co.za>


Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> added the comment:

In addition, I took the opportunity to fix a bug in the original _randbelow in that it would only raise the advertised ValueError on n=0 in the getrandbits-dependent branch, but ZeroDivisionError in the pure random branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33144>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:02:48 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 28 Mar 2018 15:02:48 +0000
Subject: [issue33106] Deleting a key in a read-only gdbm results in KeyError, 
 not gdbm.error
In-Reply-To: <1521495851.1.0.467229070634.issue33106@psf.upfronthosting.co.za>
Message-ID: <1522249368.98.0.467229070634.issue33106@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I like this idea. But this is a behavior change so I think it could only be applied to master branch. But there is a problem, except dbm.gnu and dbm.ndbm, we also get dbm.dumb. It already raises a ValueError when deleting a key in readonly mode. Does it need to be changed to raise dbm.dumb.error to achieve consistency?

----------
nosy: +xiang.zhang
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33106>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:04:21 2018
From: report at bugs.python.org (Maxim Avanov)
Date: Wed, 28 Mar 2018 15:04:21 +0000
Subject: [issue33170] New type based on int() created with typing.NewType is
 not consistent
In-Reply-To: <1522248688.28.0.467229070634.issue33170@psf.upfronthosting.co.za>
Message-ID: <1522249461.65.0.467229070634.issue33170@psf.upfronthosting.co.za>


Maxim Avanov <maxim.avanov at gmail.com> added the comment:

Logically, I would expect it to behave similarly to

```
>>> class PercentDiscount(int): pass

>>> PercentDiscount('50') == PercentDiscount(50)
True
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33170>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:04:27 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:04:27 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522249467.96.0.467229070634.issue33126@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
pull_requests: +6016
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:04:53 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:04:53 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522249493.02.0.467229070634.issue33126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, it seems only PyBuffer_ToContiguous() is worth documenting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:18:32 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 28 Mar 2018 15:18:32 +0000
Subject: [issue33124] Lazy execution of module bytecode
In-Reply-To: <1521757031.84.0.467229070634.issue33124@psf.upfronthosting.co.za>
Message-ID: <1522250312.98.0.467229070634.issue33124@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Serhiy: There is a semi-common case where global constants can be quite expensive, specifically, initializing a global full of expensive to compute/serialize data so it will be shared post-fork when doing multiprocessing on a POSIX system. That said, that would likely be a case where lazy initialization would be a problem; you don't want each worker independently initializing the global lazily.

Also, for all practical purposes, aren't enums and namedtuples global constants too? Since they don't rely on any syntax based support at point of use, they're just a "function call" followed by assignment to a global name; you couldn't really separate the concept of global constants from enums/namedtuple definitions, right?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33124>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:21:36 2018
From: report at bugs.python.org (Maxim Avanov)
Date: Wed, 28 Mar 2018 15:21:36 +0000
Subject: [issue33170] New type based on int() created with typing.NewType is
 not consistent
In-Reply-To: <1522248688.28.0.467229070634.issue33170@psf.upfronthosting.co.za>
Message-ID: <1522250496.75.0.467229070634.issue33170@psf.upfronthosting.co.za>


Maxim Avanov <maxim.avanov at gmail.com> added the comment:

Ok, after further reading, I see that NewType creates an identity stub.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33170>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:26:37 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:26:37 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522250797.59.0.467229070634.issue33126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset aa50bf08e64f49d57917ab0b1aadf4308a3168a6 by Antoine Pitrou in branch 'master':
bpo-33126: Document PyBuffer_ToContiguous() (#6292)
https://github.com/python/cpython/commit/aa50bf08e64f49d57917ab0b1aadf4308a3168a6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:27:55 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 15:27:55 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522250875.13.0.467229070634.issue33126@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6017

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:29:01 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 28 Mar 2018 15:29:01 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522250941.41.0.467229070634.issue33126@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6018

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:38:42 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:38:42 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522251522.81.0.467229070634.issue33166@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding Chris Wilcox who wrote the original patch using GetMaximumProcessorCount.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:45:10 2018
From: report at bugs.python.org (Jonathan)
Date: Wed, 28 Mar 2018 15:45:10 +0000
Subject: [issue33172] Update built-in version of SQLite3
Message-ID: <1522251910.92.0.467229070634.issue33172@psf.upfronthosting.co.za>


New submission from Jonathan <bugreports at lightpear.com>:

The current version of SQLite (in Python 3.6) is 3.7.17 which was released almost 5 years ago - https://www.sqlite.org/releaselog/3_7_17.html

Given that user updating of the version of SQLite used by Python is something of a pain (and the process is different across platforms (*and* different again for virtual-envs across platforms)), can the built-in version please be updated to a more recent version? This will allow usage of new SQLite features and users can benefit from a lot of performance enhancements/optimisations too.

SQLite has excellent backwards compatibility, so except for any regressions (and they run over a hundred million tests per release to keep them to a minimum), any newer version will be backwards compatible with that version.
Thanks

----------
messages: 314610
nosy: jonathan-lp
priority: normal
severity: normal
status: open
title: Update built-in version of SQLite3
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33172>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:47:36 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:47:36 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522252056.83.0.467229070634.issue33126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 18fdc87207ea65b3906f07cb47c51a609e442f93 by Antoine Pitrou (Miss Islington (bot)) in branch '3.6':
bpo-33126: Document PyBuffer_ToContiguous() (GH-6292) (GH-6293)
https://github.com/python/cpython/commit/18fdc87207ea65b3906f07cb47c51a609e442f93


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:50:27 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:50:27 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522252227.19.0.467229070634.issue33126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 6124d8ec0d1eb8016e5e54a4d341b8f4f995623c by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
bpo-33126: Document PyBuffer_ToContiguous() (GH-6292) (GH-6294)
https://github.com/python/cpython/commit/6124d8ec0d1eb8016e5e54a4d341b8f4f995623c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:50:58 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Mar 2018 15:50:58 +0000
Subject: [issue33126] Some C buffer protocol APIs not documented
In-Reply-To: <1521823746.22.0.467229070634.issue33126@psf.upfronthosting.co.za>
Message-ID: <1522252258.92.0.467229070634.issue33126@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/issue33126>
_______________________________________

From report at bugs.python.org  Wed Mar 28 11:51:39 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 28 Mar 2018 15:51:39 +0000
Subject: [issue33106] Deleting a key in a read-only gdbm results in KeyError, 
 not gdbm.error
In-Reply-To: <1521495851.1.0.467229070634.issue33106@psf.upfronthosting.co.za>
Message-ID: <1522252299.64.0.467229070634.issue33106@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +6019
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33106>
_______________________________________

From report at bugs.python.org  Wed Mar 28 12:28:48 2018
From: report at bugs.python.org (Walt Askew)
Date: Wed, 28 Mar 2018 16:28:48 +0000
Subject: [issue33173] GzipFile's .seekable() returns True even if underlying
 buffer is not seekable
Message-ID: <1522254528.0.0.467229070634.issue33173@psf.upfronthosting.co.za>


New submission from Walt Askew <waltaskew at gmail.com>:

The seekable method on gzip.GzipFile always returns True, even if the underlying buffer is not seekable. However, if seek is called on the GzipFile, the seek will fail unless the underlying buffer is seekable. This can cause consumers of the GzipFile object to mistakenly believe calling seek on the object is safe, when in fact it will lead to an exception.

For example, this led to a bug when I was trying to use requests & boto3 to stream & decompress an S3 upload like so:

resp = requests.get(uri, stream=True)
decompressed = gzip.GzipFile(fileobj=resp.raw)
boto3.client('s3').upload_fileobj(decompressed, Bucket=bucket, Key=key)

boto3 checks the seekable method on the the GzipFile, chooses a code path based on the file being seekable but later raises an exception when the seek call fails because the underlying HTTP stream is not seekable.

----------
components: Library (Lib)
messages: 314613
nosy: Walt Askew
priority: normal
severity: normal
status: open
title: GzipFile's .seekable() returns True even if underlying buffer is not seekable
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33173>
_______________________________________

From report at bugs.python.org  Wed Mar 28 12:55:46 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 16:55:46 +0000
Subject: [issue33172] Update built-in version of SQLite3
In-Reply-To: <1522251910.92.0.467229070634.issue33172@psf.upfronthosting.co.za>
Message-ID: <1522256146.05.0.467229070634.issue33172@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Python source releases do not include SQLite: the build process links Python with a system-supplied SQLite library or some local copy supplied by the builder, depending on the platform and the build setters.  The pre-built versions of Python for Windows and macOS downloadable from python.org do ship with their own versions of SQLite; currently both use version 3.21.0 with Python 3.6.4.  So, depending on what platform you are on and where you obtained your Python from, you may be able to upgrade SQLite through some system package update and, if the Python in-use dynamically links to it, you would be all set.  If you build Python yourself from source, you can also build your own version of SQLite and use it (see Python's top-level setup.py for exact details on where the build looks for SQLite files).

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33172>
_______________________________________

From report at bugs.python.org  Wed Mar 28 13:27:34 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Mar 2018 17:27:34 +0000
Subject: [issue30891] importlib: _find_and_load() race condition on
 sys.modules[name] check
In-Reply-To: <1499679864.46.0.419806460775.issue30891@psf.upfronthosting.co.za>
Message-ID: <1522258054.47.0.467229070634.issue30891@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

There's a bunch of things wrong with zipimport, just ask Thomas. ;)

----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30891>
_______________________________________

From report at bugs.python.org  Wed Mar 28 14:27:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 18:27:17 +0000
Subject: [issue30622] Fix NPN guard for OpenSSL 1.1
In-Reply-To: <1497107294.71.0.653300932954.issue30622@psf.upfronthosting.co.za>
Message-ID: <1522261637.34.0.467229070634.issue30622@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 15b6400d6439aad9859faba91ce297dfeae8d31d by Ned Deily (Christian Heimes) in branch '3.6':
bpo-30622: Fix backport of NPN fix (#6102)
https://github.com/python/cpython/commit/15b6400d6439aad9859faba91ce297dfeae8d31d


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30622>
_______________________________________

From report at bugs.python.org  Wed Mar 28 14:27:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 18:27:17 +0000
Subject: [issue32872] backport of #32305 causes regressions in various packages
In-Reply-To: <1519031028.52.0.467229070634.issue32872@psf.upfronthosting.co.za>
Message-ID: <1522261637.65.0.714561066657.issue32872@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 7f554c536cfe2e66a1ff0a36c8896040be1e5aee by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-32872: Avoid regrtest compatibility issue with namespace packages. (GH-6276) (GH-6278)
https://github.com/python/cpython/commit/7f554c536cfe2e66a1ff0a36c8896040be1e5aee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32872>
_______________________________________

From report at bugs.python.org  Wed Mar 28 14:27:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Mar 2018 18:27:17 +0000
Subject: [issue33163] Upgrade pip to 9.0.3 and setuptools to v39.0.1
In-Reply-To: <1522224813.43.0.467229070634.issue33163@psf.upfronthosting.co.za>
Message-ID: <1522261637.76.0.574204596225.issue33163@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset db65936a40e13144ec5307d16755a954f6a36b7e by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-33163: Upgrade pip to 9.0.3 and setuptools to v39.0.1. (GH-6285)
https://github.com/python/cpython/commit/db65936a40e13144ec5307d16755a954f6a36b7e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33163>
_______________________________________

From report at bugs.python.org  Wed Mar 28 16:01:02 2018
From: report at bugs.python.org (William Scullin)
Date: Wed, 28 Mar 2018 20:01:02 +0000
Subject: [issue33174] error building the _sha3 module with Intel 2018 compilers
Message-ID: <1522267262.01.0.467229070634.issue33174@psf.upfronthosting.co.za>


New submission from William Scullin <wscullin at gmail.com>:

When building Python 3.6.X and later with icc (18.0.0.128 or
18.0.1.163), there's an error building the _sha3 module with any
optimization level other than -O0:

building '_sha3' extension
icc -pthread -fPIC -Wsign-compare -Wunreachable-code -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -fp-model strict -I./Include -I.
-I/usr/local/include
-I/derp/Python-3.6.4/Include
-I/derp/Python-3.6.4 -c
/derp/Python-3.6.4/Modules/_sha3/
sha3module.c -o
build/temp.linux-x86_64-3.6/derp/Python-3.6.4/Modules/_sha3/sha3module.o
": internal error: ** The compiler has encountered an unexpected problem.
** Segmentation violation signal raised. **
Access violation or stack overflow. Please contact Intel Support for assistance.

compilation aborted for
/derp/Python-3.6.4/Modules/_sha3/sha3module.c
(code 4)
...
[ jlselogin2: Python-3.6.4 ]$

if I drop to -O0, compilation works every time. I haven't found
disabling any particular set of optimizations to be useful in
obtaining a successful build.
...
[ jlselogin2: Python-3.6.4 ]$

dropping to -O0, compilation works every time. I haven't found
disabling any particular set of optimizations to be useful in
obtaining a successful build with icc.

 Intel has been notified and a bug filed as this is really a compiler bug. On the Python side, it does not appear possible to use Modules/Setup to drop the optimization level for just _sha3 and I'm hunting for a workaround.

----------
components: Installation
messages: 314619
nosy: wscullin
priority: normal
severity: normal
status: open
title: error building the _sha3 module with Intel 2018 compilers
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33174>
_______________________________________

From report at bugs.python.org  Wed Mar 28 16:13:38 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 28 Mar 2018 20:13:38 +0000
Subject: [issue33174] error building the _sha3 module with Intel 2018 compilers
In-Reply-To: <1522267262.01.0.467229070634.issue33174@psf.upfronthosting.co.za>
Message-ID: <1522268018.76.0.467229070634.issue33174@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33174>
_______________________________________

From report at bugs.python.org  Wed Mar 28 16:19:21 2018
From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSBWYWxv?=)
Date: Wed, 28 Mar 2018 20:19:21 +0000
Subject: [issue9584] fnmatch, glob: Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1522268361.58.0.467229070634.issue9584@psf.upfronthosting.co.za>


Change by Mat?? Valo <matusvalo at gmail.com>:


----------
pull_requests: +6020
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Wed Mar 28 17:04:21 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 28 Mar 2018 21:04:21 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522271061.48.0.467229070634.issue33166@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I created a psutil branch using GetLogicalProcessorInformation() to determine both logical and physical CPUs:
https://github.com/giampaolo/psutil/pull/1257
According to https://stackoverflow.com/questions/31209256 basically all Windows APIs are unreliable and GetLogicalProcessorInformationEx() is what should really be used. 
That is available only starting from Windows 7 though so apparently what we want is GetLogicalProcessorInformationEx() and if not available fallback on GetActiveProcessorCount(ALL_PROCESSOR_GROUPS) which may still report the wrong number of CPUs on 32 bit processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Mar 28 17:06:29 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Wed, 28 Mar 2018 21:06:29 +0000
Subject: [issue32234] Add context management to mailbox.Mailbox
In-Reply-To: <1521831161.37.0.467229070634.issue32234@psf.upfronthosting.co.za>
Message-ID: <CAOy+up49yWgQ=nUwOgwzsoDOZtGh+PqHPckKAz6fueR3JumOSQ@mail.gmail.com>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

The availability of context manager does not make it mandatory if it does
not fit some needs.

> In the last example on https://docs.python.org/3/
> library/mailbox.html#examples inbox is locked and unlocked multiple
> times. The with statement couldn't be used here.
>

I agree with the idea: if the user code needs to manage a lock, using this
context manager is a bad idea.

By the way, this example does not need to manage the lock because 'inbox'
is an instance of mailbox.Maildir so the .lock() and .unlock() calls do
nothing for this class (
https://docs.python.org/3/library/mailbox.html#mailbox.Maildir.unlock).

>
> On https://pymotw.com/3/mailbox/ some examples use the idiom
>
>     mbox = ...
>     mbox.lock()
>     try:
>         ...
>     finally:
>         mbox.unlock()
>
> and others use the idiom
>
>     mbox = ...
>     mbox.lock()
>     try:
>         ...
>     finally:
>         mbox.flush()
>         mbox.close()
>

In the first example, there is a .flush() call at the end of the try block.
In the second case, mbox.flush() is unnecessary because .close() call
flush. So I see it like choosing between (.flush() and .unlock()) or
.close(). It's what the context manager does.

If there is no agreement, perhaps this proposal should be abandoned?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32234>
_______________________________________

From report at bugs.python.org  Wed Mar 28 18:44:03 2018
From: report at bugs.python.org (Donald Stufft)
Date: Wed, 28 Mar 2018 22:44:03 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
In-Reply-To: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>
Message-ID: <1522277043.53.0.467229070634.issue33131@psf.upfronthosting.co.za>


Donald Stufft <donald at stufft.io> added the comment:

Oh, I had never written NEWS entries for upgrading pip/setuptools, with the idea that the specific version being installed is considered an implementation detail. However if folks want it, I can.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Wed Mar 28 19:46:24 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Mar 2018 23:46:24 +0000
Subject: [issue33173] GzipFile's .seekable() returns True even if underlying
 buffer is not seekable
In-Reply-To: <1522254528.0.0.467229070634.issue33173@psf.upfronthosting.co.za>
Message-ID: <1522280784.55.0.467229070634.issue33173@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +6021
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33173>
_______________________________________

From report at bugs.python.org  Wed Mar 28 20:03:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Mar 2018 00:03:47 +0000
Subject: [issue24234] Should we define complex.__complex__ and bytes.__bytes__?
In-Reply-To: <1431985055.48.0.760233282847.issue24234@psf.upfronthosting.co.za>
Message-ID: <1522281827.29.0.467229070634.issue24234@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The difference between __complex__ and __bytes__ on one side, and __int__ and __float__ on other side is that the latter have dedicated type slots while the former are just entries in the type's dict. Thus testing and calling __int__ and __float__ is much faster.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24234>
_______________________________________

From report at bugs.python.org  Wed Mar 28 20:04:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Mar 2018 00:04:41 +0000
Subject: [issue33055] bytes does not implement __bytes__()
In-Reply-To: <1520864882.07.0.467229070634.issue33055@psf.upfronthosting.co.za>
Message-ID: <1522281881.88.0.467229070634.issue33055@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In any case this is a duplicate of 24234

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Should we define complex.__complex__ and bytes.__bytes__?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33055>
_______________________________________

From report at bugs.python.org  Wed Mar 28 20:21:19 2018
From: report at bugs.python.org (qb-cea)
Date: Thu, 29 Mar 2018 00:21:19 +0000
Subject: [issue24132] Direct sub-classing of pathlib.Path
In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za>
Message-ID: <1522282879.33.0.467229070634.issue24132@psf.upfronthosting.co.za>


qb-cea <quentin.bouget at cea.fr> added the comment:

> What about AbstractPath instead of _PurePath ?

I will use this, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24132>
_______________________________________

From report at bugs.python.org  Wed Mar 28 20:32:01 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 29 Mar 2018 00:32:01 +0000
Subject: [issue32798] mmap.flush() on Linux does not accept the "offset" and
 "size" args
In-Reply-To: <1518102419.01.0.467229070634.issue32798@psf.upfronthosting.co.za>
Message-ID: <1522283521.69.0.467229070634.issue32798@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

By the way, there is a note in the "Change History" section of the msync() documentation at http://pubs.opengroup.org/onlinepubs/9699919799/

    The second [EINVAL] error condition is made mandatory.

The second EINVAL error condition they mention is:

    [EINVAL] The value of addr is not a multiple of the page size as returned by sysconf().

So unless I'm missing something obvious, the "the msync() function may fail if" part may now be outdated?

Also, I noticed that we don't have tests for mm.flush(offset) and mm.flush(offset, size) cases. It would be nice to add some tests even if we decide to not merge the documentation PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32798>
_______________________________________

From report at bugs.python.org  Wed Mar 28 21:23:38 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 01:23:38 +0000
Subject: [issue28180] Implementation of the PEP 538: coerce C locale to C.utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1522286618.23.0.467229070634.issue28180@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given that issue 32002 and issue 30672 track the known challenges in testing the expected locale coercion behaviour reliably, I'm going to go ahead and close this overall implementation issue (the feature is there, and works in a way we're happy with, we're just encountering some challenges clearly expressing those expectations as a regression test).

----------
dependencies:  -PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Wed Mar 28 21:50:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 01:50:32 +0000
Subject: [issue33128] PathFinder is twice on sys.meta_path
In-Reply-To: <1521847841.75.0.467229070634.issue33128@psf.upfronthosting.co.za>
Message-ID: <1522288232.89.0.467229070634.issue33128@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Calling initexternalimports InitalizeMainInterpreter and from new_interpreter is right, since we only want these importers on the metapath after we know sys.path has been configured appropriately.

It's the call from InitializeCore that's questionable, since we haven't finished setting up sys.path at that point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33128>
_______________________________________

From report at bugs.python.org  Wed Mar 28 21:55:36 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 01:55:36 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
In-Reply-To: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>
Message-ID: <1522288536.83.0.467229070634.issue33131@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's a useful data point for folks trying to diagnose post-maintenance-update failures when we upgrade pip on their behalf, rather than them explicitly doing it themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Wed Mar 28 21:58:59 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 29 Mar 2018 01:58:59 +0000
Subject: [issue24234] Should we define complex.__complex__ and bytes.__bytes__?
In-Reply-To: <1431985055.48.0.760233282847.issue24234@psf.upfronthosting.co.za>
Message-ID: <1522288739.65.0.467229070634.issue24234@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

It's not necessary for complex() and bytes() to call the special methods if the argument's type is exactly complex or bytes (respectively) -- these cases are already taken care of by the current code.  But adding these special methods enables other code to be more regular, without having to test for the special cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24234>
_______________________________________

From report at bugs.python.org  Wed Mar 28 23:56:21 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 29 Mar 2018 03:56:21 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522295781.36.0.467229070634.issue33166@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> if not available fallback on 
> GetActiveProcessorCount(ALL_PROCESSOR_GROUPS)

The fallback for older versions of Windows is dwNumberOfProcessors from GetSystemInfo. This can be removed from 3.7 and 3.8, which no longer support Windows versions prior to Windows 7.

> GetLogicalProcessorInformationEx() is what should really be used. 

GetActiveProcessorCount and GetMaximumProcessorCount are implemented via GetLogicalProcessorInformationEx (i.e. NtQuerySystemInformation, SystemLogicalProcessorAndGroupInformation). They query the RelationGroup information. For ALL_PROCESSOR_GROUPS, they respectively sum the ActiveProcessorCount and MaximumProcessorCount over all groups.

These functions were added in Windows 7 to support the implementation of logical processor groups, which allows up to 64 logical processors per group. Each process is created in a single group, which is assigned round-robin. A thread can call SetThreadGroupAffinity to manually switch to another group.

Apparently someone at Microsoft advised calling GetMaximumProcessorCount (see issue 30581), but I don't follow this decision. Why should os.cpu_count() include CPUs that may or may not come online? Also, on POSIX it reports sysconf(_SC_NPROCESSORS_ONLN), not sysconf(_SC_NPROCESSORS_CONF), so for Windows it should instead call GetActiveProcessorCount. I assume on BSD that HW_NCPU is similar, though I'm not sure for MacOS. Also on MacOS it appears to be deprecated in favor of HW_LOGICALCPU, HW_LOGICALCPU_MAX, HW_PHYSICALCPU, and HW_PHYSICALCPU_MAX.


> which may still report the wrong number of CPUs on 32 bit processes.

32-bit Windows and WOW64 emulation are limited to 32 CPUs. Applications that need more logical processors should be 64-bit

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Thu Mar 29 02:20:57 2018
From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSBWYWxv?=)
Date: Thu, 29 Mar 2018 06:20:57 +0000
Subject: [issue9584] fnmatch, glob: Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1522304457.92.0.467229070634.issue9584@psf.upfronthosting.co.za>


Mat?? Valo <matusvalo at gmail.com> added the comment:

Hi All,

I have created new patch for handling curly brace expansion. The patch is available on Github PR #6299

----------
nosy: +Mat?? Valo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Thu Mar 29 03:00:37 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 07:00:37 +0000
Subject: [issue33131] Upgrade to pip 10 for Python 3.7
In-Reply-To: <1521876461.03.0.467229070634.issue33131@psf.upfronthosting.co.za>
Message-ID: <1522306837.02.0.467229070634.issue33131@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The changelog for a release is our primary notification to users about what has changed in a Python release.  With 3.6.5, we just had a case where it seemed important to update pip between the release candidate and the final, something we normally would not do.  In the past, we could manually munge the changelog to include this info but it's much more difficult to do so now with the NEWS entries managed via blurb.  In fact, IIRC, it was a design decision to require a b.p.o issue for any item meriting a NEWS item.  So, it's a bit of extra work for you all but it does make life a lot easier for the release team as it's a lot easier to add the NEWS item at the time when the updates are checked in rather than having to go back and do it after the fact. Thanks!

https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-5-final

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33131>
_______________________________________

From report at bugs.python.org  Thu Mar 29 04:05:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 08:05:10 +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: <1522310710.97.0.467229070634.issue31453@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Christian, is there more needed for this issue or can it be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31453>
_______________________________________

From report at bugs.python.org  Thu Mar 29 04:11:13 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Mar 2018 08:11:13 +0000
Subject: [issue33175] dataclasses should look up __set_name__ on class,
 not instance
Message-ID: <1522311073.3.0.467229070634.issue33175@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

Reported by Jelle Zijlstra at https://github.com/python/cpython/pull/6260#pullrequestreview-107905037

----------
assignee: eric.smith
components: Library (Lib)
messages: 314636
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: dataclasses should look up __set_name__ on class, not instance
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33175>
_______________________________________

From report at bugs.python.org  Thu Mar 29 04:21:52 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Mar 2018 08:21:52 +0000
Subject: [issue33176] Allow memoryview.cast(readonly=...)
Message-ID: <1522311712.08.0.467229070634.issue33176@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It may be useful to get a readonly view of a memoryview.

----------
components: Interpreter Core
messages: 314637
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: Allow memoryview.cast(readonly=...)
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33176>
_______________________________________

From report at bugs.python.org  Thu Mar 29 04:36:26 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Mar 2018 08:36:26 +0000
Subject: [issue33175] dataclasses should look up __set_name__ on class,
 not instance
In-Reply-To: <1522311073.3.0.467229070634.issue33175@psf.upfronthosting.co.za>
Message-ID: <1522312586.21.0.467229070634.issue33175@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +6023
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33175>
_______________________________________

From report at bugs.python.org  Thu Mar 29 04:46:52 2018
From: report at bugs.python.org (Artur Yarmolin)
Date: Thu, 29 Mar 2018 08:46:52 +0000
Subject: [issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter
In-Reply-To: <1508407674.96.0.213398074469.issue31817@psf.upfronthosting.co.za>
Message-ID: <1522313212.55.0.467229070634.issue31817@psf.upfronthosting.co.za>


Artur Yarmolin <6598335 at gmail.com> added the comment:

Python 3.6.4
tcl8.6.5+dfsg-2
tk8.6.5-1

The problem:

*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu.so: undefined symbol: Tcl_GetCharLength

still remains!

----------
nosy: +6598335

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31817>
_______________________________________

From report at bugs.python.org  Thu Mar 29 04:47:59 2018
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 29 Mar 2018 08:47:59 +0000
Subject: [issue33177] make install hangs on macOS when there is an existing
 Python app
Message-ID: <1522313279.55.0.467229070634.issue33177@psf.upfronthosting.co.za>


New submission from Joongi Kim <me at daybreaker.info>:

I have installed Python 3.6.4 for macOS by downloading from the official site (www.python.org) and then tried installing 3.6.5 using pyenv.

Then the installation process hangs here:

https://user-images.githubusercontent.com/555156/38078784-57e44462-3378-11e8-8011-9579afc3c811.png

There is a 2-years old issue in pyenv (https://github.com/pyenv/pyenv/issues/512) but this may have to be fixed from here.

----------
components: Installation, macOS
messages: 314639
nosy: achimnol, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: make install hangs on macOS when there is an existing Python app
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33177>
_______________________________________

From report at bugs.python.org  Thu Mar 29 05:02:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 09:02:50 +0000
Subject: [issue33177] make install hangs on macOS when there is an existing
 Python app
In-Reply-To: <1522313279.55.0.467229070634.issue33177@psf.upfronthosting.co.za>
Message-ID: <1522314170.37.0.467229070634.issue33177@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Sorry, we can't do much about pyenv issues, suggest you pursue with that project.  If pyenv uses the python.org installers, there is an installer option to avoid installing into /Applications.  If pyenv does its own Python framework build, it can install the framework and the Applications directory into any directory using the --enable-framework=/path/to/directory option of ./configure.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33177>
_______________________________________

From report at bugs.python.org  Thu Mar 29 05:10:37 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 09:10:37 +0000
Subject: [issue33177] make install hangs on macOS when there is an existing
 Python app
In-Reply-To: <1522313279.55.0.467229070634.issue33177@psf.upfronthosting.co.za>
Message-ID: <1522314637.42.0.467229070634.issue33177@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

P.S. There *is* an old languishing issue, Issue11486, to add an option to configure to have framework builds not try to install into /Applications.  The patch there would need to be updated and turned into a PR for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33177>
_______________________________________

From report at bugs.python.org  Thu Mar 29 05:22:02 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 09:22:02 +0000
Subject: [issue32823] Regression in test -j behavior and time in 3.7.0b1
In-Reply-To: <1518391854.25.0.467229070634.issue32823@psf.upfronthosting.co.za>
Message-ID: <1522315322.72.0.467229070634.issue32823@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Terry, is this still an issue?  Are other Windows developers seeing this?

----------
nosy: +ned.deily, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32823>
_______________________________________

From report at bugs.python.org  Thu Mar 29 06:38:40 2018
From: report at bugs.python.org (Ethan Smith)
Date: Thu, 29 Mar 2018 10:38:40 +0000
Subject: [issue32380] functools.singledispatch interacts poorly with methods
In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za>
Message-ID: <1522319920.65.0.467229070634.issue32380@psf.upfronthosting.co.za>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
pull_requests: +6024

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32380>
_______________________________________

From report at bugs.python.org  Thu Mar 29 06:44:13 2018
From: report at bugs.python.org (Ethan Smith)
Date: Thu, 29 Mar 2018 10:44:13 +0000
Subject: [issue32380] functools.singledispatch interacts poorly with methods
In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za>
Message-ID: <1522320253.19.0.467229070634.issue32380@psf.upfronthosting.co.za>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32380>
_______________________________________

From report at bugs.python.org  Thu Mar 29 07:36:27 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 11:36:27 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522323387.63.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +6025

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Thu Mar 29 07:38:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 11:38:58 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522323538.39.0.467229070634.issue32726@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +6026

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Thu Mar 29 07:41:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 11:41:13 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522323673.8.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 7a6f59e123db1ff4bdf311711ad179421ee12b83 by Ned Deily in branch '3.7':
bpo-32726: macOS 10.6+ installer now builds Tcl/TK 8.6 (GH-6308)
https://github.com/python/cpython/commit/7a6f59e123db1ff4bdf311711ad179421ee12b83


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Thu Mar 29 08:17:13 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 12:17:13 +0000
Subject: [issue32380] functools.singledispatch interacts poorly with methods
In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za>
Message-ID: <1522325833.89.0.467229070634.issue32380@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added ?ukasz to the nosy list, as I'd like his +1 before accepting this change (I do still think it's a good idea, for the same reasons we added partialmethod).

----------
nosy: +lukasz.langa, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32380>
_______________________________________

From report at bugs.python.org  Thu Mar 29 08:47:35 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 12:47:35 +0000
Subject: [issue32726] macOS installer and framework enhancements and changes
 for 3.7.0 and 3.6.5
In-Reply-To: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>
Message-ID: <1522327655.22.0.467229070634.issue32726@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset b9e7fe38a07a16942cb65cb922c234c95e2823a0 by Ned Deily in branch 'master':
bpo-32726: macOS 10.6+ installer now builds Tcl/TK 8.6 (GH-6307)
https://github.com/python/cpython/commit/b9e7fe38a07a16942cb65cb922c234c95e2823a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Thu Mar 29 09:43:08 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 13:43:08 +0000
Subject: [issue30672] PEP 538: Unexpected locale behaviour on *BSD (including
 Mac OS X)
In-Reply-To: <1497518633.36.0.998856107706.issue30672@psf.upfronthosting.co.za>
Message-ID: <1522330988.65.0.467229070634.issue30672@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ned, I'd forgotten about the part of this issue which amounts to "Check for 'POSIX' as a locale coercion trigger in addition to 'C', as not every platform aliases the former to the latter the way glibc does".

So while I don't think this is really a release blocker (as you have to explicitly request the POSIX locale to encounter the discrepancy, and I think fixing it in 3.7.1 would be OK), I *am* bumping it up to "critical", as I think it would be better to resolve this for 3.7.0b4 rather than letting it linger further.

----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30672>
_______________________________________

From report at bugs.python.org  Thu Mar 29 09:48:23 2018
From: report at bugs.python.org (emezh)
Date: Thu, 29 Mar 2018 13:48:23 +0000
Subject: [issue33178] Add support for BigEndianUnion and LittleEndianUnion in
 ctypes
Message-ID: <1522331303.68.0.467229070634.issue33178@psf.upfronthosting.co.za>


New submission from emezh <eugene.mezh at gmail.com>:

Python documentation says that "To build structures with non-native byte order, you can use one of the BigEndianStructure, LittleEndianStructure, BigEndianUnion, and LittleEndianUnion base classes"

However, BigEndianUnion ad LittleEndianUnion are not implemented

>>> from ctypes import *
>>> BigEndianStructure
<class 'ctypes._endian.BigEndianStructure'>
>>> BigEndianUnion
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'BigEndianUnion' is not defined

Is that something that can be added?

See also https://bugs.python.org/issue19023

----------
components: ctypes
messages: 314647
nosy: Eugene Mezhibovsky
priority: normal
severity: normal
status: open
title: Add support for BigEndianUnion and LittleEndianUnion in ctypes
type: enhancement
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33178>
_______________________________________

From report at bugs.python.org  Thu Mar 29 09:48:49 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 13:48:49 +0000
Subject: [issue30672] PEP 538: Unexpected locale behaviour on *BSD (including
 Mac OS X)
In-Reply-To: <1497518633.36.0.998856107706.issue30672@psf.upfronthosting.co.za>
Message-ID: <1522331329.52.0.467229070634.issue30672@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the headsup, Nick.  BTW, some of the discussion in languishing Issue18378 might be relevant here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30672>
_______________________________________

From report at bugs.python.org  Thu Mar 29 09:52:51 2018
From: report at bugs.python.org (emezh)
Date: Thu, 29 Mar 2018 13:52:51 +0000
Subject: [issue33178] Add support for BigEndianUnion and LittleEndianUnion in
 ctypes
In-Reply-To: <1522331303.68.0.467229070634.issue33178@psf.upfronthosting.co.za>
Message-ID: <1522331571.22.0.467229070634.issue33178@psf.upfronthosting.co.za>


emezh <eugene.mezh at gmail.com> added the comment:

updated nosy list

----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, theller

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33178>
_______________________________________

From report at bugs.python.org  Thu Mar 29 10:15:52 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 14:15:52 +0000
Subject: [issue33179] Investigate using a context variable for zero-arg super
 initialisation
Message-ID: <1522332952.84.0.467229070634.issue33179@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As noted in https://docs.python.org/3/reference/datamodel.html?#creating-the-class-object, implementing PEP 487 required the introduction of __classcell__ as a way for __build_class__ to pass the zero-arg super() cell object through to type.__new__.

Now that Python 3.7+ offers context variables, we may be able to design a more robust (and better hidden) alternative which stashes the "current zero-arg super cell object" in a context variable, allowing type.__new__ to retrieve it when needed, without having to pass it through the class body execution namespace.

----------
messages: 314650
nosy: Martin.Teichmann, encukou, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: Investigate using a context variable for zero-arg super initialisation
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33179>
_______________________________________

From report at bugs.python.org  Thu Mar 29 10:29:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 29 Mar 2018 14:29:04 +0000
Subject: [issue33179] Investigate using a context variable for zero-arg super
 initialisation
In-Reply-To: <1522332952.84.0.467229070634.issue33179@psf.upfronthosting.co.za>
Message-ID: <1522333744.34.0.467229070634.issue33179@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This would work only if we had chained contexts from PEP 550.  With PEP 567, swapping the current Context in boundmethods would cause all methods to lose the context that the user wanted them to run in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33179>
_______________________________________

From report at bugs.python.org  Thu Mar 29 10:43:28 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 14:43:28 +0000
Subject: [issue30672] PEP 538: Unexpected locale behaviour on *BSD (including
 Mac OS X)
In-Reply-To: <1497518633.36.0.998856107706.issue30672@psf.upfronthosting.co.za>
Message-ID: <1522334608.48.0.467229070634.issue30672@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The locale module has its own extra layer of oddities that I don't personally understand - #29571 and #20087 are another couple of issues along those lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30672>
_______________________________________

From report at bugs.python.org  Thu Mar 29 10:47:17 2018
From: report at bugs.python.org (Joongi Kim)
Date: Thu, 29 Mar 2018 14:47:17 +0000
Subject: [issue33177] make install hangs on macOS when there is an existing
 Python app
In-Reply-To: <1522313279.55.0.467229070634.issue33177@psf.upfronthosting.co.za>
Message-ID: <1522334837.6.0.467229070634.issue33177@psf.upfronthosting.co.za>


Joongi Kim <me at daybreaker.info> added the comment:

I found that the reason was my Python 3.6.4 installed via the official-installer has the permission of "root:wheel" and pyenv is running in my plain user privilege. Using chown command to change the permissions to "joongi:admin" and retrying worked.

What I'm curious now is: why didn't "rm -r /Application/Python\ 3.6" command explicitly display the permission error and just the whole installation process hanged up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33177>
_______________________________________

From report at bugs.python.org  Thu Mar 29 10:52:29 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 14:52:29 +0000
Subject: [issue33179] Investigate using a context variable for zero-arg super
 initialisation
In-Reply-To: <1522332952.84.0.467229070634.issue33179@psf.upfronthosting.co.za>
Message-ID: <1522335149.82.0.467229070634.issue33179@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that this isn't about the __class__ reference itself - that would still be a closure cell.

This issue is about the fact that since Python 3.6, type.__new__ has handled calling __set_name__ on all the descriptors, so __build_class__ needs a way to pass the cell over to type.__new__.

Currently, the channel for that is the class body execution namespace itself, which created a new requirement for metaclasses to ensure that the "__classcell__" entry actually makes it all the way to "type.__new__". Django at least had to make changes to account for that, and it's mildly disappointing to be imposing that requirement on library and framework authors solely because of a technical limitation in CPython.

Even without context chaining, it seems to me that nesting of class definitions could be handled by making the context variable a list of cell objects and having type.__new__ look at the final entry rather than the whole thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33179>
_______________________________________

From report at bugs.python.org  Thu Mar 29 10:53:31 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 29 Mar 2018 14:53:31 +0000
Subject: [issue33180] Flag for unusable sys.executable
Message-ID: <1522335211.5.0.467229070634.issue33180@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

If you host Python in another program, it's likely that sys.executable is not pointing to a normal Python interpreter. This can cause libraries such as multiprocessing to fail when they try to launch the interpreter again. Worse, it may have launched your application many more times before failure :)

I think we should add either a flag to indicate to any such library that sys.executable is not useful for relaunching Python, or a field that points to the actual executable but can safely be left None (or for most horrendous generality, a list of arguments to relaunch, as sometimes a command line option can get you into a normal interpreter). These would be set by embedders only, and Programs/python.c would set the "normal" values.

Thoughts?

----------
assignee: steve.dower
messages: 314655
nosy: eric.snow, ncoghlan, steve.dower
priority: normal
severity: normal
status: open
title: Flag for unusable sys.executable
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33180>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:01:39 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 29 Mar 2018 15:01:39 +0000
Subject: [issue33180] Flag for unusable sys.executable
In-Reply-To: <1522335211.5.0.467229070634.issue33180@psf.upfronthosting.co.za>
Message-ID: <1522335699.88.0.467229070634.issue33180@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Looking at the docs https://docs.python.org/3/library/sys.html#sys.executable maybe we only need to clarify that it's not None only if it provides the normal command line? Then file bugs against all the libraries that don't work when it's not set?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33180>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:07:53 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Mar 2018 15:07:53 +0000
Subject: [issue33175] dataclasses should look up __set_name__ on class,
 not instance
In-Reply-To: <1522311073.3.0.467229070634.issue33175@psf.upfronthosting.co.za>
Message-ID: <1522336073.62.0.467229070634.issue33175@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 521995205a2cb6b504fe0e39af22a81f785350a3 by Eric V. Smith in branch 'master':
bpo-33175: dataclasses should look up __set_name__ on class, not instance (GH-6305)
https://github.com/python/cpython/commit/521995205a2cb6b504fe0e39af22a81f785350a3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33175>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:09:16 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 29 Mar 2018 15:09:16 +0000
Subject: [issue33175] dataclasses should look up __set_name__ on class,
 not instance
In-Reply-To: <1522311073.3.0.467229070634.issue33175@psf.upfronthosting.co.za>
Message-ID: <1522336156.42.0.467229070634.issue33175@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6027

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33175>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:18:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 29 Mar 2018 15:18:10 +0000
Subject: [issue33179] Investigate using a context variable for zero-arg super
 initialisation
In-Reply-To: <1522332952.84.0.467229070634.issue33179@psf.upfronthosting.co.za>
Message-ID: <1522336690.63.0.467229070634.issue33179@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Even without context chaining, it seems to me that nesting of class definitions could be handled by making the context variable a list of cell objects and having type.__new__ look at the final entry rather than the whole thing.

Hum, yeah, this might work :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33179>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:25:14 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Mar 2018 15:25:14 +0000
Subject: [issue24234] Should we define complex.__complex__ and bytes.__bytes__?
In-Reply-To: <1431985055.48.0.760233282847.issue24234@psf.upfronthosting.co.za>
Message-ID: <1522337114.96.0.467229070634.issue24234@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/issue24234>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:32:41 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 29 Mar 2018 15:32:41 +0000
Subject: [issue33175] dataclasses should look up __set_name__ on class,
 not instance
In-Reply-To: <1522311073.3.0.467229070634.issue33175@psf.upfronthosting.co.za>
Message-ID: <1522337561.11.0.467229070634.issue33175@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset faa6f5c74ca56d4cc0dd9db78d5c8e864b617d0c by Miss Islington (bot) in branch '3.7':
bpo-33175: dataclasses should look up __set_name__ on class, not instance (GH-6305)
https://github.com/python/cpython/commit/faa6f5c74ca56d4cc0dd9db78d5c8e864b617d0c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33175>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:37:46 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 15:37:46 +0000
Subject: [issue33180] Flag for unusable sys.executable
In-Reply-To: <1522335211.5.0.467229070634.issue33180@psf.upfronthosting.co.za>
Message-ID: <1522337866.0.0.467229070634.issue33180@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm not sure what the right solution is at the design level, but I did recently run into a quirk related to this in the embedding tests: on \*nix systems, PySys_SetProgramName affects sys.executable, while Windows ignores it.

But certainly the intention is that a non-None sys.executable should be usable the way multiprocessing and the test suite use it: as a way to run Python in a subprocess. If an embedding environment wants to support that, it can set it to something suitable, and if it doesn't, it can set it to None.

(I do sometimes wonder if subprocess should have some sys.executable-specific helpers though - rerunning Python with the same settings as the current Python requires quite a bit more than just calling sys.executable with no particular options)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33180>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:45:40 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Mar 2018 15:45:40 +0000
Subject: [issue33180] Flag for unusable sys.executable
In-Reply-To: <1522335211.5.0.467229070634.issue33180@psf.upfronthosting.co.za>
Message-ID: <1522338340.52.0.467229070634.issue33180@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also mentioning https://docs.python.org/3/library/multiprocessing.html#multiprocessing.set_executable, since it came up on the pickle-protocol-version-5 thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33180>
_______________________________________

From report at bugs.python.org  Thu Mar 29 11:50:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Mar 2018 15:50:19 +0000
Subject: [issue32823] Regression in test -j behavior and time in 3.7.0b1
In-Reply-To: <1518391854.25.0.467229070634.issue32823@psf.upfronthosting.co.za>
Message-ID: <1522338619.23.0.467229070634.issue32823@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes. For 3.7 and 3.8, nothing appears until 41 seconds because test___all__ takes 40 seconds.  For 3.6, the batch result appears at 37 seconds because test___all__ runs in 36 seconds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32823>
_______________________________________

From report at bugs.python.org  Thu Mar 29 12:08:41 2018
From: report at bugs.python.org (Oliver Urs Lenz)
Date: Thu, 29 Mar 2018 16:08:41 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
Message-ID: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>


New submission from Oliver Urs Lenz <oliver.urs.lenz at gmail.com>:

SimpleHTTPRequestHandler.send_head() has this bit:

        if os.path.isdir(path):
            parts = urllib.parse.urlsplit(self.path)
            if not parts.path.endswith('/'):
                # redirect browser - doing basically what apache does
                self.send_response(HTTPStatus.MOVED_PERMANENTLY)

https://github.com/python/cpython/blob/521995205a2cb6b504fe0e39af22a81f785350a3/Lib/http/server.py#L676

I think there are two issues here:
1) why should the server return a redirect code here, and not (in the code that immediately follows) when it serves an index file?
2) code 301 (permanent redirect) is really unforgiving, browsers like Firefox and Chrome will permanently cache the redirect, making it essentially impossible to undo if you do not control the client, and not trivial even if you do. This will probably not change on the browser-side, general opinion seems to be that limited caching should either be specified in the response header or that a different redirect code should be sent back.
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/thread.html#msg363

Therefore I would like to propose that preferably,
- no redirect code be sent back, or else that
- a different redirect code be sent back, or else that
- no-caching or a time limit be added to the header

(This may require that send_head check for index files instead)

----------
components: Library (Lib)
messages: 314663
nosy: oulenz
priority: normal
severity: normal
status: open
title: SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Thu Mar 29 13:33:46 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Mar 2018 17:33:46 +0000
Subject: [issue33175] dataclasses should look up __set_name__ on class,
 not instance
In-Reply-To: <1522311073.3.0.467229070634.issue33175@psf.upfronthosting.co.za>
Message-ID: <1522344826.36.0.467229070634.issue33175@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/issue33175>
_______________________________________

From report at bugs.python.org  Thu Mar 29 14:03:19 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Mar 2018 18:03:19 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1522346599.21.0.467229070634.issue33166@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

That makes sense to me. Thanks for deciphering this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Thu Mar 29 14:15:43 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 29 Mar 2018 18:15:43 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1522347343.36.0.467229070634.issue33074@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I highly suspect you don't have gdbm installed in your environment and `import dbm.gnu` will fail. When simply using `dbm.open`, it searches through [dbm.gnu, dbm.ndbm, dbm.dumb]. In my environment, macOS 10.13.3, dbm.gnu works correctly(so dbm works correctly) and dbm.ndbm fails with same error. Currently I cannot see any code in Python _dbm module could lead to this error. And POSIX only requires dbm library to support at least 1023 bytes long key/value pairs.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Thu Mar 29 14:43:37 2018
From: report at bugs.python.org (Bernhard Rosenkraenzer)
Date: Thu, 29 Mar 2018 18:43:37 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
Message-ID: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>


New submission from Bernhard Rosenkraenzer <bero at lindev.ch>:

Python 3.7.0b3 fails to build with clang 6.0 (implicit cast from void* to a different pointer type is an error now):

/usr/bin/clang++ -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -g -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw -flto -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw  -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw -fprofile-instr-generate  -I. -I./Include -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw -fPIC -DPy_BUILD_CORE -o Programs/_testembed.o ./Programs/_testembed.c
clang-6.0: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
./Programs/_testembed.c:173:34: warning: ISO C++11 does not allow conversion from string literal to 'wchar_t *' [-Wwritable-strings]
    wchar_t *static_warnoption = L"once";
                                 ^
./Programs/_testembed.c:174:31: warning: ISO C++11 does not allow conversion from string literal to 'wchar_t *' [-Wwritable-strings]
    wchar_t *static_xoption = L"also_not_an_option=2";
                              ^
./Programs/_testembed.c:177:14: error: cannot initialize a variable of type 'wchar_t *' with an rvalue of type 'void *'
    wchar_t *dynamic_once_warnoption = calloc(warnoption_len+1, sizeof(wchar_t));
             ^                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Programs/_testembed.c:178:14: error: cannot initialize a variable of type 'wchar_t *' with an rvalue of type 'void *'
    wchar_t *dynamic_xoption = calloc(xoption_len+1, sizeof(wchar_t));
             ^                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings and 2 errors generated.
make[3]: *** [Makefile:777: Programs/_testembed.o] Error 1

----------
components: Tests
files: python-3.7.0b3-clang-6.0.patch
keywords: patch
messages: 314666
nosy: bero
priority: normal
severity: normal
status: open
title: Python 3.7.0b3 fails to build with clang 6.0
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file47505/python-3.7.0b3-clang-6.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Thu Mar 29 14:49:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 18:49:57 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522349397.25.0.467229070634.issue33182@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ncoghlan, ned.deily
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Thu Mar 29 15:05:46 2018
From: report at bugs.python.org (Robert Xiao)
Date: Thu, 29 Mar 2018 19:05:46 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1522350346.79.0.467229070634.issue33074@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

So we have some other problems then:

(1) It should be documented in dbm, and ideally in shelve, that keys/values over a certain limit might not work. Presently there is no hint that such a limit exists, and until you mentioned it I was unaware that POSIX only required 1023-byte keys and values.
(2) dbm.ndbm should refuse to perform operations that might corrupt the database, or it should be deprecated entirely if this is impossible. A built-in data storage system for Python should not have an easy corruption route, as it is very surprising for users.
(3) It might be worth considering "dbm.sqlite" or somesuch, adapting a SQLite database as a key-value store. The key-value store approach is much simpler than sqlite and appropriate for certain applications, while SQLite itself would provide robustness and correctness. I can volunteer to build such a thing on top of the existing Python SQLite support.
(4) The approach of shelve is incompatible with limited-length values, because shelve's pickles are of an unpredictable length. This suggests that shelve should internally prioritize dumbdbm over ndbm if ndbm cannot guarantee support for arbitrary-length keys/values.
(5) dbm.gnu is not a default, and I can't even work out how to get it enabled with the stock Python installation (i.e. without building my own Python against e.g. Macports gdbm). Is it a problem to ship dbm.gnu as part of the default install, so that it is more feasible to assume its existence? 

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Thu Mar 29 15:59:00 2018
From: report at bugs.python.org (Joel Johnson)
Date: Thu, 29 Mar 2018 19:59:00 +0000
Subject: [issue25433] whitespace in strip()/lstrip()/rstrip()
In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>
Message-ID: <1522353540.48.0.467229070634.issue25433@psf.upfronthosting.co.za>


Joel Johnson <particlemanj2 at gmail.com> added the comment:

I have started working on this and will have a pull request submitted by the end of the week. 

The term "whitespace" appears in several contextual situations throughout the documentation. While all situations would benefit from the definition of "whitespace" contained in the str.isspace() documentation, not all of the situations would benefit from a link to str.isspace() whose primary goal is to document the str.isspace() function and not to provide a global definition of what a whitespace character is.

Therefore I suggest the documentation of Python 3 create a new glossary definition of "whitespace" (which contains the definition currently in the str.isspace() documentation) and is pointed to wherever the term "whitespace" is used in any documentation related to strings - including this specific case of strip()/lstrip()/rstrip().

----------
nosy: +joel.johnson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25433>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:05:00 2018
From: report at bugs.python.org (Patrick Fink)
Date: Thu, 29 Mar 2018 20:05:00 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1522353900.03.0.467229070634.issue5315@psf.upfronthosting.co.za>


Patrick Fink <mail at pfink.de> added the comment:

A workaround to handle signals reliably that I successfully tested now is to execute everything within a subthread and let the main thread just join this subthread. Like:

signal.signal(MY_SIGNAL, signal_handler)
threading.Thread(target = my_main_function)
thread.start()
thread.join()

Doing it like this, the main thread should always listen to signals disregarding whether the subthread is stuck.

----------
nosy: +Patrick Fink

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5315>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:07:40 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Thu, 29 Mar 2018 20:07:40 +0000
Subject: [issue33183] Refactoring: replacing some assertTrue by assertIn
Message-ID: <1522354060.39.0.467229070634.issue33183@psf.upfronthosting.co.za>


New submission from St?phane Blondon <stephane.blondon at gmail.com>:

In several cases, tests use ```self.assertTrue(a in b)```. Using ```self.assertIn(a, b)``` seems to be better.
For examples:
./Lib/test/test_inspect.py:
   self.assertTrue('(po, pk' in repr(sig))
./Lib/test/test_configparser.py:
   self.assertTrue('that_value' in cf['Spacey Bar'])
./Lib/test/test_collections.py:
   self.assertTrue(elem in c)

There are some cases where ```self.assertTrue(a not in b)``` could be replaced by  ```self.assertNotIn(a, b)```

./Lib/tkinter/test/test_ttk/test_widgets.py:
   self.assertTrue('.' not in value)
./Lib/test/mapping_tests.py:
   self.assertTrue(not ('a' in d))
   self.assertTrue('a' not in d)


$ find . -name "*.py" | xargs grep -r "assertTrue.* in "
finds 131 occurences but there are some false positives inside the output.

I can write a patch if you are interested.

----------
components: Tests
messages: 314670
nosy: sblondon
priority: normal
severity: normal
status: open
title: Refactoring: replacing some assertTrue by assertIn
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33183>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:27:21 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Mar 2018 20:27:21 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
In-Reply-To: <1522247418.61.0.467229070634.issue33169@psf.upfronthosting.co.za>
Message-ID: <1522355241.42.0.467229070634.issue33169@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:29:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Mar 2018 20:29:02 +0000
Subject: [issue33183] Refactoring: replacing some assertTrue by assertIn
In-Reply-To: <1522354060.39.0.467229070634.issue33183@psf.upfronthosting.co.za>
Message-ID: <1522355342.14.0.467229070634.issue33183@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue16510.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Using appropriate checks in tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33183>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:37:25 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Mar 2018 20:37:25 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
In-Reply-To: <1522247418.61.0.467229070634.issue33169@psf.upfronthosting.co.za>
Message-ID: <1522355845.02.0.467229070634.issue33169@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Correct because as documented it calls invalidate_caches() on meta-path finders and the one that handles sys.path calls invalidate_caches() on the finders found in sys.path_importer_cache() (as documented by https://docs.python.org/3/library/importlib.html#importlib.machinery.PathFinder.invalidate_caches). Since None isn't a finder it doesn't do anything there as there is no method to call. So the "full of lies" comment by the OP on the mypy repo is over-the-top/incorrect.

Now tweaking https://github.com/python/cpython/blob/521995205a2cb6b504fe0e39af22a81f785350a3/Lib/importlib/_bootstrap_external.py#L1180-L1186 to delete entries in sys.path_importer_cache() that are set to None is straight-forward, but I don't think we can backport since it would be going against what the documentation says it does.

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:46:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 20:46:57 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1522356417.36.0.467229070634.issue33074@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Addressing your point (5):

> (5) dbm.gnu is not a default, and I can't even work out how to get it enabled with the stock Python installation (i.e. without building my own Python against e.g. Macports gdbm)

If you are using MacPorts, the easiest way is to use a Python from MacPorts. For example,
  ports install py36-gdbm
would install everything you would need to use gdbm with their python3.6.
  
> Is it a problem to ship dbm.gnu as part of the default install, so that it is more feasible to assume its existence?

The main problem is that gdbm is GPL3 licensed.  Python source distributions do not include any GPL3-licensed software to avoid tainting Python itself.  We therefore avoid shipping GPL3 software with python.org binary releases, like our macOS installers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:47:39 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 20:47:39 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1522356459.42.0.467229070634.issue33074@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Addressing your point (5):

> (5) dbm.gnu is not a default, and I can't even work out how to get it enabled with the stock Python installation (i.e. without building my own Python against e.g. Macports gdbm)

If you are using MacPorts, the easiest way is to use a Python from MacPorts. For example,
  port install py36-gdbm
would install everything you would need to use gdbm with their python3.6.
  
> Is it a problem to ship dbm.gnu as part of the default install, so that it is more feasible to assume its existence?

The main problem is that gdbm is GPL3 licensed.  Python source distributions do not include any GPL3-licensed software to avoid tainting Python itself.  We therefore avoid shipping GPL3 software with python.org binary releases, like our macOS installers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Thu Mar 29 16:47:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Mar 2018 20:47:50 +0000
Subject: [issue33074] dbm corrupts index on macOS (_dbm module)
In-Reply-To: <1521009252.74.0.467229070634.issue33074@psf.upfronthosting.co.za>
Message-ID: <1522356470.8.0.467229070634.issue33074@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg314673

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33074>
_______________________________________

From report at bugs.python.org  Thu Mar 29 22:11:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Mar 2018 02:11:58 +0000
Subject: [issue33184] Update OpenSSL to 1.1.0h / 1.0.2o
Message-ID: <1522375918.6.0.467229070634.issue33184@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at python.org>:

https://www.openssl.org/source/

----------
messages: 314675
nosy: christian.heimes, ned.deily, steve.dower, zach.ware
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Update OpenSSL to 1.1.0h / 1.0.2o
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33184>
_______________________________________

From report at bugs.python.org  Fri Mar 30 00:39:04 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 04:39:04 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522384744.93.0.467229070634.issue33182@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Huh, I thought we had a clang builder in the pre-merge CI. Is that running an older version of clang, perhaps?

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Fri Mar 30 00:50:25 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 04:50:25 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522385425.02.0.467229070634.issue33182@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +6028
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Fri Mar 30 01:02:38 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 05:02:38 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
In-Reply-To: <1522247418.61.0.467229070634.issue33169@psf.upfronthosting.co.za>
Message-ID: <1522386158.03.0.467229070634.issue33169@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agree that we can't change 3.6 at this late stage, but the change is borderline enough on the "new feature"/"bug fix" scale that I think it's worth asking Ned if he's comfortable with us changing it for 3.7.0b4.

Ned: the change we'd like to make is to update PathFinder.invalidate_caches to delete all entries in sys.path_importer_cache that have a value of None.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Fri Mar 30 01:36:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 05:36:51 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522388211.27.0.467229070634.issue33182@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 69f5c73311a61b05485b19626935bf240ad31c5b by Nick Coghlan in branch 'master':
bpo-33182: Fix pointer types in _testembed (GH-6310)
https://github.com/python/cpython/commit/69f5c73311a61b05485b19626935bf240ad31c5b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Fri Mar 30 01:37:20 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 30 Mar 2018 05:37:20 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522388240.37.0.467229070634.issue33182@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6029

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Fri Mar 30 02:24:08 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 06:24:08 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522391048.42.0.467229070634.issue33182@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 2961717986201d639b60de51e5f2e9aa2573856c by Nick Coghlan (Miss Islington (bot)) in branch '3.7':
bpo-33182: Fix pointer types in _testembed (GH-6310) (GH-6311)
https://github.com/python/cpython/commit/2961717986201d639b60de51e5f2e9aa2573856c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Fri Mar 30 02:26:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 06:26:32 +0000
Subject: [issue33182] Python 3.7.0b3 fails to build with clang 6.0
In-Reply-To: <1522349017.92.0.467229070634.issue33182@psf.upfronthosting.co.za>
Message-ID: <1522391192.43.0.467229070634.issue33182@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the bug report - the 3.7 branch should be buildable again now.

My assumption would be that Travis are still running clang 5, since 6 was only released very recently.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33182>
_______________________________________

From report at bugs.python.org  Fri Mar 30 02:39:52 2018
From: report at bugs.python.org (Dimitri Papadopoulos Orfanos)
Date: Fri, 30 Mar 2018 06:39:52 +0000
Subject: [issue25433] whitespace in strip()/lstrip()/rstrip()
In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>
Message-ID: <1522391992.83.0.467229070634.issue25433@psf.upfronthosting.co.za>


Dimitri Papadopoulos Orfanos <dimitri.papadopoulos at gmail.com> added the comment:

I agree on avoiding a link to str.isspace() and defining "whitespace" instead.

However please note there are many de facto definitions of "whitespace". All of them must be documented - or at least the conceptual classes of "whitespace" and clarify which class each of the following belongs to:

* Unicode whitespaces are by very far the most common: str.isspace(), strip()/lstrip()/rstrip(), Py_UNICODE_ISSPACE.

* Py_ISSPACE targets byte/bytearray but is never used!

* bytearray.strip() does not use Py_ISSPACE but a hardcoded list of ASCII whitespaces instead.

* finally string.whitespace is probably equivalent to the list used by bytearray.strip().

Beyond the docs, I think Python 3 should rationalize bytearray.strip() /  Py_ISSPACE / string.whitespace, probably having bytearray.strip() rely on Py_ISSPACE, and Py_ISSPACE rely on string.whitespace unless string.whitespace is obsoleted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25433>
_______________________________________

From report at bugs.python.org  Fri Mar 30 02:52:39 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 06:52:39 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1522392759.88.0.467229070634.issue18814@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

With PEPs 538 and 540 implemented for 3.7, my thinking on this has evolved a bit.

A recent discussion on python-ideas [1] also introduced me to the third party library, "ftfy", which offers a wide range of tools for cleaning up improperly decoded data: https://ftfy.readthedocs.io/en/latest/

That includes a lone surrogate fixer: https://ftfy.readthedocs.io/en/latest/#ftfy.fixes.fix_surrogates

So a potential way to go here would be to a section on "Handling Improperly Decoded Text Data" to the codecs module documentation, and include ftfy as a See Also link in that new section.

If folks think that would be a reasonable way to go, then I think the clearest way to handle it would be to close this issue as "later" (which still implies "maybe never", but not as strongly as "rejected" does), and open a new issue for the suggested new section in the docs.

[1] https://mail.python.org/pipermail/python-ideas/2018-January/048583.html

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Fri Mar 30 04:30:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Mar 2018 08:30:19 +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: <1522398619.14.0.467229070634.issue32563@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Tidying up old git branches, and I noticed this was still open even though Larry had long ago merged the PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Fri Mar 30 09:41:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Mar 2018 13:41:51 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
In-Reply-To: <1522247418.61.0.467229070634.issue33169@psf.upfronthosting.co.za>
Message-ID: <1522417311.31.0.467229070634.issue33169@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The current behavior is causing problems for at least some use cases so it does seems to be closer to a bug than a feature.  If there is agreement that it is desirable to make the change, I think it's better to do it now in 3.7 than later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Fri Mar 30 11:01:30 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 30 Mar 2018 15:01:30 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
In-Reply-To: <1522417311.31.0.467229070634.issue33169@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLEPVTc1_HtTPSWeW8vnUKX9CUHsCG6KSXki_dtnFANXA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

SGTM.

On Fri, Mar 30, 2018, 06:41 Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at python.org> added the comment:
>
> The current behavior is causing problems for at least some use cases so it
> does seems to be closer to a bug than a feature.  If there is agreement
> that it is desirable to make the change, I think it's better to do it now
> in 3.7 than later.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue33169>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Fri Mar 30 11:51:58 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 30 Mar 2018 15:51:58 +0000
Subject: [issue33185] Python 3.7.0b3 fails in pydoc where b2 did not.
Message-ID: <1522425117.82.0.467229070634.issue33185@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

"pydoc coverage" worked with 3.7b2, but fails with a surprising ModuleNotFoundError for configparser with b3.  The configparser is importable in the Python interpreter.  I tried with -v to what imports were attempted, and configparser isn't even mentioned until the failure message.

Complete reproduction:

# Using 3.7.0b2
$ mktmpenv -p /usr/local/pythonz/pythons/CPython-3.7.0b2/bin/python3.7 -n -q
/Library/Python/2.7/site-packages/virtualenv.py:1098: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
Collecting pip
  Using cached pip-9.0.3-py2.py3-none-any.whl
Collecting setuptools
  Using cached setuptools-39.0.1-py2.py3-none-any.whl
Installing collected packages: pip, setuptools
  Found existing installation: pip 7.1.2
    Uninstalling pip-7.1.2:
      Successfully uninstalled pip-7.1.2
  Found existing installation: setuptools 18.2
    Uninstalling setuptools-18.2:
      Successfully uninstalled setuptools-18.2
Successfully installed pip-9.0.3 setuptools-39.0.1
This is a temporary environment. It will be deleted when you run 'deactivate'.
$ python -V
Python 3.7.0b2
$ pip install -q coverage==4.5.1
$ pydoc coverage
 Help on package coverage:

 NAME
     coverage - Code coverage measurement for Python.

 DESCRIPTION
     Ned Batchelder
     https://nedbatchelder.com/code/coverage

 PACKAGE CONTENTS
     __main__
     annotate
     backunittest
     backward
     bytecode
     cmdline
     collector
     config
     control
     data
     debug
     env
     execfile
     files
     html
     misc
     multiproc
     parser
     phystokens
     pickle2json
     plugin
     plugin_support
     python
     pytracer
     report
     results
     summary
     templite
     tracer
     version
     xmlreport

 DATA
     __url__ = 'https://coverage.readthedocs.io'
     version_info = (4, 5, 1, 'final', 0)

 VERSION
     4.5.1

 FILE
     /usr/local/virtualenvs/tmp-e3c595a6301312d/lib/python3.7/site-packages/coverage/__init__.py


$ deactivate
Removing temporary environment: tmp-e3c595a6301312d
Removing tmp-e3c595a6301312d...

# Using 3.7.0b3
$ mktmpenv -p /usr/local/pythonz/pythons/CPython-3.7.0b3/bin/python3.7 -n -q
/Library/Python/2.7/site-packages/virtualenv.py:1098: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
Collecting pip
  Using cached pip-9.0.3-py2.py3-none-any.whl
Collecting setuptools
  Using cached setuptools-39.0.1-py2.py3-none-any.whl
Installing collected packages: pip, setuptools
  Found existing installation: pip 7.1.2
    Uninstalling pip-7.1.2:
      Successfully uninstalled pip-7.1.2
  Found existing installation: setuptools 18.2
    Uninstalling setuptools-18.2:
      Successfully uninstalled setuptools-18.2
Successfully installed pip-9.0.3 setuptools-39.0.1
This is a temporary environment. It will be deleted when you run 'deactivate'.
$ python -V
Python 3.7.0b3
$ pip install -q coverage==4.5.1
$ pydoc coverage
problem in coverage - ModuleNotFoundError: No module named 'configparser'

$ python -c 'import configparser; print(configparser)'
<module 'configparser' from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/configparser.py'>

$ python -v -m pydoc coverage
import _frozen_importlib # frozen
import _imp # builtin
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import '_warnings' # <class '_frozen_importlib.BuiltinImporter'>
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
import '_frozen_importlib_external' # <class '_frozen_importlib.FrozenImporter'>
import '_io' # <class '_frozen_importlib.BuiltinImporter'>
import 'marshal' # <class '_frozen_importlib.BuiltinImporter'>
import 'posix' # <class '_frozen_importlib.BuiltinImporter'>
import _thread # previously loaded ('_thread')
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import _weakref # previously loaded ('_weakref')
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# installing zipimport hook
import 'zipimport' # <class '_frozen_importlib.BuiltinImporter'>
# installed zipimport hook
import _thread # previously loaded ('_thread')
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import _weakref # previously loaded ('_weakref')
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/__init__.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__init__.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/__init__.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/codecs.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/codecs.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/codecs.cpython-37.pyc'
import '_codecs' # <class '_frozen_importlib.BuiltinImporter'>
import 'codecs' # <_frozen_importlib_external.SourceFileLoader object at 0x1005da438>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/aliases.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/aliases.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/aliases.cpython-37.pyc'
import 'encodings.aliases' # <_frozen_importlib_external.SourceFileLoader object at 0x1005e7f60>
import 'encodings' # <_frozen_importlib_external.SourceFileLoader object at 0x1005cbe80>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/utf_8.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/utf_8.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/utf_8.cpython-37.pyc'
import 'encodings.utf_8' # <_frozen_importlib_external.SourceFileLoader object at 0x1005fac88>
import '_signal' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/latin_1.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/latin_1.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/encodings/__pycache__/latin_1.cpython-37.pyc'
import 'encodings.latin_1' # <_frozen_importlib_external.SourceFileLoader object at 0x1005fe710>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/io.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/io.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/io.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/abc.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/abc.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/abc.cpython-37.pyc'
import '_abc' # <class '_frozen_importlib.BuiltinImporter'>
import 'abc' # <_frozen_importlib_external.SourceFileLoader object at 0x1005fecc0>
import 'io' # <_frozen_importlib_external.SourceFileLoader object at 0x1005fe908>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/site.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/site.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/os.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/os.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/os.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/stat.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/stat.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/stat.cpython-37.pyc'
import '_stat' # <class '_frozen_importlib.BuiltinImporter'>
import 'stat' # <_frozen_importlib_external.SourceFileLoader object at 0x10069d630>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/posixpath.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/posixpath.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/posixpath.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/genericpath.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/genericpath.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/genericpath.cpython-37.pyc'
import 'genericpath' # <_frozen_importlib_external.SourceFileLoader object at 0x1006ad0b8>
import 'posixpath' # <_frozen_importlib_external.SourceFileLoader object at 0x10069dcf8>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/_collections_abc.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/_collections_abc.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/_collections_abc.cpython-37.pyc'
import '_collections_abc' # <_frozen_importlib_external.SourceFileLoader object at 0x1006ad6d8>
import 'os' # <_frozen_importlib_external.SourceFileLoader object at 0x1006102b0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/_bootlocale.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/_bootlocale.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/_bootlocale.cpython-37.pyc'
import '_locale' # <class '_frozen_importlib.BuiltinImporter'>
import '_bootlocale' # <_frozen_importlib_external.SourceFileLoader object at 0x100610278>
import 'site' # <_frozen_importlib_external.SourceFileLoader object at 0x100603828>
Python 3.7.0b3 (default, Mar 29 2018, 23:29:31)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/runpy.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/runpy.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/runpy.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/__init__.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__init__.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/__init__.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/types.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/types.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/types.cpython-37.pyc'
import 'types' # <_frozen_importlib_external.SourceFileLoader object at 0x1006f1be0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/warnings.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/warnings.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/warnings.cpython-37.pyc'
import 'warnings' # <_frozen_importlib_external.SourceFileLoader object at 0x1006f1d30>
import 'importlib' # <_frozen_importlib_external.SourceFileLoader object at 0x1006f17f0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/machinery.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/machinery.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/machinery.cpython-37.pyc'
import 'importlib.machinery' # <_frozen_importlib_external.SourceFileLoader object at 0x1006fbda0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/util.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/util.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/util.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/abc.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/abc.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/importlib/__pycache__/abc.cpython-37.pyc'
import 'importlib.abc' # <_frozen_importlib_external.SourceFileLoader object at 0x100706b38>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/contextlib.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/contextlib.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/contextlib.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/collections/__init__.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/operator.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/operator.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/operator.cpython-37.pyc'
import '_operator' # <class '_frozen_importlib.BuiltinImporter'>
import 'operator' # <_frozen_importlib_external.SourceFileLoader object at 0x100763940>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/keyword.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/keyword.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/keyword.cpython-37.pyc'
import 'keyword' # <_frozen_importlib_external.SourceFileLoader object at 0x10076bac8>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/heapq.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/heapq.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/heapq.cpython-37.pyc'
# extension module '_heapq' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so'
# extension module '_heapq' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so'
import '_heapq' # <_frozen_importlib_external.ExtensionFileLoader object at 0x10076f978>
import 'heapq' # <_frozen_importlib_external.SourceFileLoader object at 0x10076f438>
import 'itertools' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/reprlib.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/reprlib.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/reprlib.cpython-37.pyc'
import 'reprlib' # <_frozen_importlib_external.SourceFileLoader object at 0x10076fa58>
import '_collections' # <class '_frozen_importlib.BuiltinImporter'>
import 'collections' # <_frozen_importlib_external.SourceFileLoader object at 0x100742b00>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/functools.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/functools.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/functools.cpython-37.pyc'
import '_functools' # <class '_frozen_importlib.BuiltinImporter'>
import 'functools' # <_frozen_importlib_external.SourceFileLoader object at 0x100742ef0>
import 'contextlib' # <_frozen_importlib_external.SourceFileLoader object at 0x100712470>
import 'importlib.util' # <_frozen_importlib_external.SourceFileLoader object at 0x1007062e8>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/pkgutil.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/pkgutil.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/pkgutil.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/weakref.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/weakref.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/weakref.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/_weakrefset.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/_weakrefset.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/_weakrefset.cpython-37.pyc'
import '_weakrefset' # <_frozen_importlib_external.SourceFileLoader object at 0x1007ad390>
import 'weakref' # <_frozen_importlib_external.SourceFileLoader object at 0x100791160>
import 'pkgutil' # <_frozen_importlib_external.SourceFileLoader object at 0x1007480f0>
import 'runpy' # <_frozen_importlib_external.SourceFileLoader object at 0x1006f1400>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/pydoc.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/pydoc.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/pydoc.cpython-37.pyc'
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/inspect.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/inspect.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/inspect.cpython-37.pyc'
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/dis.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/dis.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/dis.cpython-37.pyc'
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/opcode.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/opcode.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/opcode.cpython-37.pyc'
# extension module '_opcode' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so'
# extension module '_opcode' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so'
import '_opcode' # <_frozen_importlib_external.ExtensionFileLoader object at 0x10081ca20>
import 'opcode' # <_frozen_importlib_external.SourceFileLoader object at 0x10081c2e8>
import 'dis' # <_frozen_importlib_external.SourceFileLoader object at 0x10080f0f0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/collections/__pycache__/abc.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/collections/abc.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/collections/__pycache__/abc.cpython-37.pyc'
import 'collections.abc' # <_frozen_importlib_external.SourceFileLoader object at 0x100824a58>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/enum.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/enum.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/enum.cpython-37.pyc'
import 'enum' # <_frozen_importlib_external.SourceFileLoader object at 0x100824a90>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/linecache.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/linecache.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/linecache.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/tokenize.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/tokenize.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/tokenize.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/re.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/re.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/re.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/sre_compile.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/sre_compile.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/sre_compile.cpython-37.pyc'
import '_sre' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/sre_parse.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/sre_parse.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/sre_parse.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/sre_constants.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/sre_constants.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/sre_constants.cpython-37.pyc'
import 'sre_constants' # <_frozen_importlib_external.SourceFileLoader object at 0x10085edd8>
import 'sre_parse' # <_frozen_importlib_external.SourceFileLoader object at 0x1008575f8>
import 'sre_compile' # <_frozen_importlib_external.SourceFileLoader object at 0x100846f98>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/copyreg.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/copyreg.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/copyreg.cpython-37.pyc'
import 'copyreg' # <_frozen_importlib_external.SourceFileLoader object at 0x1008742e8>
import 're' # <_frozen_importlib_external.SourceFileLoader object at 0x1008460f0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/token.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/token.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/token.cpython-37.pyc'
import 'token' # <_frozen_importlib_external.SourceFileLoader object at 0x1008745f8>
import 'tokenize' # <_frozen_importlib_external.SourceFileLoader object at 0x100826ba8>
import 'linecache' # <_frozen_importlib_external.SourceFileLoader object at 0x10081cbe0>
import 'inspect' # <_frozen_importlib_external.SourceFileLoader object at 0x1007e9780>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/platform.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/platform.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/platform.cpython-37.pyc'
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/subprocess.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/subprocess.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/subprocess.cpython-37.pyc'
import 'time' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/signal.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/signal.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/signal.cpython-37.pyc'
import 'signal' # <_frozen_importlib_external.SourceFileLoader object at 0x1008a9080>
import 'errno' # <class '_frozen_importlib.BuiltinImporter'>
# extension module '_posixsubprocess' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so'
# extension module '_posixsubprocess' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so'
import '_posixsubprocess' # <_frozen_importlib_external.ExtensionFileLoader object at 0x1008b2550>
# extension module 'select' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so'
# extension module 'select' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so'
import 'select' # <_frozen_importlib_external.ExtensionFileLoader object at 0x1008b25c0>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/selectors.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/selectors.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/selectors.cpython-37.pyc'
# extension module 'math' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so'
# extension module 'math' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so'
import 'math' # <_frozen_importlib_external.ExtensionFileLoader object at 0x100918160>
import 'selectors' # <_frozen_importlib_external.SourceFileLoader object at 0x1008b2940>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/threading.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/threading.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/threading.cpython-37.pyc'
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/traceback.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/traceback.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/traceback.cpython-37.pyc'
import 'traceback' # <_frozen_importlib_external.SourceFileLoader object at 0x100930240>
import 'threading' # <_frozen_importlib_external.SourceFileLoader object at 0x1008ba940>
import 'subprocess' # <_frozen_importlib_external.SourceFileLoader object at 0x100894e80>
import 'platform' # <_frozen_importlib_external.SourceFileLoader object at 0x100808208>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/urllib/__pycache__/__init__.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/urllib/__init__.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/urllib/__pycache__/__init__.cpython-37.pyc'
import 'urllib' # <_frozen_importlib_external.SourceFileLoader object at 0x1008a02e8>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/urllib/__pycache__/parse.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/urllib/parse.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/urllib/__pycache__/parse.cpython-37.pyc'
import 'urllib.parse' # <_frozen_importlib_external.SourceFileLoader object at 0x1008a0240>
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/getopt.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/getopt.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/getopt.cpython-37.pyc'
# /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/gettext.cpython-37.pyc matches /usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/gettext.py
# code object from '/usr/local/pythonz/pythons/CPython-3.7.0b3/lib/python3.7/__pycache__/gettext.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/locale.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/locale.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/locale.cpython-37.pyc'
import 'locale' # <_frozen_importlib_external.SourceFileLoader object at 0x100971a20>
import 'gettext' # <_frozen_importlib_external.SourceFileLoader object at 0x100952da0>
import 'getopt' # <_frozen_importlib_external.SourceFileLoader object at 0x1009527f0>
# possible namespace for ./coverage
# possible namespace for /Users/ned/coverage
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/__init__.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__init__.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/__init__.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/version.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/version.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/version.cpython-37.pyc'
import 'coverage.version' # <_frozen_importlib_external.SourceFileLoader object at 0x1009a0748>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/control.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/control.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/control.cpython-37.pyc'
import 'atexit' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/env.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/env.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/env.cpython-37.pyc'
import 'coverage.env' # <_frozen_importlib_external.SourceFileLoader object at 0x100a6b4a8>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/annotate.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/annotate.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/annotate.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/files.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/files.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/files.cpython-37.pyc'
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/hashlib.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/hashlib.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/hashlib.cpython-37.pyc'
# extension module '_hashlib' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so'
# extension module '_hashlib' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so'
import '_hashlib' # <_frozen_importlib_external.ExtensionFileLoader object at 0x100a7a6a0>
# extension module '_blake2' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so'
# extension module '_blake2' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so'
import '_blake2' # <_frozen_importlib_external.ExtensionFileLoader object at 0x100a7ada0>
# extension module '_sha3' loaded from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so'
# extension module '_sha3' executed from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so'
import '_sha3' # <_frozen_importlib_external.ExtensionFileLoader object at 0x100a7aeb8>
import 'hashlib' # <_frozen_importlib_external.SourceFileLoader object at 0x100a75b70>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/fnmatch.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/fnmatch.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/fnmatch.cpython-37.pyc'
import 'fnmatch' # <_frozen_importlib_external.SourceFileLoader object at 0x100a7a080>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/ntpath.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/ntpath.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/__pycache__/ntpath.cpython-37.pyc'
import 'ntpath' # <_frozen_importlib_external.SourceFileLoader object at 0x100a800f0>
# /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/backward.cpython-37.pyc matches /usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/backward.py
# code object from '/usr/local/virtualenvs/tmp-95cdcd5f6881b25d/lib/python3.7/site-packages/coverage/__pycache__/backward.cpython-37.pyc'
problem in coverage - ModuleNotFoundError: No module named 'configparser'

# destroy coverage.backward
# destroy coverage.files
# destroy coverage.annotate
# destroy coverage.control
# destroy coverage
# clear builtins._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.__interactivehook__
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup[2] removing sys
# cleanup[2] removing builtins
# cleanup[2] removing _frozen_importlib
# cleanup[2] removing _imp
# cleanup[2] removing _thread
# cleanup[2] removing _warnings
# cleanup[2] removing _weakref
# cleanup[2] removing _frozen_importlib_external
# cleanup[2] removing _io
# cleanup[2] removing marshal
# cleanup[2] removing posix
# cleanup[2] removing zipimport
# cleanup[2] removing encodings
# cleanup[2] removing codecs
# cleanup[2] removing _codecs
# cleanup[2] removing encodings.aliases
# cleanup[2] removing encodings.utf_8
# cleanup[2] removing _signal
# cleanup[2] removing __main__
# destroy __main__
# cleanup[2] removing encodings.latin_1
# cleanup[2] removing io
# cleanup[2] removing abc
# cleanup[2] removing _abc
# cleanup[2] removing site
# destroy site
# cleanup[2] removing os
# cleanup[2] removing stat
# cleanup[2] removing _stat
# cleanup[2] removing posixpath
# cleanup[2] removing genericpath
# cleanup[2] removing os.path
# cleanup[2] removing _collections_abc
# cleanup[2] removing _bootlocale
# destroy _bootlocale
# cleanup[2] removing _locale
# cleanup[2] removing runpy
# destroy runpy
# cleanup[2] removing importlib
# cleanup[2] removing importlib._bootstrap
# cleanup[2] removing importlib._bootstrap_external
# cleanup[2] removing types
# cleanup[2] removing warnings
# cleanup[2] removing importlib.machinery
# cleanup[2] removing importlib.util
# cleanup[2] removing importlib.abc
# cleanup[2] removing contextlib
# destroy contextlib
# cleanup[2] removing collections
# cleanup[2] removing operator
# destroy operator
# cleanup[2] removing _operator
# cleanup[2] removing keyword
# destroy keyword
# cleanup[2] removing heapq
# cleanup[2] removing _heapq
# cleanup[2] removing itertools
# cleanup[2] removing reprlib
# destroy reprlib
# cleanup[2] removing _collections
# cleanup[2] removing functools
# cleanup[2] removing _functools
# cleanup[2] removing pkgutil
# cleanup[2] removing weakref
# destroy weakref
# cleanup[2] removing _weakrefset
# destroy _weakrefset
# cleanup[2] removing inspect
# cleanup[2] removing dis
# cleanup[2] removing opcode
# destroy opcode
# cleanup[2] removing _opcode
# cleanup[2] removing collections.abc
# cleanup[2] removing enum
# cleanup[2] removing linecache
# cleanup[2] removing tokenize
# cleanup[2] removing re
# cleanup[2] removing sre_compile
# cleanup[2] removing _sre
# cleanup[2] removing sre_parse
# cleanup[2] removing sre_constants
# destroy sre_constants
# cleanup[2] removing copyreg
# cleanup[2] removing token
# cleanup[2] removing platform
# cleanup[2] removing subprocess
# cleanup[2] removing time
# cleanup[2] removing signal
# cleanup[2] removing errno
# cleanup[2] removing _posixsubprocess
# cleanup[2] removing select
# cleanup[2] removing selectors
# cleanup[2] removing math
# cleanup[2] removing threading
# cleanup[2] removing traceback
# destroy traceback
# cleanup[2] removing urllib
# cleanup[2] removing urllib.parse
# cleanup[2] removing getopt
# destroy getopt
# cleanup[2] removing gettext
# destroy gettext
# cleanup[2] removing locale
# cleanup[2] removing coverage.version
# destroy coverage.version
# cleanup[2] removing atexit
# cleanup[2] removing coverage.env
# destroy coverage.env
# cleanup[2] removing hashlib
# destroy hashlib
# cleanup[2] removing _hashlib
# cleanup[2] removing _blake2
# cleanup[2] removing _sha3
# cleanup[2] removing fnmatch
# destroy fnmatch
# cleanup[2] removing ntpath
# destroy ntpath
# destroy _sha3
# destroy _blake2
# destroy inspect
# destroy pkgutil
# destroy platform
# destroy urllib
# destroy urllib.parse
# destroy importlib.util
# destroy importlib.abc
# destroy importlib.machinery
# destroy zipimport
# destroy dis
# destroy importlib
# destroy token
# destroy types
# destroy _opcode
# destroy subprocess
# destroy io
# destroy signal
# destroy warnings
# destroy errno
# destroy selectors
# destroy threading
# destroy _signal
# destroy _posixsubprocess
# destroy math
# destroy select
# destroy locale
# destroy encodings
# destroy atexit
# destroy _hashlib
# cleanup[3] wiping _frozen_importlib
# destroy _frozen_importlib_external
# cleanup[3] wiping _imp
# cleanup[3] wiping _thread
# cleanup[3] wiping _warnings
# cleanup[3] wiping _weakref
# cleanup[3] wiping _io
# cleanup[3] wiping marshal
# cleanup[3] wiping posix
# cleanup[3] wiping codecs
# cleanup[3] wiping _codecs
# cleanup[3] wiping encodings.aliases
# cleanup[3] wiping encodings.utf_8
# cleanup[3] wiping encodings.latin_1
# cleanup[3] wiping abc
# cleanup[3] wiping _abc
# cleanup[3] wiping os
# destroy abc
# destroy posixpath
# cleanup[3] wiping stat
# cleanup[3] wiping _stat
# destroy _stat
# cleanup[3] wiping genericpath
# cleanup[3] wiping _collections_abc
# cleanup[3] wiping _locale
# cleanup[3] wiping importlib._bootstrap
# cleanup[3] wiping collections
# destroy _collections_abc
# destroy heapq
# destroy collections.abc
# cleanup[3] wiping _operator
# destroy _operator
# cleanup[3] wiping _heapq
# cleanup[3] wiping itertools
# cleanup[3] wiping _collections
# destroy _collections
# cleanup[3] wiping functools
# destroy _abc
# cleanup[3] wiping _functools
# destroy _functools
# cleanup[3] wiping enum
# cleanup[3] wiping linecache
# destroy tokenize
# cleanup[3] wiping re
# destroy _locale
# destroy enum
# destroy sre_compile
# destroy functools
# destroy copyreg
# cleanup[3] wiping _sre
# cleanup[3] wiping sre_parse
# cleanup[3] wiping time
# cleanup[3] wiping sys
# cleanup[3] wiping builtins
# destroy stat
# destroy genericpath
# destroy _heapq
# destroy re
# destroy _sre
# destroy sre_parse
$

----------
components: Library (Lib)
keywords: 3.7regression
messages: 314686
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.7.0b3 fails in pydoc where b2 did not.
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33185>
_______________________________________

From report at bugs.python.org  Fri Mar 30 11:54:26 2018
From: report at bugs.python.org (Matt Eaton)
Date: Fri, 30 Mar 2018 15:54:26 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522425266.43.0.467229070634.issue33181@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Oliver,

A possible option that would work for both the client side caching and the server would be to pass back a Cache-Control header with a max-age attached when the 301 is returned.

I am thinking something like this:

if os.path.isdir(path):
    parts = urllib.parse.urlsplit(self.path)
    if not parts.path.endswith('/'):
        # redirect browser - doing basically what apache does
        self.send_response(HTTPStatus.MOVED_PERMANENTLY)
        new_parts = (parts[0], parts[1], parts[2] + '/',
                     parts[3], parts[4])
        new_url = urllib.parse.urlunsplit(new_parts)
        self.send_header("Location", new_url)
        self.send_header("Cache-Control", "max-age=600")
        self.end_headers()
        return None
    for index in "index.html", "index.htm":
        index = os.path.join(path, index)
        if os.path.exists(index):
            path = index
            break


Possibly we could even provide some way for the max age to be variable.
Thoughts?

----------
nosy: +agnosticdev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:06:55 2018
From: report at bugs.python.org (alexey@altlinux.org)
Date: Fri, 30 Mar 2018 16:06:55 +0000
Subject: [issue33186] Memory corruption with urllib.parse
Message-ID: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>


New submission from alexey at altlinux.org <alexey at altlinux.org>:

There is a strange behavior while processing data in a "for" loop with urllib.parse.unquote() - looks like memory corruption - a list contains elements that have never been appended.

I'll explain the testcase.

I spotted the problem by checking for any remains of url encoding left in output_list. There were these strings with url encoding left - "bad_boys" dict in testcase. Now, when iterating through input_list (read from "data.txt"), I'm checking for those problematic entries and printing what is being appended to the output_list as well as all problematic (unwanted, "Bad Boys") and converted problematic entries ("Normal conversions") existing in the output_list. At some point, unwanted entries appear in output_list. The resulting output_list contains converted and unconverted problematic entries, though input_list's length equals output_list's length.

data.txt needs to be saved along with testcase.py, and then you can run testcase.py.

The output of running testcase.py:

Bad Boys are:
	 seil%2fturbo_firmware 140335684191552
	 intelligent_platforms_proficy_hmi%2fscada_cimplicity 140335684515920
	 seil%2fneu_2fe_plus_firmware 140335684536080
	 seil%2fb1_firmware 140335684134640
	 eil%2fx2_firmware 140335684191984
	 seil%2fx1_firmware 140335684190832
	 seil%2fx2_firmware 140335684190904
	 seil%2fx86_firmware 140335684192488

Input list length is: 17094 

Bad Boy detected
Element type: <class 'str'>
Convertation: seil%2fb1_firmware 140335679096848 >> seil/b1_firmware 140335681345768
Just appended: seil/b1_firmware 140335681345768
Normal conversions in output list:
	 seil/b1_firmware 140335681345768

Bad Boy detected
Element type: <class 'str'>
Convertation: seil%2fx1_firmware 140335679096920 >> seil/x1_firmware 140335681345840
Just appended: seil/x1_firmware 140335681345840
Normal conversions in output list:
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840

Bad Boy detected
Element type: <class 'str'>
Convertation: seil%2fx2_firmware 140335679096992 >> seil/x2_firmware 140335681345912
Just appended: seil/x2_firmware 140335681345912
Normal conversions in output list:
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840
	 seil/x2_firmware 140335681345912

Bad Boy detected
Element type: <class 'str'>
Convertation: seil%2fx86_firmware 140335679134936 >> seil/x86_firmware 140335681346704
Just appended: seil/x86_firmware 140335681346704
Normal conversions in output list:
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840
	 seil/x2_firmware 140335681345912
	 seil/x86_firmware 140335681346704
Bad Boys in output list:
	 eil%2fx2_firmware 140335681346272

Bad Boy detected
Element type: <class 'str'>
Convertation: seil%2fturbo_firmware 140335679200976 >> seil/turbo_firmware 140335679269456
Just appended: seil/turbo_firmware 140335679269456
Normal conversions in output list:
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840
	 seil/x2_firmware 140335681345912
	 seil/x86_firmware 140335681346704
	 seil/turbo_firmware 140335679269456
Bad Boys in output list:
	 eil%2fx2_firmware 140335681346272
	 seil%2fb1_firmware 140335679267800
	 seil%2fx1_firmware 140335679267872
	 seil%2fx2_firmware 140335679267944
	 seil%2fx86_firmware 140335679269384

Bad Boy detected
Element type: <class 'str'>
Convertation: seil%2fneu_2fe_plus_firmware 140335678867056 >> seil/neu_2fe_plus_firmware 140335680328928
Just appended: seil/neu_2fe_plus_firmware 140335680328928
Normal conversions in output list:
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840
	 seil/x2_firmware 140335681345912
	 seil/x86_firmware 140335681346704
	 seil/turbo_firmware 140335679269456
	 seil/neu_2fe_plus_firmware 140335680328928
Bad Boys in output list:
	 eil%2fx2_firmware 140335681346272
	 seil%2fb1_firmware 140335679267800
	 seil%2fx1_firmware 140335679267872
	 seil%2fx2_firmware 140335679267944
	 seil%2fx86_firmware 140335679269384
	 seil%2fturbo_firmware 140335679849576

Bad Boy detected
Element type: <class 'str'>
Convertation: intelligent_platforms_proficy_hmi%2fscada_cimplicity 140335678546800 >> intelligent_platforms_proficy_hmi/scada_cimplicity 140335681194376
Just appended: intelligent_platforms_proficy_hmi/scada_cimplicity 140335681194376
Normal conversions in output list:
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840
	 seil/x2_firmware 140335681345912
	 seil/x86_firmware 140335681346704
	 seil/turbo_firmware 140335679269456
	 seil/neu_2fe_plus_firmware 140335680328928
	 intelligent_platforms_proficy_hmi/scada_cimplicity 140335681194376
Bad Boys in output list:
	 eil%2fx2_firmware 140335681346272
	 seil%2fb1_firmware 140335679267800
	 seil%2fx1_firmware 140335679267872
	 seil%2fx2_firmware 140335679267944
	 seil%2fx86_firmware 140335679269384
	 seil%2fturbo_firmware 140335679849576
	 seil%2fneu_2fe_plus_firmware 140335678934512

FINAL RESULTS
Output list length is: 17094
Normal conversions in output list (Bad Boys -related):
	 seil/b1_firmware 140335681345768
	 seil/x1_firmware 140335681345840
	 seil/x2_firmware 140335681345912
	 seil/x86_firmware 140335681346704
	 seil/turbo_firmware 140335679269456
	 seil/neu_2fe_plus_firmware 140335680328928
	 intelligent_platforms_proficy_hmi/scada_cimplicity 140335681194376
Bad Boys in output list:
	 eil%2fx2_firmware 140335681346272
	 seil%2fb1_firmware 140335679267800
	 seil%2fx1_firmware 140335679267872
	 seil%2fx2_firmware 140335679267944
	 seil%2fx86_firmware 140335679269384
	 seil%2fturbo_firmware 140335679849576
	 seil%2fneu_2fe_plus_firmware 140335678934512
	 intelligent_platforms_proficy_hmi%2fscada_cimplicity 140335681195728

----------
components: Library (Lib)
files: testcase.py
messages: 314688
nosy: alexey at altlinux.org
priority: normal
severity: normal
status: open
title: Memory corruption with urllib.parse
type: security
versions: Python 3.5
Added file: https://bugs.python.org/file47506/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:07:46 2018
From: report at bugs.python.org (alexey@altlinux.org)
Date: Fri, 30 Mar 2018 16:07:46 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522426066.35.0.467229070634.issue33186@psf.upfronthosting.co.za>


Change by alexey at altlinux.org <alexey at altlinux.org>:


Added file: https://bugs.python.org/file47507/data.txt.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:09:12 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 30 Mar 2018 16:09:12 +0000
Subject: [issue33185] Python 3.7.0b3 fails in pydoc where b2 did not.
In-Reply-To: <1522425117.82.0.467229070634.issue33185@psf.upfronthosting.co.za>
Message-ID: <1522426152.29.0.467229070634.issue33185@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Turns out it's even simpler:

$ pydoc itertools
No module named 'ast'

# !!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33185>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:12:12 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Fri, 30 Mar 2018 16:12:12 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522426332.94.0.467229070634.issue33186@psf.upfronthosting.co.za>


Change by Ivan Zakharyaschev <imz at altlinux.org>:


----------
nosy: +imz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:12:36 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 30 Mar 2018 16:12:36 +0000
Subject: [issue33185] Python 3.7.0b3 fails in pydoc where b2 did not.
In-Reply-To: <1522425117.82.0.467229070634.issue33185@psf.upfronthosting.co.za>
Message-ID: <1522426356.93.0.467229070634.issue33185@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Oh, sorry, I forgot that import attempts aren't shown until -vv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33185>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:34:54 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 30 Mar 2018 16:34:54 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
Message-ID: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

The ElementInclude module in ElementTree seems undocumented. I couldn't find any documentation in the stdlib docs. Pretty much the only source that I could find is here:

http://effbot.org/zone/element-xinclude.htm

I noticed it while looking for a place to document the changes of #20928.

----------
assignee: docs at python
components: Documentation
messages: 314691
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: Document ElementInclude (XInclude) support in ElementTree
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:35:14 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Fri, 30 Mar 2018 16:35:14 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522427714.92.0.467229070634.issue33186@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

I've tested this on a e2k machine (e2k is a VLIW/EPIC architecture, similar to ia64), where python3 3.5 has been compiled with a completely different proprietary compiler, and got the same bad result.

python3-3.5.1-alt7.3

(This has also been tested with the same results on an Ubuntu machine.)

So, this probably means that this is not a matter of wrong compiler optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:36:35 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 30 Mar 2018 16:36:35 +0000
Subject: [issue20928] xml.etree.ElementInclude does not include nested
 xincludes
In-Reply-To: <1394829606.55.0.5394943571.issue20928@psf.upfronthosting.co.za>
Message-ID: <1522427795.64.0.467229070634.issue20928@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

There seems to be no documentation currently for ElementInclude. Would be nice if someone who's interested in this feature could take the time to write something up. I created a documentation ticket as issue #33187.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20928>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:41:23 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 30 Mar 2018 16:41:23 +0000
Subject: [issue20928] xml.etree.ElementInclude does not include nested
 xincludes
In-Reply-To: <1394829606.55.0.5394943571.issue20928@psf.upfronthosting.co.za>
Message-ID: <1522428083.37.0.467229070634.issue20928@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

PR is complete now, ready for merging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20928>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:42:08 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Fri, 30 Mar 2018 16:42:08 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522428128.0.0.467229070634.issue33186@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

The bad results are also reproducible with:

# dpkg -l python3.2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                          Version                             Architecture                        Description
+++-=============================================================-===================================-===================================-===============================================================================================================================
ii  python3.2                                                     3.2.3-7                             ia64                                Interactive high-level object-oriented language (version 3.2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:43:24 2018
From: report at bugs.python.org (Geoffrey Spear)
Date: Fri, 30 Mar 2018 16:43:24 +0000
Subject: [issue33185] Python 3.7.0b3 fails in pydoc where b2 did not.
In-Reply-To: <1522425117.82.0.467229070634.issue33185@psf.upfronthosting.co.za>
Message-ID: <1522428204.97.0.467229070634.issue33185@psf.upfronthosting.co.za>


Geoffrey Spear <geoffspear at gmail.com> added the comment:

This behavior seems to have been introduced in commit ee3784594b33c72c3fdca6a71892d22f14045ab6

----------
nosy: +geoffreyspear, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33185>
_______________________________________

From report at bugs.python.org  Fri Mar 30 12:54:41 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Mar 2018 16:54:41 +0000
Subject: [issue33185] Python 3.7.0b3 fails in pydoc where b2 did not.
In-Reply-To: <1522425117.82.0.467229070634.issue33185@psf.upfronthosting.co.za>
Message-ID: <1522428881.69.0.467229070634.issue33185@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33185>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:22:57 2018
From: report at bugs.python.org (Oliver Urs Lenz)
Date: Fri, 30 Mar 2018 17:22:57 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522430577.89.0.467229070634.issue33181@psf.upfronthosting.co.za>


Oliver Urs Lenz <oliver.urs.lenz at gmail.com> added the comment:

That would definitely take the sting out of that permanent redirect. But I am still wondering why we redirect at all. Why not leave redirects to the user and do:

if os.path.isdir(path):
    if not path.endswith('/'):
        path = path + '/'
    for index in "index.html", "index.htm":
        index = os.path.join(path, index)
        if os.path.exists(index):
            path = index
            break

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:26:26 2018
From: report at bugs.python.org (Oliver Urs Lenz)
Date: Fri, 30 Mar 2018 17:26:26 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522430786.72.0.467229070634.issue33181@psf.upfronthosting.co.za>


Oliver Urs Lenz <oliver.urs.lenz at gmail.com> added the comment:

In fact, since we use os.path.join, we could remove that condition altogether:

if os.path.isdir(path):
    for index in "index.html", "index.htm":
        index = os.path.join(path, index)
        if os.path.exists(index):
            path = index
            break

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:27:23 2018
From: report at bugs.python.org (Stephen ONeal)
Date: Fri, 30 Mar 2018 17:27:23 +0000
Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor
In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za>
Message-ID: <1522430843.57.0.467229070634.issue29595@psf.upfronthosting.co.za>


Stephen ONeal <stephen.oneal.04 at gmail.com> added the comment:

My project we're going into the underlying _work_queue and blocking adding more elements based on unfinished_tasks to accomplish this, bubbling this up to the API would be a welcome addition.

----------
nosy: +stephen.oneal.04 at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29595>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:30:54 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 30 Mar 2018 17:30:54 +0000
Subject: [issue33176] Allow memoryview.cast(readonly=...)
In-Reply-To: <1522311712.08.0.467229070634.issue33176@psf.upfronthosting.co.za>
Message-ID: <1522431054.67.0.467229070634.issue33176@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +6030
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33176>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:31:54 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 30 Mar 2018 17:31:54 +0000
Subject: [issue33176] Allow memoryview.cast(readonly=...)
In-Reply-To: <1522311712.08.0.467229070634.issue33176@psf.upfronthosting.co.za>
Message-ID: <1522431114.06.0.467229070634.issue33176@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have created an initial implementation in PR 6314.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33176>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:33:20 2018
From: report at bugs.python.org (Matt Eaton)
Date: Fri, 30 Mar 2018 17:33:20 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522431200.9.0.467229070634.issue33181@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

It looks like the 301 redirect is in place to emulate the behavior that Apache provides when it runs into a trailing slash.  This is observed when this condition is met:

parts = urllib.parse.urlsplit(self.path)
if not parts.path.endswith('/'):

Apache Directory Index Redirect:
http://httpd.apache.org/docs/current/mod/mod_dir.html#DirectoryIndexRedirect

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Fri Mar 30 13:48:35 2018
From: report at bugs.python.org (Oliver Urs Lenz)
Date: Fri, 30 Mar 2018 17:48:35 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522432115.36.0.467229070634.issue33181@psf.upfronthosting.co.za>


Oliver Urs Lenz <oliver.urs.lenz at gmail.com> added the comment:

Yes, but Apache's redirect can be turned off, whereas this can't, so it seems unnecessarily limiting to force this on users. Note that most of the motivation given by Apache doesn't apply here: with my proposed simplification, both types of indices would still be served whether the path contains a trailing slash or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Fri Mar 30 14:03:43 2018
From: report at bugs.python.org (Rick Teachey)
Date: Fri, 30 Mar 2018 18:03:43 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
Message-ID: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>


New submission from Rick Teachey <ricky at teachey.org>:

I'm getting the following error at when attempting to create a new `dataclass` with any base class that is supplied a type variable:

    TypeError: type() doesn't support MRO entry resolution; use types.new_class()

In principle, it seems like this shouldn't cause any problems, since this works as expected:

    @dataclass
    class MyClass(Generic[MyTypeVar]):
        pass

The problem seems to be the call to `type` in `make_dataclass` for instantiating the class object, since `type` doesn't support type variables. If I replace the `dataclass` line that produces the error with the following code block, it seems to work:

    try:
        cls = type(cls_name, bases, namespace)
    except TypeError:
        cls = types.new_class(cls_name, bases, namespace)

I haven't tested, but it might be possible to just remove the call to `type` altogether.

I've attached a file demonstrating the issue.

----------
components: Library (Lib)
files: dataclass_metaclass_issue.py
messages: 314703
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: dataclass MRO entry resolution for type variable metaclasses: TypeError
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47508/dataclass_metaclass_issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 14:21:21 2018
From: report at bugs.python.org (Rick Teachey)
Date: Fri, 30 Mar 2018 18:21:21 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522434081.12.0.467229070634.issue33188@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Sorry: to be clear, the error only occurs when attempting to create the class using `make_dataclass`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 14:22:16 2018
From: report at bugs.python.org (Matt Eaton)
Date: Fri, 30 Mar 2018 18:22:16 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522434136.01.0.467229070634.issue33181@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

I agree with you in regards to the statement, "Apache's redirect can be turned off, whereas this can't."  That is why my first thought would be to try and control this response to the client a bit better by providing a variable max-age.

self.send_header("Cache-Control", "max-age=xxx")

Removing the condition completely would be good idea as well, but would be my second course of action due to this functionality being in the Python code base for awhile now.

if os.path.isdir(path):
    for index in "index.html", "index.htm":
        index = os.path.join(path, index)
        if os.path.exists(index):
            path = index
            break


Those are my thoughts on the matter at least, possibly someone else in the community could weigh in as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Fri Mar 30 14:48:27 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 30 Mar 2018 18:48:27 +0000
Subject: [issue33180] Flag for unusable sys.executable
In-Reply-To: <1522335211.5.0.467229070634.issue33180@psf.upfronthosting.co.za>
Message-ID: <1522435707.24.0.467229070634.issue33180@psf.upfronthosting.co.za>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33180>
_______________________________________

From report at bugs.python.org  Fri Mar 30 15:04:38 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Mar 2018 19:04:38 +0000
Subject: [issue33152] Use list comprehension in timeit module instead of loop
 with append
In-Reply-To: <1522137941.19.0.467229070634.issue33152@psf.upfronthosting.co.za>
Message-ID: <1522436678.68.0.467229070634.issue33152@psf.upfronthosting.co.za>


Change by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib) -Distutils
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33152>
_______________________________________

From report at bugs.python.org  Fri Mar 30 15:10:54 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Mar 2018 19:10:54 +0000
Subject: [issue33069] Maintainer information discarded when writing PKG-INFO
In-Reply-To: <1520948629.75.0.467229070634.issue33069@psf.upfronthosting.co.za>
Message-ID: <1522437054.64.0.467229070634.issue33069@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to have a warning from distutils for cases not handled by older Metadata PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33069>
_______________________________________

From report at bugs.python.org  Fri Mar 30 15:44:48 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Fri, 30 Mar 2018 19:44:48 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522439088.16.0.467229070634.issue33186@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

> a list contains elements that have never been appended

Why do we think that it's true?

1. The described result can be valid if there are "doubly quoted" strings in the input list.

2. Also, there could be a bug in unquote() which doesn't corrupt the list as a side effect, but simply returns a wrong result value, which is indeed appended to the output list at its turn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 15:52:17 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 30 Mar 2018 19:52:17 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522439537.62.0.467229070634.issue33188@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

You can also cause this same error without dataclasses:

from typing import TypeVar, Generic
from types import new_class
MyTypeVar = TypeVar("MyTypeVar")
MyParent = new_class("MyParent", (Generic[MyTypeVar],), {})
c = type('MyChild', (MyParent[int],), {})  # error in 3.8

I assume you get the same error in 3.7, but I can't compile it just now.

The above code works in 3.6. And the code in dataclass_metaclass_issue.py works in 3.6, using the backported dataclasses.py from PyPI.

So it seems this is a typing problem, not a dataclasses problem.

+Ivan, in case he has some insights.

----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:02:12 2018
From: report at bugs.python.org (Rick Teachey)
Date: Fri, 30 Mar 2018 20:02:12 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522440132.34.0.467229070634.issue33188@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Same error on 3.7.

Probably getting beyond my knowledge here but from the error message, it seems like the answer is simply that:

type('MyChild', (MyParent[int],), {})

...is just the wrong way to make a new `type` when utilizing type variables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:07:43 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 30 Mar 2018 20:07:43 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522440463.47.0.467229070634.issue33188@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This is not a bug but an explicit design decision. Generic classes are _static_ typing concept and therefore are not supposed to work freely with _dynamic_ class creation. During discussion of PEP 560 it was decided that there should be at least one way to dynamically create generic classes, `types.new_class` was chosen for this, see https://www.python.org/dev/peps/pep-0560/#dynamic-class-creation-and-types-resolve-bases

Also the exception message is quite clear about this. Unfortunately, PEPs 560 and 557 were discussed in parallel so not every possible interactions where thought out. But is it critical for dataclasses to call `type`? I believe there should be no other differences with `types.new_class`. I would say the latter is even better than `type` because it correctly treats `__prepare__` on the metaclass IIRC. So I would propose to switch from `type()` to `types.new_class()` for dynamic creation of dataclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:18:26 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Fri, 30 Mar 2018 20:18:26 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522441106.96.0.467229070634.issue33186@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

> 1. The described result can be valid if there are "doubly quoted" strings in the input list.

To check this I've modified your testcase.py:

diff --git a/testcase.py b/testcase.py
index b597205..fefcef2 100755
--- a/testcase.py
+++ b/testcase.py
@@ -53,6 +53,11 @@ for entry in input_list:
 	# Conveting
 	conv_entry=urllib.parse.unquote(entry)
 
+	if conv_entry in bad_boys:
+		flag=True
+		print("ABOUT TO APPEND A BAD BOY")
+		print("Conversion:",entry,id(entry),end=" ")
+
 	# Printing (debug)
 	if flag:
 		print(">>",conv_entry,id(conv_entry))
@@ -61,7 +66,7 @@ for entry in input_list:
 	output_list.append(conv_entry)
 
 	# Printing (debug)
-	if entry in bad_boys:
+	if flag:
 		print("Just appended:", output_list[-1], id(output_list[-1]))
 		flag=False	
 		for x in output_list:

Let's run it and look for my new message:

$ ./testcase.py | fgrep -A1 -e ABOUT
ABOUT TO APPEND A BAD BOY
Conversion: eil%252fx2_firmware 139920242273280 >> eil%2fx2_firmware 139920244465360
--
ABOUT TO APPEND A BAD BOY
Conversion: seil%252fb1_firmware 139920242325448 >> seil%2fb1_firmware 139920241899608
--
ABOUT TO APPEND A BAD BOY
Conversion: seil%252fx1_firmware 139920242325520 >> seil%2fx1_firmware 139920241899752
--
ABOUT TO APPEND A BAD BOY
Conversion: seil%252fx2_firmware 139920242325592 >> seil%2fx2_firmware 139920241899896
--
ABOUT TO APPEND A BAD BOY
Conversion: seil%252fx86_firmware 139920242356704 >> seil%2fx86_firmware 139920241901408
--
ABOUT TO APPEND A BAD BOY
Conversion: seil%252fturbo_firmware 139920242416280 >> seil%2fturbo_firmware 139920242993744
--
ABOUT TO APPEND A BAD BOY
Conversion: seil%252fneu_2fe_plus_firmware 139920242065856 >> seil%2fneu_2fe_plus_firmware 139920243007536
--
ABOUT TO APPEND A BAD BOY
Conversion: intelligent_platforms_proficy_hmi%252fscada_cimplicity 139920241710560 >> intelligent_platforms_proficy_hmi%2fscada_cimplicity 139920244342480
$ fgrep -ne 'seil%252fneu_2fe_plus_firmware' data.txt
15191:seil%252fneu_2fe_plus_firmware
$ 

So, there is indeed a "doubly" quoted data, at 15191 in data.txt.

This is not a bug, everything work correctly.

This issue needs to be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:25:16 2018
From: report at bugs.python.org (Riccardo Polignieri)
Date: Fri, 30 Mar 2018 20:25:16 +0000
Subject: [issue33189] pygettext doesn't work with f-strings
Message-ID: <1522441516.38.0.467229070634.issue33189@psf.upfronthosting.co.za>


New submission from Riccardo Polignieri <riccardo.polignieri at gmail.com>:

Tested (on windows) with python 3.6, but I guess it's the same in py3.7: 

# test.py
def hello(x):
  print(_(f'hello {x}'))



> py pygettext.py test.py
Traceback (most recent call last):
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 623, in <module>
    if __name__ == '__main__':
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 597, in main
    for _token in tokens:
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 328, in __call__
    ##              'tstring:', tstring
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 382, in __openseen
    elif ttype == tokenize.STRING:
  File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 236, in safe_eval
    # unwrap quotes, safely
  File "<string>", line 1, in <module>
NameError: name 'x' is not defined

----------
components: Demos and Tools
messages: 314712
nosy: Riccardo Polignieri
priority: normal
severity: normal
status: open
title: pygettext doesn't work with f-strings
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33189>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:33:28 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Mar 2018 20:33:28 +0000
Subject: [issue33130] functools.reduce signature/docstring discordance
In-Reply-To: <1521849944.24.0.467229070634.issue33130@psf.upfronthosting.co.za>
Message-ID: <1522442008.07.0.467229070634.issue33130@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

inspect.signature(functools.reduce) raises, so I presume you mean the header for the reduce entry at
https://docs.python.org/3/library/functools.html#functools.reduce.  The first line of the docstring, functools.reduce.__doc__, also displayed by help(functools.reduce) has an old version of the signature, which disagrees also on the 3rd parameter name. 
doc header: functools.reduce(function, iterable[, initializer])
.__doc__:   reduce(function, sequence[, initial]) -> value

The current PR only touches the body of the doc entry, not what we call the docstring.  It replaces 'sequence' with 'iterable'.

Functools does not have a Python-coded backup for the C-coded reduce, which only accepts arguments by position.  I have not looked at the C code, whose names are not accessible from Python.  The doc and docstring should match, and should use the parameter names we would want to use of args were ever passed by name.  So I think the docstring (in the C code) should be changed to match the doc.

There should really be a '/,' to indicate that args must be passed by position, or do we only use that in ArgClinic signatures (which show up in help output)?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33130>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:43:02 2018
From: report at bugs.python.org (Rick Teachey)
Date: Fri, 30 Mar 2018 20:43:02 +0000
Subject: [issue33190] problem with ABCMeta.__prepare__ when called after
 types.new_class
Message-ID: <1522442582.8.0.467229070634.issue33190@psf.upfronthosting.co.za>


New submission from Rick Teachey <ricky at teachey.org>:

I am pretty sure this is a bug. If not I apologize.

Say I want to dynamically create a new `C` class, with base class `MyABC` (and dynamically assigned abstract method `m`). This works fine if I use `type`, but if I use `new_class`, the keyword argument to the `m` method implementation gets lost somewhere in the call to `ABCMeta.__prepare___`.

I've attached a file to demo. Thanks.

----------
components: Library (Lib)
files: abcmeta_prepare.py
messages: 314714
nosy: Ricyteach, levkivskyi
priority: normal
severity: normal
status: open
title: problem with ABCMeta.__prepare__ when called after types.new_class
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47509/abcmeta_prepare.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33190>
_______________________________________

From report at bugs.python.org  Fri Mar 30 16:47:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Mar 2018 20:47:47 +0000
Subject: [issue33147] Update references for RFC 3548 to RFC 4648
In-Reply-To: <1522082721.06.0.467229070634.issue33147@psf.upfronthosting.co.za>
Message-ID: <1522442867.33.0.467229070634.issue33147@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ewa handles recording of CAs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +Ewa.Jodlowska, docs at python, terry.reedy
stage:  -> patch review
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33147>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:02:10 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 30 Mar 2018 21:02:10 +0000
Subject: [issue33190] problem with ABCMeta.__prepare__ when called after
 types.new_class
In-Reply-To: <1522442582.8.0.467229070634.issue33190@psf.upfronthosting.co.za>
Message-ID: <1522443730.54.0.467229070634.issue33190@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This is not a bug, but a misunderstanding:

* First, ABCMeta doesn't have `__prepare__`, it is just `type.__prepare__`
* Second, the third argument to `types.new_class` is called `kwds` for a reason. It is not a namespace like in `type` but the set of keywords in the equivalent class definition. For example:

types.new_class('Test', (A, B), {'metaclass': Meta, 'foo': 42})

id equivalent to

class Test(A, B, metaclass=Meta, foo=42):
    pass

If you want to populate the namespace, then you should use the fourth argument `exec_body` which should be a callable that takes newly created dictionary and populates it with items. For your case it should be:

C = new_class("C", (MyABC,), {}, exec_body=lambda ns: ns.update(namespace))

If you want to clarify the corresponding docstring, then please open a PR. Otherwise you can close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33190>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:06:20 2018
From: report at bugs.python.org (Rick Teachey)
Date: Fri, 30 Mar 2018 21:06:20 +0000
Subject: [issue33190] problem with ABCMeta.__prepare__ when called after
 types.new_class
In-Reply-To: <1522442582.8.0.467229070634.issue33190@psf.upfronthosting.co.za>
Message-ID: <1522443980.79.0.467229070634.issue33190@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Excellent; thank you very much for the explanation.

I have never done a PR on a project this size but I'll give it a try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33190>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:07:25 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 30 Mar 2018 21:07:25 +0000
Subject: [issue33190] problem with ABCMeta.__prepare__ when called after
 types.new_class
In-Reply-To: <1522442582.8.0.467229070634.issue33190@psf.upfronthosting.co.za>
Message-ID: <1522444045.17.0.467229070634.issue33190@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

https://devguide.python.org/ will help you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33190>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:09:31 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 30 Mar 2018 21:09:31 +0000
Subject: [issue33191] Refleak in posix_spawn
Message-ID: <1522444171.85.0.467229070634.issue33191@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

There is a refleak in posix_spawn; see for example http://buildbot.python.org/all/#/builders/114/builds/53

The attached PR fixes it, but I am not confident that I did it correctly.

----------
components: Interpreter Core
messages: 314719
nosy: gregory.p.smith, ned.deily, pablogsal, vstinner, zach.ware
priority: critical
severity: normal
status: open
title: Refleak in posix_spawn
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33191>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:10:58 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 30 Mar 2018 21:10:58 +0000
Subject: [issue33191] Refleak in posix_spawn
In-Reply-To: <1522444171.85.0.467229070634.issue33191@psf.upfronthosting.co.za>
Message-ID: <1522444258.16.0.467229070634.issue33191@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +patch
pull_requests: +6031
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33191>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:11:43 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Mar 2018 21:11:43 +0000
Subject: [issue33150] Signature error for methods of class
 configparser.Interpolation
In-Reply-To: <1522118388.18.0.467229070634.issue33150@psf.upfronthosting.co.za>
Message-ID: <1522444303.85.0.467229070634.issue33150@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Can you write a test case that raises the exception?  Use .read_string to create the CF instance, as that calls .read_file, which calls ._read, which calls ._join_multiline_values.

I wonder if we could delete .before_read and replace its call with the value passed and intended to be returned.  None of the Interpolation subclasses override it, and it is undocumented in both code and docs.  Ditto for .before_write.

----------
components:  -Build, asyncio
nosy: +terry.reedy
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33150>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:12:12 2018
From: report at bugs.python.org (Rick Teachey)
Date: Fri, 30 Mar 2018 21:12:12 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522444332.14.0.467229070634.issue33188@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Eric: see also Ivan's comment on Issue 33190, which will factor into the solution to this I think. It seems you can't just pass the `namespace` to the `kwds` argument (as I have done in my solution above).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:38:16 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 30 Mar 2018 21:38:16 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1522445896.94.0.467229070634.issue31455@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This added a refleak on 2.7, see http://buildbot.python.org/all/#/builders/78/builds/122 and later builds.  Also, the bug ID in the blurb is incorrect (31544 vs 31455).

----------
nosy: +zach.ware
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Fri Mar 30 17:40:40 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 30 Mar 2018 21:40:40 +0000
Subject: [issue32823] Regression in test -j behavior and time in 3.7.0b1
In-Reply-To: <1518391854.25.0.467229070634.issue32823@psf.upfronthosting.co.za>
Message-ID: <1522446040.76.0.467229070634.issue32823@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Terry, could you give me the full command you use to get that result?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32823>
_______________________________________

From report at bugs.python.org  Fri Mar 30 18:41:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 30 Mar 2018 22:41:22 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522449682.65.0.467229070634.issue33188@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

If we're going to call new_class in make_dataclass, then we should change the signature of make_dataclass to have the new_class parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 18:50:15 2018
From: report at bugs.python.org (Matt Eaton)
Date: Fri, 30 Mar 2018 22:50:15 +0000
Subject: [issue33034] urllib.parse.urlparse and urlsplit not raising
 ValueError for bad port
In-Reply-To: <1520583841.64.0.467229070634.issue33034@psf.upfronthosting.co.za>
Message-ID: <1522450215.09.0.467229070634.issue33034@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

I was able to get some time together today and created a rough draft for the idea that you had Berker on introducing a new API with more strict parsing rules.

This will allow the ValueError to be raised when the URL is parsed rather than when the computed property is used.  

Jonathan, this will help address your concern on the consistency of when the error message is raised.

I added the rough draft on my Github account here:
https://github.com/agnosticdev/cpython-apis/tree/master/url
https://github.com/agnosticdev/cpython-apis/blob/master/url/url.py

Please take a look and let me know what you think.
You can contact me directly to continue the conversation at my email: agnosticdev at gmail.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33034>
_______________________________________

From report at bugs.python.org  Fri Mar 30 18:51:39 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 30 Mar 2018 22:51:39 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522450299.21.0.467229070634.issue33188@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> If we're going to call new_class in make_dataclass, then we should change the signature of make_dataclass to have the new_class parameters.

Why? I think we should care about what API/signature is reasonable/typical for dataclasses use cases, while new_class is really just an implementation detail. IMO passing keyword arguments to metaclass will be much more rare for dataclasses than passing a ready namespace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 20:10:04 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 31 Mar 2018 00:10:04 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522455004.82.0.467229070634.issue33186@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Alexey, I'm afraid I can't make heads or tails of your bug report. You've gone into a detailed description of the "bad results" you have, but you haven't explained *why* they're bad, or what you were expecting.

I'm afraid that I found understanding your test case code a hard slog. A much simpler test case showing input, expected output, and actual output is appreciated. It might help if you read this:

http://sscce.org/

Its written for Java programmers, but the same applies to any programming language.

Please don't go straight to assumptions about the cause of the bug ("memory corruption") until you can demonstrate that there actually is a bug.

Ivan has spent significant effort to understand your test case, thank you Ivan, and concludes:

> This is not a bug, everything work correctly.

so I'm going to close the bug report. If you disagree with Ivan's conclusion, please write back with reasons why you disagree.

It would also significantly help if you can provide a simpler test case that demonstrates expected results and actual results (and preferably input data small enough to fit inline in the testcase script, if possible).

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Fri Mar 30 21:01:31 2018
From: report at bugs.python.org (Rick Teachey)
Date: Sat, 31 Mar 2018 01:01:31 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522458091.51.0.467229070634.issue33188@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

> passing keyword arguments to metaclass will be much more rare for dataclasses than passing a ready namespace

The impetus of my running into these issues was assuming that things like `Generic[MyTypeVar]` would "just work" with `make_dataclass`, which seemed like a valid assumption since the class creation approach made heavy use of by `dataclasses` implies this:

@dataclass
class MyDclass(Generic[MyTypeVar]):
    var: MyTypeVar

The fact that I cannot do this, then, without error is surprising:

MyDclass = make_dataclass("MyDclass", (("var", MyTypeVar),), bases=(Generic[MyTypeVar],))

I'm not stating it HAS to be fixed. Maybe it doesn't have to. But to me, the above seems like the reason to do it if it's going to be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 21:05:02 2018
From: report at bugs.python.org (Rick Teachey)
Date: Sat, 31 Mar 2018 01:05:02 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522458302.95.0.467229070634.issue33188@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

I'll also say: one of the biggest reasons I was excited to read the `dataclasses` PEP was because I thought "AWESOME! Now I can delete all of the stupid boilerplate __init__ and __repr__ methods for those `typing.Sequences`, `typing.Mapping`, etc etc subclasses!"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Fri Mar 30 22:13:41 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 31 Mar 2018 02:13:41 +0000
Subject: [issue23495] The writer.writerows method should be documented as
 accepting any iterable (not only a list)
In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za>
Message-ID: <1522462421.63.0.467229070634.issue23495@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +6032
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23495>
_______________________________________

From report at bugs.python.org  Fri Mar 30 22:26:04 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 31 Mar 2018 02:26:04 +0000
Subject: [issue23495] The writer.writerows method should be documented as
 accepting any iterable (not only a list)
In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za>
Message-ID: <1522463164.09.0.467229070634.issue23495@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

Commit 7901b48a1f89b9bfa9d111ae3725400b466a9baa removed the unnecessary list conversion (3.5+), but the documentation issue remains.

----------
nosy: +ZackerySpytz
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23495>
_______________________________________

From report at bugs.python.org  Fri Mar 30 22:38:37 2018
From: report at bugs.python.org (Rick Teachey)
Date: Sat, 31 Mar 2018 02:38:37 +0000
Subject: [issue33190] problem with ABCMeta.__prepare__ when called after
 types.new_class
In-Reply-To: <1522442582.8.0.467229070634.issue33190@psf.upfronthosting.co.za>
Message-ID: <1522463917.9.0.467229070634.issue33190@psf.upfronthosting.co.za>


Change by Rick Teachey <ricky at teachey.org>:


----------
keywords: +patch
pull_requests: +6033
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33190>
_______________________________________

From report at bugs.python.org  Fri Mar 30 22:58:22 2018
From: report at bugs.python.org (Rick Teachey)
Date: Sat, 31 Mar 2018 02:58:22 +0000
Subject: [issue33190] problem with ABCMeta.__prepare__ when called after
 types.new_class
In-Reply-To: <1522442582.8.0.467229070634.issue33190@psf.upfronthosting.co.za>
Message-ID: <1522465102.96.0.467229070634.issue33190@psf.upfronthosting.co.za>


Rick Teachey <ricky at teachey.org> added the comment:

Thank you; I gave it a go. Hopefully didn't cause too much additional work for someone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33190>
_______________________________________

From report at bugs.python.org  Sat Mar 31 04:21:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 08:21:43 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1522484503.6.0.467229070634.issue20104@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

posix_spawn() is not documented, it contains reference leaks (issue33191) and can cause crashes. It's style doesn't conform PEP 7.

The simplest fix requires changing the undocumented interface.

----------
dependencies: +Refleak in posix_spawn
nosy: +serhiy.storchaka
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sat Mar 31 04:28:04 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 31 Mar 2018 08:28:04 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1522484884.58.0.467229070634.issue31455@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Right, Zachary, thanks for noticing. Py2.7 is actually way more different than I thought, and I hadn't paid enough attention to that. Py3 does all of this in "__init__", whereas Py2 essentially implements "__new__" in C, which requires more cleanup.

BTW, the implementation in Py3 would also benefit from refactoring the error handling code and moving it all in one place. But it shouldn't suffer from the same kind of problem, at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Mar 31 05:03:51 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Mar 2018 09:03:51 +0000
Subject: [issue32823] Regression in test -j behavior and time in 3.7.0b1
In-Reply-To: <1518391854.25.0.467229070634.issue32823@psf.upfronthosting.co.za>
Message-ID: <1522487031.9.0.467229070634.issue32823@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

python -m test -j0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32823>
_______________________________________

From report at bugs.python.org  Sat Mar 31 06:07:36 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 31 Mar 2018 10:07:36 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1522490856.74.0.467229070634.issue31455@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
pull_requests: +6034
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Mar 31 06:13:59 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 31 Mar 2018 10:13:59 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1522491239.91.0.467229070634.issue31455@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

PR 6318 fixes the reference leak for Py2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Mar 31 06:46:25 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 31 Mar 2018 10:46:25 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522493185.5.0.467229070634.issue33188@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch
pull_requests: +6035
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Sat Mar 31 06:57:10 2018
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Sat, 31 Mar 2018 10:57:10 +0000
Subject: [issue33186] Memory corruption with urllib.parse
In-Reply-To: <1522426015.93.0.467229070634.issue33186@psf.upfronthosting.co.za>
Message-ID: <1522493830.38.0.467229070634.issue33186@psf.upfronthosting.co.za>


Ivan Zakharyaschev <imz at altlinux.org> added the comment:

Actually, Alexey shared this problem with me orally first, and then asked to have a look at his report, and I felt that just describing the technical details about what is going on is not enough, and suggested to include a brief sentence which would state what kind of assumptions seemed to be broken to Alexey. And it was:

> a list contains elements that have never been appended.

And this statement actually appeared quite helpful for me: in a few hours after this statement was made, I got an idea that this statement might actually be not true in this case. And this quickly lead me to the demonstration what really happens here, and that it was correct Python behavior.

Without this brief formal statement of the broken assumptions, I had simply had no ideas (because I supposed that something was going wrong according to Alexey's words, and didn't question whether it is really wrong or we might expect these results under some conditions as correct results).

(Actually, I'm a fan of type-checking, and what is more, of languages with expressive types like Agda or Idris where the programmer is to make provable statements of the expected properties written down as types; sometimes, they can be derived automatically, but nevertheless my point is the attitude to programming, even without formal tools: think how the expected properties would be proved, how they would be decomposed into simpler statements during the proof. Well, this is offtopic here, so, Alexey, let's not continue this discussion here.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33186>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:05:11 2018
From: report at bugs.python.org (Matt Eaton)
Date: Sat, 31 Mar 2018 12:05:11 +0000
Subject: [issue33181] SimpleHTTPRequestHandler shouldn't redirect to
 directories with code 301
In-Reply-To: <1522339721.91.0.467229070634.issue33181@psf.upfronthosting.co.za>
Message-ID: <1522497911.05.0.467229070634.issue33181@psf.upfronthosting.co.za>


Matt Eaton <agnosticdev at gmail.com> added the comment:

Adding some core team members to the nosy list to get their take on this as well.

----------
nosy: +berker.peksag, eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33181>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:21:34 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 31 Mar 2018 12:21:34 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522498894.28.0.467229070634.issue33188@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Yeah, no need to change the API. I was over-generalizing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:23:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 12:23:32 +0000
Subject: [issue31544] gettext.Catalog title is not flagged as a class
In-Reply-To: <1506007626.15.0.9927755066.issue31544@psf.upfronthosting.co.za>
Message-ID: <1522499012.86.0.467229070634.issue31544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c498cd8bf81fc47acf2f1f702e8b3bc9bd4aed65 by Serhiy Storchaka (scoder) in branch '2.7':
bpo-31544: Fix a reference leak to 'self' after the previous target error handling fixes. (GH-6318)
https://github.com/python/cpython/commit/c498cd8bf81fc47acf2f1f702e8b3bc9bd4aed65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31544>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:28:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 12:28:02 +0000
Subject: [issue31544] gettext.Catalog title is not flagged as a class
In-Reply-To: <1506007626.15.0.9927755066.issue31544@psf.upfronthosting.co.za>
Message-ID: <1522499282.33.0.467229070634.issue31544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The correct issue for 0694b6a651ba2a53f6323ffb3b23358f43885815 and c498cd8bf81fc47acf2f1f702e8b3bc9bd4aed65 is issue31455.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31544>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:28:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 12:28:47 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1522499327.03.0.467229070634.issue31455@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

New changeset c498cd8bf81fc47acf2f1f702e8b3bc9bd4aed65 by Serhiy Storchaka (scoder) in branch '2.7':
bpo-31544: Fix a reference leak to 'self' after the previous target error handling fixes. (GH-6318)
https://github.com/python/cpython/commit/c498cd8bf81fc47acf2f1f702e8b3bc9bd4aed65

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:29:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 12:29:12 +0000
Subject: [issue31544] gettext.Catalog title is not flagged as a class
In-Reply-To: <1506007626.15.0.9927755066.issue31544@psf.upfronthosting.co.za>
Message-ID: <1522499352.72.0.467229070634.issue31544@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg314739

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31544>
_______________________________________

From report at bugs.python.org  Sat Mar 31 08:43:02 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 31 Mar 2018 12:43:02 +0000
Subject: [issue33188] dataclass MRO entry resolution for type variable
 metaclasses: TypeError
In-Reply-To: <1522433023.64.0.467229070634.issue33188@psf.upfronthosting.co.za>
Message-ID: <1522500182.05.0.467229070634.issue33188@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6036

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33188>
_______________________________________

From report at bugs.python.org  Sat Mar 31 13:04:32 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Mar 2018 17:04:32 +0000
Subject: [issue14119] Ability to adjust queue size in Executors
In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za>
Message-ID: <1522515872.58.0.467229070634.issue14119@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Issue 29595 has a more complete PR, so closing this issue as duplicate.

----------
nosy: +pitrou
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Expose max_queue_size in ThreadPoolExecutor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14119>
_______________________________________

From report at bugs.python.org  Sat Mar 31 13:06:25 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Mar 2018 17:06:25 +0000
Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor
In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za>
Message-ID: <1522515985.65.0.467229070634.issue29595@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please note the PR here has some review comments that need addressing.
Also, it needs its conflicts with git master resolved.

I'm cc'ing Thomas Moreau, who has done a lot of work recently on the concurrent.futures internals.

----------
assignee: davin -> 
nosy: +tomMoral
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29595>
_______________________________________

From report at bugs.python.org  Sat Mar 31 13:20:39 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Mar 2018 17:20:39 +0000
Subject: [issue28053] parameterize what serialization is used in
 multiprocessing
In-Reply-To: <1473454734.41.0.810069156927.issue28053@psf.upfronthosting.co.za>
Message-ID: <1522516839.06.0.467229070634.issue28053@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'd like to know if the work here will be completed soon :-) This currently lacks documentation but also tests.

In particular, looking at the code (and that is supported by Will S' comment above), I feel the API isn't working as intended (i.e. setting the "reducer" property won't actually change the underlying parameters since the "reduction" module is imported eagerly).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28053>
_______________________________________

From report at bugs.python.org  Sat Mar 31 14:07:29 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 31 Mar 2018 18:07:29 +0000
Subject: [issue33169] importlib.invalidate_caches() doesn't clear all caches
In-Reply-To: <1522247418.61.0.467229070634.issue33169@psf.upfronthosting.co.za>
Message-ID: <1522519649.04.0.467229070634.issue33169@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, I will update importlib.machinery.PathFinder.invalidate_caches() to also drop None from sys.path_importer_cache (objects that are not None and do not define invalidate_caches() will be left alone just like they are today). I should hopefully be able to get to this before b4.

----------
assignee:  -> brett.cannon
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33169>
_______________________________________

From report at bugs.python.org  Sat Mar 31 14:18:46 2018
From: report at bugs.python.org (Bassem Girgis)
Date: Sat, 31 Mar 2018 18:18:46 +0000
Subject: [issue32419] Add unittest support for pyc projects
In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za>
Message-ID: <1522520326.47.0.467229070634.issue32419@psf.upfronthosting.co.za>


Bassem Girgis <brgirgis at gmail.com> added the comment:

Please let me know what I need to do in order to close this issue and finally merge the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32419>
_______________________________________

From report at bugs.python.org  Sat Mar 31 16:22:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 20:22:44 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522527764.67.0.467229070634.issue33132@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +6037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 16:24:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 20:24:02 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522527842.09.0.467229070634.issue33132@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +6038

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 16:27:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 20:27:01 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522528021.22.0.467229070634.issue33132@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +6039

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 16:54:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 20:54:16 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522529656.65.0.467229070634.issue33132@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 25c869edd665cba7187910c5b151a0016fec4754 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-33132: Fix reference counting issues in the compiler. (GH-6209). (GH-6321)
https://github.com/python/cpython/commit/25c869edd665cba7187910c5b151a0016fec4754


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 16:57:20 2018
From: report at bugs.python.org (Nitish)
Date: Sat, 31 Mar 2018 20:57:20 +0000
Subject: [issue25433] whitespace in strip()/lstrip()/rstrip()
In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>
Message-ID: <1522529840.27.0.467229070634.issue25433@psf.upfronthosting.co.za>


Change by Nitish <nitishch at protonmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25433>
_______________________________________

From report at bugs.python.org  Sat Mar 31 17:05:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 21:05:39 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522530339.56.0.467229070634.issue33096@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +6040

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sat Mar 31 17:29:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 21:29:39 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522531779.34.0.467229070634.issue33132@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset aa8e51f5ebb2a71c76059f050de01fc3c985376a by Serhiy Storchaka in branch 'master':
bpo-33132: Fix more reference counting issues in the compiler. (GH-6323)
https://github.com/python/cpython/commit/aa8e51f5ebb2a71c76059f050de01fc3c985376a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 17:29:48 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 31 Mar 2018 21:29:48 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522531788.66.0.467229070634.issue33132@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +6041

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 18:32:24 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 31 Mar 2018 22:32:24 +0000
Subject: [issue25433] whitespace in strip()/lstrip()/rstrip()
In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>
Message-ID: <1522535544.01.0.467229070634.issue25433@psf.upfronthosting.co.za>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25433>
_______________________________________

From report at bugs.python.org  Sat Mar 31 18:44:55 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 31 Mar 2018 22:44:55 +0000
Subject: [issue33192] asyncio should use signal.set_wakeup_fd on Windows
Message-ID: <1522536295.45.0.467229070634.issue33192@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

I thought there was already a bug for this, but it came up in conversation again and I can't find one, so, here you go...

It looks like originally there was this bug for making control-C wake up the asyncio event loop in Windows: https://github.com/python/asyncio/issues/191

This required some changes to signal.set_wakeup_fd to work on Windows, which was done in bpo-22018.

But I guess the last step got lost in the shuffle: right now signal.set_wakeup_fd works fine on Windows, but asyncio doesn't actually use it. This means that on Windows you can't wake up this program using control-C:

>>> import asyncio
>>> asyncio.run(asyncio.sleep(100000000))

Both of the Windows event loops should register a wakeup socket with signal.set_wakeup_fd, and arrange for the loop to wake up when data arrives on that socket, and read from it until it's empty again. (And once the loop is awake, Python's normal control-C handling will kick in.) That will make control-C on Windows work similarly to how it does on Unix.

----------
messages: 314749
nosy: asvetlov, giampaolo.rodola, njs, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: asyncio should use signal.set_wakeup_fd on Windows
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33192>
_______________________________________

From report at bugs.python.org  Sat Mar 31 19:41:30 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 31 Mar 2018 23:41:30 +0000
Subject: [issue33132] Possible refcount issues in the compiler
In-Reply-To: <1521894745.19.0.467229070634.issue33132@psf.upfronthosting.co.za>
Message-ID: <1522539690.74.0.467229070634.issue33132@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9e96e7b24e4d3ff4dce4f24c4e469cd5460712c9 by Miss Islington (bot) in branch '3.7':
bpo-33132: Fix more reference counting issues in the compiler. (GH-6323)
https://github.com/python/cpython/commit/9e96e7b24e4d3ff4dce4f24c4e469cd5460712c9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33132>
_______________________________________

From report at bugs.python.org  Sat Mar 31 19:43:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Mar 2018 23:43:00 +0000
Subject: [issue33096] ttk.Treeview.insert() does not allow to insert item with
 "False" iid
In-Reply-To: <1521364150.91.0.467229070634.issue33096@psf.upfronthosting.co.za>
Message-ID: <1522539780.37.0.467229070634.issue33096@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e80a232f2cfdab584133d9779c83885c5f9f1ba6 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-33096: Fix ttk.Treeview.insert. (GH-6228) (GH-6326)
https://github.com/python/cpython/commit/e80a232f2cfdab584133d9779c83885c5f9f1ba6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33096>
_______________________________________

From report at bugs.python.org  Sat Mar 31 20:21:48 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 01 Apr 2018 00:21:48 +0000
Subject: [issue24978] Contributing to Python 2x and 3x Documentation.
 Translation to Russian.
In-Reply-To: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za>
Message-ID: <1522542108.18.0.467229070634.issue24978@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Adding a reference to PEP 545 for contributing documentation translations.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24978>
_______________________________________

From report at bugs.python.org  Sat Mar 31 21:51:24 2018
From: report at bugs.python.org (Robert Collins)
Date: Sun, 01 Apr 2018 01:51:24 +0000
Subject: [issue32419] Add unittest support for pyc projects
In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za>
Message-ID: <1522547484.63.0.467229070634.issue32419@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Whats the use for *unittest* - a tool to help folk develop - to run a test which is only present in sourceless form?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32419>
_______________________________________

From report at bugs.python.org  Sat Mar 31 21:52:42 2018
From: report at bugs.python.org (Robert Collins)
Date: Sun, 01 Apr 2018 01:52:42 +0000
Subject: [issue32419] Add unittest support for pyc projects
In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za>
Message-ID: <1522547562.16.0.467229070634.issue32419@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Oh, and why look for __init__ - in part, because it predates namespace packages, but also because unlike regular imports unittest will do negative things like reading the entire filesystem otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32419>
_______________________________________

From report at bugs.python.org  Sat Mar 31 22:25:44 2018
From: report at bugs.python.org (Stuart Cuthbertson)
Date: Sun, 01 Apr 2018 02:25:44 +0000
Subject: [issue33193] Cannot create a venv on Windows when directory path
 contains dollar character
Message-ID: <1522549543.99.0.467229070634.issue33193@psf.upfronthosting.co.za>


New submission from Stuart Cuthbertson <stuart at sjcuthbertson.me.uk>:

I should clarify first that I haven't reproduced the following bug specifically with venv. I was asked to raise this here after raising an identical issue about virtualenv (https://github.com/pypa/virtualenv/issues/1154); a GitHub user told me this would also apply to venv. 

The bug with virtualenv is that it errors if passed a directory that contains a $ (dollar symbol). $ is a valid character for Windows directory names, filenames, and usernames. So running something simple like `python3 -m venv` (presumably) can fail in some valid Windows directories. 

The full error traceback for virtualenv is available at the above GitHub URL. A commenter in the virtualenv project (see https://github.com/pypa/virtualenv/issues/457#issuecomment-377159868) suggested that this happens because the directory path is passed as-is (with $) to distutils, and distutils is seeing the text following the $ as a placeholder and trying to replace it with a variable, which isn't found.

----------
components: Windows
messages: 314755
nosy: Stuart Cuthbertson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot create a venv on Windows when directory path contains dollar character
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33193>
_______________________________________

From report at bugs.python.org  Sat Mar 31 22:47:34 2018
From: report at bugs.python.org (Marco Rougeth)
Date: Sun, 01 Apr 2018 02:47:34 +0000
Subject: [issue33194] Path-file objects does not have method to delete itself
 if its a file
Message-ID: <1522550854.13.0.467229070634.issue33194@psf.upfronthosting.co.za>


New submission from Marco Rougeth <marco at rougeth.com>:

Path has the method `.rmdir()` for removing the directory, but it doesn't have anything if it correspond to a file.

The `os.remove` could be used here, but I think it should have a more appropriate/explicit  name like `.rmfile()`.

If it make  sense, I'd be glad to work on it.

----------
messages: 314756
nosy: rougeth
priority: normal
severity: normal
status: open
title: Path-file objects does not have method to delete itself if its a file
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33194>
_______________________________________

From report at bugs.python.org  Sat Mar 31 23:16:19 2018
From: report at bugs.python.org (Bassem Girgis)
Date: Sun, 01 Apr 2018 03:16:19 +0000
Subject: [issue32419] Add unittest support for pyc projects
In-Reply-To: <1522547562.16.0.467229070634.issue32419@psf.upfronthosting.co.za>
Message-ID: <CAGCV+-=K18vuw5gFx4fWU6oFQgj3xSrv0U61p+hn-H5QxaZ7Ag@mail.gmail.com>


Bassem Girgis <brgirgis at gmail.com> added the comment:

I Robert,

One use scenario is to run deployment tests for sourceless packages and to
ensure the integrity of the production environment. Very useful in
container environments!

In regards to the looking for the __init__ file, it is obvious that the
logic you mentioned is the reason behind that. However, if the unittest
code used a standard way to figure out "loadable" packages, whatever that
is, it would have captured the fact that python3 can indeed function with
all pyc files.

I would say the fix in here is a dirty one. A better way to solve it is to
call a standard utility which can detect if a package is loadable. This
would resolve this issue and help with any future changes in the standard
as well.

Best regards,
Bassem

Bassem Girgis, PhD

Email: brgirgis at gmail.com

On Sat, Mar 31, 2018 at 8:52 PM, Robert Collins <report at bugs.python.org>
wrote:

>
> Robert Collins <robertc at robertcollins.net> added the comment:
>
> Oh, and why look for __init__ - in part, because it predates namespace
> packages, but also because unlike regular imports unittest will do negative
> things like reading the entire filesystem otherwise.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32419>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32419>
_______________________________________