From report at bugs.python.org  Sat Sep  1 01:30:15 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 01 Sep 2018 05:30:15 +0000
Subject: [issue34560] Backport of uuid1() failure fix
In-Reply-To: <1535754822.12.0.56676864532.issue34560@psf.upfronthosting.co.za>
Message-ID: <1535779815.86.0.56676864532.issue34560@psf.upfronthosting.co.za>


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


----------
nosy: +yan12125

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

From report at bugs.python.org  Sat Sep  1 04:21:37 2018
From: report at bugs.python.org (orlnub123)
Date: Sat, 01 Sep 2018 08:21:37 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535790097.27.0.56676864532.issue34282@psf.upfronthosting.co.za>


orlnub123 <orlnub123 at gmail.com> added the comment:

> For versions 3.6 and 3.7 the solution is to modify the shadow check at line 236 so only DynamicClassAttributes are /not/ shadowed (meaning the _convert method would be shadowed by an _convert member).

Doing that might not be backwards-compatible. An enum with a subclassed behavior and member with the same name would shadow the behavior in favor of the member with the change. I propose adding an extra if statement under it that sets the member if it's named _convert and the _convert method on the class belongs to Enum (so it's not a behavior).

> For 3.8 we can move _convert to the metaclass: I wasn't originally supportive of this idea, but I can see it being useful for other Enum mix-ins such as str.  However, I will want to include a check that such a mix-in is there -- probably by checking that the Enum type is a subclass of the first member's type... something like:
>
>     if not issubclass(cls, members[0]):
>        raise TypeError(...)

My thought for moving _convert to the metaclass was that it didn't make much sense for it to be accessible through a member. Could you elaborate on how mix-ins come into play?

> While we're making that change we can also check that members is not empty and issue a friendlier error message.

I don't quite follow, what would members be in this case?

> We can also rename _convert to _convert_ in 3.8, but we'll need to have _convert also on the metaclass and have it trigger a warning that _convert_ is now the right way, and _convert will go away in 3.9.

Sounds good.

----------

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

From report at bugs.python.org  Sat Sep  1 06:05:52 2018
From: report at bugs.python.org (Zyg)
Date: Sat, 01 Sep 2018 10:05:52 +0000
Subject: [issue34562] cannot install versions 3.6.5+ on Windows
Message-ID: <1535796351.86.0.56676864532.issue34562@psf.upfronthosting.co.za>


New submission from Zyg <zclips at gmail.com>:

Hi. 
I tried to unsuccessfully install 3.7.0 and 3.6.5. The error I received was 0x80072f7d unspecified error. Searching the internet and turning off my firewall didn't help. Then I tried installing 3.4.4, it worked.

----------
components: Windows
files: Python 3.7.0 (32-bit)_20180901123914.log
messages: 324461
nosy: Zyg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: cannot install versions 3.6.5+ on Windows
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47777/Python 3.7.0 (32-bit)_20180901123914.log

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

From report at bugs.python.org  Sat Sep  1 06:18:13 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 01 Sep 2018 10:18:13 +0000
Subject: [issue34499] Extend registering of single-dispatch functions to
 parametrized generic pseudo-types
In-Reply-To: <1535200728.53.0.56676864532.issue34499@psf.upfronthosting.co.za>
Message-ID: <1535797093.95.0.56676864532.issue34499@psf.upfronthosting.co.za>


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

TBH, I don't like this idea. Consider this situation:

    @singledispatch
    def what(x: Iterable) -> None:
        print('general case')

    @what.register
    def _(x: Sequence[int]) -> None:
        print('special case')

    what(['is', 'going', 'on'])  # special case?

Even if you put in the docs that variables are erased etc. people will assume type arguments mean something unless rejected by `singledispatch`. The behaviour you propose can cause confusion.

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

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

From report at bugs.python.org  Sat Sep  1 08:24:45 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Sep 2018 12:24:45 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1535490860.43.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <ebb66e1b-3e15-f53a-323a-09b9bf907866@felt.demon.nl>


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

On 28/08/2018 23:14, STINNER Victor wrote:
> STINNER Victor <vstinner at redhat.com> added the comment:
>
>> Can we backport this to 3.7 at least?
I am the AIX(tools) Michael, Michael O is the HP-UX Michael :p

So I was not the one asking. IMHO - as the PEP was new, if I understood
correctly, in 3.7 - would be "nice" to see it back ported.

However, like you - my goal is to get the tests passing on master, and
worry about backport later.
> My policy is to focus on the master branch to support a new platform. Then add a buildbot and find a core developer to maintain this platform. See the PEP 11 for details.
>
> I would prefer to see a full test suite passing before discussing which changes should or should not be backported.
>
> I would also prefer to first see a more general discussion about who is going to support HP-UX.
>
> IMHO HP-UX is not officially supported today. My list of supported platforms:
> https://pythondev.readthedocs.io/cpython.html#supported-platforms
>
> See the test_utf8_mode now pass on HP-UX, I close the issue. Please open more specific issues for other failures. You might open a meta issue to track all HP-UX issues.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34403>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Sep  1 10:14:02 2018
From: report at bugs.python.org (Lorenz Mende)
Date: Sat, 01 Sep 2018 14:14:02 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535811242.24.0.56676864532.issue34200@psf.upfronthosting.co.za>


Lorenz Mende <lorenz.mende at gmail.com> added the comment:

I was able to reproduce the issue with Win 10, current cpython @master.
All sequential test runs are good.
With parallel execution a race condition comes up, as Victor already mentioned.

I was able to track the issue to the teardown function of the TestCase
In parallel the cleanup of the modules crashed the other tests.

line 57: support.modules_cleanup(*self.modules_before)

Is it possible to manage the cleanup differently?

----------
nosy: +LorenzMende

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

From report at bugs.python.org  Sat Sep  1 12:52:43 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Sat, 01 Sep 2018 16:52:43 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
Message-ID: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>


New submission from Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com>:

the bug is reproduced on big multiprocessing.Process output
when the size of the output gets bigger than signed int the value becomes negative, thus
```            
assert left > 0
```
in multiprocessing/connection.py:337 raises an exception like the following

```
Traceback (most recent call last):
  File "D:\GitHub\cpython\lib\threading.py", line 917, in _bootstrap_inner
    self.run()
  File "D:\GitHub\cpython\lib\threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "D:\GitHub\cpython\lib\multiprocessing\pool.py", line 470, in _handle_results
    task = get()
  File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 318, in _recv_bytes
    return self._get_more_data(ov, maxsize)
  File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 337, in _get_more_data
    assert left > 0
AssertionError
```


this assert looks invalid in this case because in C code the left value is DWORD (unsigned long), which cannot be negative by definition.

----------
components: Library (Lib)
files: invalid_assert_bug_reproduce.py
messages: 324465
nosy: Oleksandr Buchkovskyi
priority: normal
severity: normal
status: open
title: invalid assert on big output of multiprocessing.Process
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47778/invalid_assert_bug_reproduce.py

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

From report at bugs.python.org  Sat Sep  1 12:53:52 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Sep 2018 16:53:52 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1535820832.89.0.56676864532.issue34563@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  1 13:03:21 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Sat, 01 Sep 2018 17:03:21 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1535821401.83.0.56676864532.issue34563@psf.upfronthosting.co.za>


Change by Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com>:


----------
pull_requests: +8493

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

From report at bugs.python.org  Sat Sep  1 13:15:13 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Sat, 01 Sep 2018 17:15:13 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1535822113.9.0.56676864532.issue34563@psf.upfronthosting.co.za>


Change by Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com>:


----------
pull_requests: +8494

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

From report at bugs.python.org  Sat Sep  1 13:38:07 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 01 Sep 2018 17:38:07 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535823487.91.0.56676864532.issue34282@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

On 09/01/2018 01:21 AM, orlnub123 wrote:
> On 08/31/2018 03:01 ethan.furman wrote:

>> For versions 3.6 and 3.7 the solution is to modify the shadow check at
>> line 236 so only DynamicClassAttributes are /not/ shadowed (meaning
>> the _convert method would be shadowed by an _convert member).
> 
> Doing that might not be backwards-compatible. An enum with a subclassed
> behavior and member with the same name would shadow the behavior in
> favor of the member with the change. I propose adding an extra if
> statement under it that sets the member if it's named _convert and the
> _convert method on the class belongs to Enum (so it's not a behavior).

Fixing bugs is often not backwards-compatible.  ;)  I think the number
of affected people here will be low, though, because anybody who had an
_convert member should have noticed that they couldn't use it.
 
>> For 3.8 we can move _convert to the metaclass: I wasn't originally
>> supportive of this idea, but I can see it being useful for other Enum
>> mix-ins such as str.  However, I will want to include a check that
>> such a mix-in is there -- probably by checking that the Enum type is a
>> subclass of the first member's type... something like:
>>
>>      if not issubclass(cls, members[0]):
>>         raise TypeError(...)
> 
> My thought for moving _convert to the metaclass was that it didn't make
> much sense for it to be accessible through a member. Could you
> elaborate on how mix-ins come into play?

Blocking access through the member is a low priority.  For example,
originally Enum members were not available from each other (so
Color.Red.Blue didn't work), but that made accessing Color.Red _very_
slow.  The fix for the slow made it so Color.Red.Blue now "works",
although it is not recommended.

Also, moving _convert to the metaclass means it is now available on Enum,
Flag, and IntFlag, and every user-defined non-IntEnum class where it
wasn't before.  (This part will be in 3.8.)

The reason _convert exists at all is to be able to convert sets of global
constants into a drop-in replacement Enum, but that is only possible if
the drop-in Enum is compatible with the values being replaced -- so if
the values are integers (such as in the re module) then the replacement
Enum must be an IntEnum; if they were strings, then the replacement Enum
must be a StrEnum -- and the two cannot be mixed.

>> While we're making that change we can also check that members is not
>> empty and issue a friendlier error message.
> 
> I don't quite follow, what would members be in this case?

_convert is given a list of potential objects and a filter function to
select the ones to keep -- it is possible, most likely due to a bug in
user code, that the incoming list of objects is empty, or the filter
discards all of them, leaving members empty.

----------

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

From report at bugs.python.org  Sat Sep  1 13:42:03 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 01 Sep 2018 17:42:03 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535823723.49.0.56676864532.issue34200@psf.upfronthosting.co.za>


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

Maybe I'm missing something, but who is racing whom in this case? All the examples people have shared are simply running the test module directly which means there's no parallelism in the execution of the test runner with other tests. Does unittest.main() randomize the order and it's a sequence issue more than a concurrency issue?

For instance, Lorenz may have tracked this issue down to cleanup, but each of those test methods should have been run sequentially, meaning that the tearDown() method would have been called after every execution of a test with no concurrency going on.

And the temp modules for the tests are put in a directory created using tempfile.mkdtemp() so that should prevent test methods stomping on each other.

Perhaps we need to improve the failure messages at this point in the tests to get more clues as to the state of things when the failures occur?

----------

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

From report at bugs.python.org  Sat Sep  1 17:37:41 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 01 Sep 2018 21:37:41 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1535837861.83.0.56676864532.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

The attached runstack.py models the relevant parts of timsort's current merge_collapse and the proposed 2-merge.  Barring conceptual or coding errors, they appear to behave much the same with respect to "total cost", with no clear overall winner.  Of course cases can be constructed to make either look better.  As expected, twomerge requires fewer stack levels.  And they behave identically when all runs have the same length.

Note that the notion of "cost" here is simply that merging runs of lengths A and B always has cost A+B.  That should be viewed as worst case, where the rest of timsort finds nothing to exploit.

----------
Added file: https://bugs.python.org/file47779/runstack.py

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

From report at bugs.python.org  Sat Sep  1 18:14:01 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 01 Sep 2018 22:14:01 +0000
Subject: [issue34555] AF_VSOCK not unset because of wrong nesting
In-Reply-To: <1535728334.14.0.56676864532.issue34555@psf.upfronthosting.co.za>
Message-ID: <1535840041.27.0.56676864532.issue34555@psf.upfronthosting.co.za>


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


New changeset 2d7102e726e973ab2d307aa9748c7ec433677877 by Benjamin Peterson (Thomas Herzog) in branch 'master':
closes bpo-34555: Fix incorrectly nested test for HAVE_LINUX_VM_SOCKETS_H (GH-9016)
https://github.com/python/cpython/commit/2d7102e726e973ab2d307aa9748c7ec433677877


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Sep  1 18:14:10 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 01 Sep 2018 22:14:10 +0000
Subject: [issue34555] AF_VSOCK not unset because of wrong nesting
In-Reply-To: <1535728334.14.0.56676864532.issue34555@psf.upfronthosting.co.za>
Message-ID: <1535840050.34.0.56676864532.issue34555@psf.upfronthosting.co.za>


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


----------
pull_requests: +8495

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

From report at bugs.python.org  Sat Sep  1 18:30:48 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 01 Sep 2018 22:30:48 +0000
Subject: [issue34555] AF_VSOCK not unset because of wrong nesting
In-Reply-To: <1535728334.14.0.56676864532.issue34555@psf.upfronthosting.co.za>
Message-ID: <1535841048.82.0.56676864532.issue34555@psf.upfronthosting.co.za>


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


New changeset 4c532da1209bd20ba07f18448134f32ace8c54f7 by Miss Islington (bot) in branch '3.7':
closes bpo-34555: Fix incorrectly nested test for HAVE_LINUX_VM_SOCKETS_H (GH-9016)
https://github.com/python/cpython/commit/4c532da1209bd20ba07f18448134f32ace8c54f7


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

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

From report at bugs.python.org  Sat Sep  1 19:07:38 2018
From: report at bugs.python.org (orlnub123)
Date: Sat, 01 Sep 2018 23:07:38 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535843258.38.0.56676864532.issue34282@psf.upfronthosting.co.za>


orlnub123 <orlnub123 at gmail.com> added the comment:

> Fixing bugs is often not backwards-compatible.  ;)  I think the number
> of affected people here will be low, though, because anybody who had an
> _convert member should have noticed that they couldn't use it.

I think we had a misunderstanding, my proposal should be fully backwards-compatible. Maybe code can talk clearer than words? I'll attempt to turn it into a patch for 3.7 that can be backported to 3.6.

> Blocking access through the member is a low priority.  For example,
> originally Enum members were not available from each other (so
> Color.Red.Blue didn't work), but that made accessing Color.Red _very_
> slow.  The fix for the slow made it so Color.Red.Blue now "works",
> although it is not recommended.

That's honestly very interesting, thanks for the insight.

> Also, moving _convert to the metaclass means it is now available on Enum,
> Flag, and IntFlag, and every user-defined non-IntEnum class where it
> wasn't before.  (This part will be in 3.8.)

In my testings _convert has always been available to them as they all subclass Enum where it's defined. Was it originally meant to be defined on IntEnum?

> The reason _convert exists at all is to be able to convert sets of global
> constants into a drop-in replacement Enum, but that is only possible if
> the drop-in Enum is compatible with the values being replaced -- so if
> the values are integers (such as in the re module) then the replacement
> Enum must be an IntEnum; if they were strings, then the replacement Enum
> must be a StrEnum -- and the two cannot be mixed.

I understand and agree with the need for a check now however because of what I talked about above there should be a deprecation period similar to the one for renaming _convert. Would it be okay to add one?

> _convert is given a list of potential objects and a filter function to
> select the ones to keep -- it is possible, most likely due to a bug in
> user code, that the incoming list of objects is empty, or the filter
> discards all of them, leaving members empty.

My confusion came from the fact that it doesn't raise any errors currently if they're empty. Are you suggesting that it should raise one?

----------

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

From report at bugs.python.org  Sat Sep  1 19:47:44 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 01 Sep 2018 23:47:44 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535845664.78.0.56676864532.issue34282@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

orlnub123 wrote:
---------------
> In my testings _convert has always been available to them as they all
> subclass Enum where it's defined.

Wow, I really shouldn't check for things in the middle of the night.  On the bright side, no further changes are needed to _convert besides the rename.


orlnub123 wrote:
---------------
> I think we had a misunderstanding, my proposal should be fully
> backwards-compatible. Maybe code can talk clearer than words? I'll
> attempt to turn it into a patch for 3.7 that can be backported to 3.6.

Please do.  I'm curious to see what you come up with.

----------

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

From report at bugs.python.org  Sun Sep  2 04:02:24 2018
From: report at bugs.python.org (Lorenz Mende)
Date: Sun, 02 Sep 2018 08:02:24 +0000
Subject: [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1535875344.18.0.56676864532.issue23460@psf.upfronthosting.co.za>


Lorenz Mende <lorenz.mende at gmail.com> added the comment:

I want to bring this issue up again.
As the others correctly stated, either the documentation or the implementation of Decimal 'g' formatting is incorrect.

For floats the implementation suits the docu:
>>> '{:g}'.format(0.00001)
'1e-05'
For decimals:
>>> '{:g}'.format(decimal.Decimal('0.00001'))
'0.00001'

As there is a deviation between documentation and implementation, I advise to modify one of both.

----------
nosy: +LorenzMende

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

From report at bugs.python.org  Sun Sep  2 04:24:17 2018
From: report at bugs.python.org (Lorenz Mende)
Date: Sun, 02 Sep 2018 08:24:17 +0000
Subject: [issue23949] Number of elements display in error message is wrong
 while unpacking in traceback
In-Reply-To: <1429028937.85.0.30895290076.issue23949@psf.upfronthosting.co.za>
Message-ID: <1535876657.31.0.56676864532.issue23949@psf.upfronthosting.co.za>


Lorenz Mende <lorenz.mende at gmail.com> added the comment:

This issue shall be closed, as the solution is already on master with 4171bbe687904582329c7977d571686953275b45.

----------
nosy: +LorenzMende

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

From report at bugs.python.org  Sun Sep  2 04:26:28 2018
From: report at bugs.python.org (ron)
Date: Sun, 02 Sep 2018 08:26:28 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535876788.67.0.56676864532.issue34529@psf.upfronthosting.co.za>


ron <ron at mailinator.com> added the comment:

Well... when handling GBs of data - it's preferred to generate the file directly in the required format rather than doing conversions. 

The new line is a format... protocols don't matter here...
I still think the library should allow the user to create this format directly.

Lets get out of the scope of Google or others... The new line is a great format it allows you to take a "row" in the middle of the file and see it. You don't need to read 1gb file into parser in order to see it you can use copy 1 row... We are adopting this format for all our jsons, so it would be nice to get the service directly from the library.

----------

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

From report at bugs.python.org  Sun Sep  2 04:26:40 2018
From: report at bugs.python.org (Lorenz Mende)
Date: Sun, 02 Sep 2018 08:26:40 +0000
Subject: [issue5038] urrlib2/httplib doesn't reset file position between
 requests
In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>
Message-ID: <1535876800.72.0.56676864532.issue5038@psf.upfronthosting.co.za>


Lorenz Mende <lorenz.mende at gmail.com> added the comment:

Issue shall be closed, as no reproduction code is provided.
No patch provided and no comments since 2015.

----------
nosy: +LorenzMende

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

From report at bugs.python.org  Sun Sep  2 05:09:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Sep 2018 09:09:42 +0000
Subject: [issue23949] Number of elements display in error message is wrong
 while unpacking in traceback
In-Reply-To: <1429028937.85.0.30895290076.issue23949@psf.upfronthosting.co.za>
Message-ID: <1535879382.97.0.56676864532.issue23949@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  2 09:32:33 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 02 Sep 2018 13:32:33 +0000
Subject: [issue5038] urrlib2/httplib doesn't reset file position between
 requests
In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>
Message-ID: <1535895153.15.0.56676864532.issue5038@psf.upfronthosting.co.za>


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

Here is a demonstration script in case it helps. I haven?t tested it with versions before Python 2.6.

Older versions send ?Content-Length: 11?, but leave the server hanging trying to read the data. Newer versions (I presume since Issue 12319, 3.6+) send a valid HTTP 1.1 chunked request, but with empty data.

----------
Added file: https://bugs.python.org/file47780/auth-mmap.py

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

From report at bugs.python.org  Sun Sep  2 09:46:28 2018
From: report at bugs.python.org (orlnub123)
Date: Sun, 02 Sep 2018 13:46:28 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535895988.76.0.56676864532.issue34282@psf.upfronthosting.co.za>


Change by orlnub123 <orlnub123 at gmail.com>:


----------
pull_requests: +8496

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

From report at bugs.python.org  Sun Sep  2 10:19:16 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 02 Sep 2018 14:19:16 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535897956.66.0.56676864532.issue34200@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Since my buildbot has been infected with this bug, I took some time to hunt it out.  It turns out that issue is caused by an internal import triggered by the open() function (at least on Windows).

A recent change to the interpreter (commit 9e4994d) changed the order of internal imports wrt file encodings so the default encoding for text files triggers a walking of sys.path thus seeing an incomplete test tree.

The reason being that the path for the test tree is added to sys.path prior to it being completely flushed out.  In theory this should not be a problem due to mtimes, but it seems that the all the additions occur within the time resolution of the directory's mtime.

A quick fix for how internal imports happen *now* is:

@@ -81,7 +81,7 @@ class TestPkg(unittest.TestCase):
             if contents is None:
                 os.mkdir(fullname)
             else:
-                f = open(fullname, "w")
+                f = open(fullname, "w", encoding="utf-8")
                 f.write(contents)
                 if contents and contents[-1] != '\n':
                     f.write('\n')

however, to prevent further changes to internal imports cauing further problems, the following seems to be prudent:

@@ -70,7 +70,6 @@ class TestPkg(unittest.TestCase):

     def mkhier(self, descr):
         root = tempfile.mkdtemp()
-        sys.path.insert(0, root)
         if not os.path.isdir(root):
             os.mkdir(root)
         for name, contents in descr:
@@ -86,6 +85,7 @@ class TestPkg(unittest.TestCase):
                 if contents and contents[-1] != '\n':
                     f.write('\n')
                 f.close()
+        sys.path.insert(0, root)
         self.root = root
         # package name is the name of the first item
         self.pkgname = descr[0][0]

----------
nosy: +jkloth

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

From report at bugs.python.org  Sun Sep  2 11:17:31 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 02 Sep 2018 15:17:31 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1535901451.57.0.56676864532.issue34284@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

Also happens for some objects in the `_tkinter` module:
>>> _tkinter.TkttType.__new__(_tkinter.TkttType)
Traceback (most recent call last):
  File "<pyshell#126>", line 1, in <module>
    _tkinter.TkttType.__new__(_tkinter.TkttType)
TypeError: object.__new__(_tkinter.tktimertoken) is not safe, use _tkinter.tktimertoken.__new__()
>>> _tkinter.Tcl_Obj.__new__(_tkinter.Tcl_Obj)
Traceback (most recent call last):
  File "<pyshell#127>", line 1, in <module>
    _tkinter.Tcl_Obj.__new__(_tkinter.Tcl_Obj)
TypeError: object.__new__(_tkinter.Tcl_Obj) is not safe, use _tkinter.Tcl_Obj.__new__()
>>> _tkinter.TkappType.__new__(_tkinter.TkappType)
Traceback (most recent call last):
  File "<pyshell#128>", line 1, in <module>
    _tkinter.TkappType.__new__(_tkinter.TkappType)
TypeError: object.__new__(_tkinter.tkapp) is not safe, use _tkinter.tkapp.__new__()

----------

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

From report at bugs.python.org  Sun Sep  2 12:16:15 2018
From: report at bugs.python.org (Windson Yang)
Date: Sun, 02 Sep 2018 16:16:15 +0000
Subject: [issue34552] Clarify built-in types comparisons
In-Reply-To: <1535693872.67.0.56676864532.issue34552@psf.upfronthosting.co.za>
Message-ID: <1535904975.2.0.56676864532.issue34552@psf.upfronthosting.co.za>


Change by Windson Yang <wiwindson at gmail.com>:


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

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

From report at bugs.python.org  Sun Sep  2 12:22:35 2018
From: report at bugs.python.org (Windson Yang)
Date: Sun, 02 Sep 2018 16:22:35 +0000
Subject: [issue29750] smtplib doesn't handle unicode passwords
In-Reply-To: <1488919224.48.0.0966376973087.issue29750@psf.upfronthosting.co.za>
Message-ID: <1535905355.47.0.56676864532.issue29750@psf.upfronthosting.co.za>


Windson Yang <wiwindson at gmail.com> added the comment:

I added a pitch to support utf-8.

----------

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

From report at bugs.python.org  Sun Sep  2 12:47:12 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 02 Sep 2018 16:47:12 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1535906832.77.0.56676864532.issue18307@psf.upfronthosting.co.za>


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

Serhiy's analysis sounds right to me - for precompiled bytecode files, we really want co_filename to reflect the import time filename *not* the compile time filename.

While zipimport is one way to get the compile time and import time paths to differ, there are others:

- move an existing directory to another location
- copy a directory tree to a different machine
- move an implicitly cached pyc file to another location

Concrete example from a recent'ish build where I convert an implicitly cached pyc to a standalone one, but co_filename still references the original source file:

===========
$ ./python -c "import contextlib; print(contextlib.__file__); print(contextlib.contextmanager.__code__.co_filename)"
/home/ncoghlan/devel/cpython/Lib/contextlib.py
/home/ncoghlan/devel/cpython/Lib/contextlib.py
$ mkdir -p /tmp/example
$ cd /tmp/example
$ cp /home/ncoghlan/devel/cpython/Lib/__pycache__/contextlib.cpython-38.pyc contextlib.pyc
$ /home/ncoghlan/devel/cpython/python -c "import contextlib; print(contextlib.__file__); print(contextlib.contextmanager.__code__.co_filename)"
/tmp/example/contextlib.pyc
/home/ncoghlan/devel/cpython/Lib/contextlib.py
===========

----------

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

From report at bugs.python.org  Sun Sep  2 14:23:40 2018
From: report at bugs.python.org (Tom Berry)
Date: Sun, 02 Sep 2018 18:23:40 +0000
Subject: [issue34564] Tutorial Section 2.1 Windows Installation Path Correction
Message-ID: <1535912620.22.0.56676864532.issue34564@psf.upfronthosting.co.za>


New submission from Tom Berry <tom.berryx at gmail.com>:

The listed installation location is incorrect in the 02 Sep 18 release of the tutorial. It shows the default install path as C:\python36 vice C:\Program Files\python37. 

This may be related to an installer issue, as installing single-user places the program in an entirely different directory. Changing the installer to default back to C:\python37 would remove the need to differentiate Program Files (x86) for a 32-bit installer, as well as Program Files\ for the 64-bit. 

Corrected Tutorial attached reflecting change FROM C:\python36 TO C:\Program Files\Python37.

----------
assignee: docs at python
components: Documentation
files: Tutorial_EDIT.pdf
messages: 324482
nosy: aperture, docs at python
priority: normal
severity: normal
status: open
title: Tutorial Section 2.1 Windows Installation Path Correction
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47781/Tutorial_EDIT.pdf

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

From report at bugs.python.org  Sun Sep  2 16:03:40 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Sun, 02 Sep 2018 20:03:40 +0000
Subject: [issue34565] Launcher does not validate major versions
Message-ID: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>


New submission from Brendan Gerrity <bgerrity at ucdavis.edu>:

When a version argument is passed to the launcher (e.g. `py -3.4` or `py -7.0`), contrary to the launcher help text, the major version isn't validated as 2 or 3.

----------
components: Windows
messages: 324483
nosy: bgerrity, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Launcher does not validate major versions
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep  2 17:54:50 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Sun, 02 Sep 2018 21:54:50 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1535925290.89.0.56676864532.issue34565@psf.upfronthosting.co.za>


Change by Brendan Gerrity <bgerrity at ucdavis.edu>:


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

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

From report at bugs.python.org  Sun Sep  2 19:27:59 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 02 Sep 2018 23:27:59 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535564240.55.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <20180902232752.GS27312@ando.pearwood.info>


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

I've tried running this code in Python 3.6:

from _struct import Struct
for i in range(100000):
    L = [Struct.__new__(Struct) for j in range(1000)]
    for s in L:
        try:
            x = s.pack_into(bytearray())
        except SystemError:
            pass

I've run it 6 times, for a total of 600 million calls to Struct.__new__ 
and pack_into, and I cannot reproduce any crash or segfault. An 
exception (SystemError) is the correct behaviour.

Is anyone able to try it under Python 3.7?

Unless somebody is able to demonstrate a segfault or core dump, or 
otherwise demonstrate a problem with the C code, I think this ticket 
ought to be closed.

----------

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

From report at bugs.python.org  Sun Sep  2 21:44:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:44:21 +0000
Subject: [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535939061.17.0.56676864532.issue34500@psf.upfronthosting.co.za>


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

The change to Tools/scripts/diff.py us effectively a backport of the the patch merged for #7582. The git log  labels it as a2637729f23dc993e820fd92f0d1759ad714c9b2.

The change to Doc/library/difflib.rst does not apply to current 3.x as the test code is no longer present.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sun Sep  2 21:48:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:48:17 +0000
Subject: [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535939297.39.0.56676864532.issue34500@psf.upfronthosting.co.za>


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


New changeset 30af2e737aad427d4da97f8dadeeecff6c2b28f5 by Terry Jan Reedy (Micka?l Schoentgen) in branch '2.7':
bpo-34500: Fix ResourceWarning in difflib.py (GH-8926)
https://github.com/python/cpython/commit/30af2e737aad427d4da97f8dadeeecff6c2b28f5


----------

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

From report at bugs.python.org  Sun Sep  2 21:50:50 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:50:50 +0000
Subject: [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535939450.06.0.56676864532.issue34500@psf.upfronthosting.co.za>


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

Using 'with open' is now standard.  Thanks for the update.
In the message above, /us/is/.

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

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

From report at bugs.python.org  Sun Sep  2 21:59:52 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:59:52 +0000
Subject: [issue34532] Windows launcher exits with error after listing
 available versions
In-Reply-To: <1535476358.72.0.56676864532.issue34532@psf.upfronthosting.co.za>
Message-ID: <1535939992.01.0.56676864532.issue34532@psf.upfronthosting.co.za>


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

I shrank the title to fit in the space and clarified that it does list the versions (at least on my Win 10).  So this is invisible in normal use.

----------
nosy: +terry.reedy
title: Python launcher on Windows exits with error when requesting list of available versions -> Windows launcher exits with error after listing available versions

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

From report at bugs.python.org  Sun Sep  2 22:17:08 2018
From: report at bugs.python.org (Gabriel McManus)
Date: Mon, 03 Sep 2018 02:17:08 +0000
Subject: [issue29386] select.epoll.poll may behave differently if timeout = -1
 vs timeout = None
In-Reply-To: <1485671321.44.0.0475790676768.issue29386@psf.upfronthosting.co.za>
Message-ID: <1535941028.41.0.56676864532.issue29386@psf.upfronthosting.co.za>


Gabriel McManus <gmcmanus at gmail.com> added the comment:

I don't know of any other OS that implements epoll, so this is issue is likely no longer a problem. Although it is strange to convert -1 to -1000 (as though from seconds to milliseconds), it may not be worth changing.

----------

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

From report at bugs.python.org  Sun Sep  2 23:47:10 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 03 Sep 2018 03:47:10 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1535946430.31.0.56676864532.issue34486@psf.upfronthosting.co.za>


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

It looks to me pure Python implementation could not handle such cases. Put aside other possible bugs, threading.Condition.wait re-acquire the lock using threading.Condition._acquire_restore which could be interrupted and not able to acquire the lock. So it seems in any way using Pure Python, it's not possible to guarantee the lock is acquired.

----------

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

From report at bugs.python.org  Mon Sep  3 00:20:41 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 03 Sep 2018 04:20:41 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1535948441.63.0.56676864532.issue34563@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep  3 00:22:19 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 03 Sep 2018 04:22:19 +0000
Subject: [issue34505] urllib2 fails for proxy credentials that contains a '/'
 character
In-Reply-To: <1535246664.68.0.56676864532.issue34505@psf.upfronthosting.co.za>
Message-ID: <1535948539.14.0.56676864532.issue34505@psf.upfronthosting.co.za>


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


----------
type: crash -> behavior

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

From report at bugs.python.org  Mon Sep  3 00:25:45 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 04:25:45 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535948745.06.0.56676864532.issue34535@psf.upfronthosting.co.za>


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

Another possibility might be to not use the Windows timeout clock, at least not for short timeouts.  The following shows that tk does about 970 1 millesecond timeouts in 1 second (on my machine).
---
import tkinter as tk

root = tk.Tk()
cbid = None
cbcount = 0

def cb():
    global cbid, cbcount
    cbcount += 1
    cbid = root.after(1, cb)

def cbcancel():
    print(cbcount)
    root.after_cancel(cbid)

root.after(1000, cbcancel)
cbid = root.after(1, cb)
root.mainloop()
---

Here is a proof-of-concept queue-get-with-timeout function with sub-millesecond resolution.
---
import tkinter as tk
from queue import Queue, Empty
from time import perf_counter

q = Queue()
fails = 0
value = '<raise Empty>'

def qcb():
    try:
        global value
        value = q.get(block=False)
    except Empty:
        global fails
        fails += 1
        if perf_counter() < stop:
            root.after(0, qcb)
            return
    root.destroy()

def qget_to(timeout):
    global root, stop
    root = tk.Tk()
    root.withdraw()
    stop = perf_counter() + timeout
    qid = root.after(0, qcb)
    #q.put(1)
    root.mainloop()
    print('failures:', fails, 'value:', value)

qget_to(.001)
---

With the put commented out, there are 27 fails (on my machine).  When a value is already available, there are none.  The loop could be parameterized to repeatedly call the no-block version of any similar function.  Large enough time-outs could be partially fulfilled using the system timeout function.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Mon Sep  3 00:31:26 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 03 Sep 2018 04:31:26 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1535949086.49.0.56676864532.issue23855@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

The suggested patch is not acceptable: MemoryError should be raised in the unlikely event of a malloc() failure, there's a missing call to MsiCloseHandle(), the use of tabs violates PEP 7, and there's a blatant syntax error.

----------
nosy: +ZackerySpytz
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/issue23855>
_______________________________________

From report at bugs.python.org  Mon Sep  3 00:32:51 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 03 Sep 2018 04:32:51 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1535949171.22.0.56676864532.issue23855@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8499
stage:  -> patch review

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

From report at bugs.python.org  Mon Sep  3 01:26:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 05:26:11 +0000
Subject: [issue29386] select.epoll.poll may behave differently if timeout = -1
 vs timeout = None
In-Reply-To: <1485671321.44.0.0475790676768.issue29386@psf.upfronthosting.co.za>
Message-ID: <1535952371.65.0.56676864532.issue29386@psf.upfronthosting.co.za>


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

See similar issue31334. It may be worth to make the code similar. Only -1 is documented as a special timeout value for epoll_wait().

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

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

From report at bugs.python.org  Mon Sep  3 01:34:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 05:34:23 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1535952863.88.0.56676864532.issue34565@psf.upfronthosting.co.za>


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

What is wrong with supporting version 7.0?

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

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

From report at bugs.python.org  Mon Sep  3 01:36:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 05:36:04 +0000
Subject: [issue34532] Windows launcher exits with error after listing
 available versions
In-Reply-To: <1535476358.72.0.56676864532.issue34532@psf.upfronthosting.co.za>
Message-ID: <1535952964.72.0.56676864532.issue34532@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch

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

From report at bugs.python.org  Mon Sep  3 01:36:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 05:36:23 +0000
Subject: [issue34532] Windows launcher exits with error after listing
 available versions
In-Reply-To: <1535476358.72.0.56676864532.issue34532@psf.upfronthosting.co.za>
Message-ID: <1535952983.28.0.56676864532.issue34532@psf.upfronthosting.co.za>


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


----------
keywords: +easy (C)

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

From report at bugs.python.org  Mon Sep  3 01:54:34 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Mon, 03 Sep 2018 05:54:34 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1535954074.97.0.56676864532.issue34565@psf.upfronthosting.co.za>


Brendan Gerrity <bgerrity at ucdavis.edu> added the comment:

The function's comment says otherwise; I just noticed when I was messing with 34565. Supporting arbitrary major versions makes the -0 arg ambiguous so alternatively that could be the special case?

----------

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

From report at bugs.python.org  Mon Sep  3 02:20:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 06:20:26 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1535955626.9.0.56676864532.issue34565@psf.upfronthosting.co.za>


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

Wouldn't be better to fix a comment?

----------

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

From report at bugs.python.org  Mon Sep  3 02:37:51 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Mon, 03 Sep 2018 06:37:51 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1535956671.81.0.56676864532.issue34563@psf.upfronthosting.co.za>


Change by Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep  3 02:40:26 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Mon, 03 Sep 2018 06:40:26 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1535956826.59.0.56676864532.issue34563@psf.upfronthosting.co.za>


Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com> added the comment:

By bigger than signed int i meant bigger than positive signed int

----------

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

From report at bugs.python.org  Mon Sep  3 03:06:18 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 03 Sep 2018 07:06:18 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535958378.83.0.56676864532.issue34543@psf.upfronthosting.co.za>


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

IMHO SystemError is the wrong exception, that exception is primarily used to signal implementation errors.

BTW. I can reproduce crashes in a couple of runs of your scriptlet:

Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from _struct import Struct
>>> for i in range(100000):
...     L = [Struct.__new__(Struct) for j in range(1000)]
...     for s in L:
...         try:
...             x = s.pack_into(bytearray())
...         except SystemError:
...             pass
... 
Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
TypeError: 'code' object cannot be interpreted as an integer
>>>             
>>> from _struct import Struct
>>> for i in range(100000):
...     L = [Struct.__new__(Struct) for j in range(1000)]
...     for s in L:
...         try:
...             x = s.pack_into(bytearray())
...         except SystemError:
...             pass
... 
Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
TypeError: 'traceback' object cannot be interpreted as an integer
>>> 
>>> 
>>> 
>>> from _struct import Struct
>>> for i in range(100000):
...     L = [Struct.__new__(Struct) for j in range(1000)]
...     for s in L:
...         try:
...             x = s.pack_into(bytearray())
...         except SystemError:
...             pass
... 
Segmentation fault: 11

----------

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

From report at bugs.python.org  Mon Sep  3 03:10:11 2018
From: report at bugs.python.org (nilanjan roy)
Date: Mon, 03 Sep 2018 07:10:11 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1535958611.61.0.56676864532.issue34461@psf.upfronthosting.co.za>


nilanjan roy <roy.nilanjan at gmail.com> added the comment:

@scoder: *xml* package organization have little confusion 

1. Current xml have exposed all the sub-packages from *__all__* scope from the initializer - so there are possibilities to write code from script 
a. *import xml as x* or *import xml.somepackage as x* => which is also possible even if I do not declare the sub-packages from *__all__* scope
of an initializer
b. as all the subpackages are available in xml initialzer scope- so this is allowed to developer to write *from xml import ** - but this flexibility will not work(which is contradictory)  as each of sub-package initializer doesn't have any inclusion(which i have included in PR) 

Regards,

----------

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

From report at bugs.python.org  Mon Sep  3 03:27:40 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Mon, 03 Sep 2018 07:27:40 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1535959660.53.0.56676864532.issue34565@psf.upfronthosting.co.za>


Brendan Gerrity <bgerrity at ucdavis.edu> added the comment:

Added a commit that just changes the comment.

----------

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

From report at bugs.python.org  Mon Sep  3 03:30:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 07:30:07 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1535959807.29.0.56676864532.issue34461@psf.upfronthosting.co.za>


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

I concur with Stefan. Not all users of ElementTree need to import ElementInclude, ElementPath and deprecated cElementTree. If you need ElementInclude or ElementPath, it is better to specify this explicitly. The star import is not recommended in general case (you even can't use it in a local scope in Python 3). The valid use of it is with modules that define a lot of names and are specially designed for this (like tkinter or turtle) and in an interactive session.

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

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

From report at bugs.python.org  Mon Sep  3 04:44:27 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Mon, 03 Sep 2018 08:44:27 +0000
Subject: [issue34532] Windows launcher exits with error after listing
 available versions
In-Reply-To: <1535476358.72.0.56676864532.issue34532@psf.upfronthosting.co.za>
Message-ID: <1535964267.15.0.56676864532.issue34532@psf.upfronthosting.co.za>


Change by Brendan Gerrity <bgerrity at ucdavis.edu>:


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

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

From report at bugs.python.org  Mon Sep  3 04:58:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 08:58:24 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535965104.86.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I am the AIX(tools) Michael, Michael O is the HP-UX Michael :p

Oh, I didn't notice that you two have the same first name :-)

> So I was not the one asking. IMHO - as the PEP was new, if I understood
correctly, in 3.7 - would be "nice" to see it back ported. However, like you - my goal is to get the tests passing on master, and
worry about backport later.

*My position didn't change since my last comment, same position for AIX and HP-UX: msg324289. I also updated my website to write down this policy:
https://pythondev.readthedocs.io/cpython.html#i-want-cpython-to-support-my-platform

By the way, please don't comment issues that are closed.

----------

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

From report at bugs.python.org  Mon Sep  3 04:59:47 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 Sep 2018 08:59:47 +0000
Subject: [issue34505] urllib2 fails for proxy credentials that contains a '/'
 character
In-Reply-To: <1535246664.68.0.56676864532.issue34505@psf.upfronthosting.co.za>
Message-ID: <1535965187.6.0.56676864532.issue34505@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add some more detail on the problem and maybe a small script explaining what you expect and what the current output is? Clicking on the pinterest link gives no details.

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep  3 05:03:46 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 Sep 2018 09:03:46 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1535965426.09.0.56676864532.issue34536@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep  3 05:13:24 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 03 Sep 2018 09:13:24 +0000
Subject: [issue29386] select.epoll.poll may behave differently if timeout = -1
 vs timeout = None
In-Reply-To: <1485671321.44.0.0475790676768.issue29386@psf.upfronthosting.co.za>
Message-ID: <1535966004.79.0.56676864532.issue29386@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep  3 06:22:54 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 03 Sep 2018 10:22:54 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535970174.87.0.56676864532.issue34543@psf.upfronthosting.co.za>


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

Thanks for confirming the seg fault. I've changed this to a crasher.

Should we change the exception to RuntimeError?

----------
components: +Library (Lib) -Extension Modules
type: behavior -> crash

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

From report at bugs.python.org  Mon Sep  3 07:05:03 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 03 Sep 2018 11:05:03 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535972703.24.0.56676864532.issue34543@psf.upfronthosting.co.za>


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

It's not as easy as that, the SystemError in the original report is caused by invalid use of a C-API due to partial initialisation of an _struct.Struct instance.

The solution is likely two-fold:

1) Ensure that __new__ fully initialises the fields in de C struct to some value

2) (Possibly) check that fields in the C structure have a sane value before using them. This part can have a measurable performance cost, and it would be nicer to avoid this by picking smart values in (1). 

The most important bit is the first step, even if that keeps raising SystemError when only calling Struct.__new__ because this avoid crashing the interpreter.

----------

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

From report at bugs.python.org  Mon Sep  3 07:27:22 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 03 Sep 2018 11:27:22 +0000
Subject: [issue34499] Extend registering of single-dispatch functions to
 parametrized generic pseudo-types
In-Reply-To: <1535200728.53.0.56676864532.issue34499@psf.upfronthosting.co.za>
Message-ID: <1535974042.36.0.56676864532.issue34499@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I agree with Ivan. This is a no go for parametrized pseudotypes.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Sep  3 07:58:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 11:58:12 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535975892.87.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8503

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

From report at bugs.python.org  Mon Sep  3 07:59:23 2018
From: report at bugs.python.org (DeKrain)
Date: Mon, 03 Sep 2018 11:59:23 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535975963.81.0.56676864532.issue34543@psf.upfronthosting.co.za>


DeKrain <dawidkrainski8 at gmail.com> added the comment:

I think we should leave 'Extension Modules' in components field, because implementation of struct module is really written in C.

----------

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

From report at bugs.python.org  Mon Sep  3 08:06:40 2018
From: report at bugs.python.org (Marcel Plch)
Date: Mon, 03 Sep 2018 12:06:40 +0000
Subject: [issue34566] pipe read sometimmes returns EOF but returncode is still
 None
Message-ID: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>


New submission from Marcel Plch <mplch at redhat.com>:

TL;DR: For reproducer, please see attached file and the end of this description for a runner script.

It seems that when pipe is being read it has a chance of returning EOF and not setting the return code.
This bug affects all (or at least a broad set of) architectures and is present in all versions. (2.7 and 3.8 were tested).
This bug is not reproducible when configured using --with-pydebug flag.
As a result, any code relying on proper setting of the returncode attribute might (and probably is going to) fail.
-----------
$ for i in $(seq 1 1000); do ./python script.py; done | grep poll | sort | uniq -c

Actual output:
630 output: '', return code: 0, pollstatus=0
370 output: '', return code: None, pollstatus=None

Expected output:
1000 output: '', return code: 0, pollstatus=0

----------
components: Library (Lib)
files: script.py
messages: 324508
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: pipe read sometimmes returns EOF but returncode is still None
versions: Python 3.8
Added file: https://bugs.python.org/file47782/script.py

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

From report at bugs.python.org  Mon Sep  3 08:16:18 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 03 Sep 2018 12:16:18 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535976978.29.0.56676864532.issue34543@psf.upfronthosting.co.za>


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

@DeKrain: I agree

----------
components: +Extension Modules -Library (Lib)

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

From report at bugs.python.org  Mon Sep  3 08:17:33 2018
From: report at bugs.python.org (Marcel Plch)
Date: Mon, 03 Sep 2018 12:17:33 +0000
Subject: [issue34566] pipe read sometimes returns EOF but returncode is still
 None
In-Reply-To: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>
Message-ID: <1535977053.99.0.56676864532.issue34566@psf.upfronthosting.co.za>


Marcel Plch <mplch at redhat.com> added the comment:

original downstream issue - https://bugzilla.redhat.com/show_bug.cgi?id=1623070

----------
title: pipe read sometimmes returns EOF but returncode is still None -> pipe read sometimes returns EOF but returncode is still None

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

From report at bugs.python.org  Mon Sep  3 08:19:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 12:19:24 +0000
Subject: [issue34566] pipe read sometimes returns EOF but returncode is still
 None
In-Reply-To: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>
Message-ID: <1535977164.03.0.56676864532.issue34566@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Sep  3 08:38:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 12:38:24 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535978304.53.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f01b2a1b84ee08df73a78cf1017eecf15e3cb995 by Victor Stinner in branch 'master':
bpo-34544: Fix setlocale() in pymain_read_conf() (GH-9041)
https://github.com/python/cpython/commit/f01b2a1b84ee08df73a78cf1017eecf15e3cb995


----------

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

From report at bugs.python.org  Mon Sep  3 08:38:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 12:38:24 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535978304.64.0.902498594338.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f01b2a1b84ee08df73a78cf1017eecf15e3cb995 by Victor Stinner in branch 'master':
bpo-34544: Fix setlocale() in pymain_read_conf() (GH-9041)
https://github.com/python/cpython/commit/f01b2a1b84ee08df73a78cf1017eecf15e3cb995


----------

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

From report at bugs.python.org  Mon Sep  3 08:44:39 2018
From: report at bugs.python.org (Vadim Pushtaev)
Date: Mon, 03 Sep 2018 12:44:39 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1535978679.57.0.56676864532.issue34284@psf.upfronthosting.co.za>


Vadim Pushtaev <pushtaev.vm at gmail.com> added the comment:

Also for `curses.panel.panel`:

>>> from curses.panel import panel
>>> panel.__new__(panel)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object.__new__(_curses_panel.panel) is not safe, use _curses_panel.panel.__new__()

----------

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

From report at bugs.python.org  Mon Sep  3 08:59:18 2018
From: report at bugs.python.org (Vijay)
Date: Mon, 03 Sep 2018 12:59:18 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1535979558.48.0.56676864532.issue34553@psf.upfronthosting.co.za>


Vijay <vijay.ramdass at gmail.com> added the comment:

Thanks for the inputs. i will check with pywin32 team.
is there any pywin32 link to raise the case. please share if you know.

----------

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

From report at bugs.python.org  Mon Sep  3 09:28:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 13:28:24 +0000
Subject: [issue34567] test.pythoninfo: dump interpreter _PyCoreConfig
Message-ID: <1535981304.49.0.56676864532.issue34567@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

test.pythoninfo should also dump the interpreter _PyCoreConfig. It would help to check if the C locale has been coerced for example.

----------
components: Tests
messages: 324515
nosy: vstinner
priority: normal
severity: normal
status: open
title: test.pythoninfo: dump interpreter _PyCoreConfig
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep  3 09:31:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 13:31:26 +0000
Subject: [issue34567] test.pythoninfo: dump interpreter _PyCoreConfig
In-Reply-To: <1535981304.49.0.56676864532.issue34567@psf.upfronthosting.co.za>
Message-ID: <1535981486.68.0.56676864532.issue34567@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Sep  3 09:32:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 13:32:58 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535981578.18.0.56676864532.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

My fix didn't work :-(

https://buildbot.python.org/all/#/builders/87/builds/1355

...
Fatal Python error: get_locale_encoding: failed to get the locale encoding: nl_langinfo(CODESET) failed
...

----------

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

From report at bugs.python.org  Mon Sep  3 09:41:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 Sep 2018 13:41:56 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535979558.48.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <CAAjsFLTUH0Z1eRTQrH_GiO99Y3aUk1u89C7K0XUY__OtHA6zUA@mail.gmail.com>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This might help : https://github.com/mhammond/pywin32/issues

Thanks
-- 

Regards,
Karthikeyan S

----------

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

From report at bugs.python.org  Mon Sep  3 09:47:34 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Mon, 03 Sep 2018 13:47:34 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
Message-ID: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck <pekka.klarck at gmail.com>:

= Introduction =

In Python 3.5 and 3.6 types defined in the typing module are instances of `type` and also subclasses of the "real" type they represent. For example, both `isinstance(typing.List, type)` and `issubclass(typing.List, list)` return true. In Python 3.7 the former returns false and the latter causes a TypeError. I could find anything related to these changes in the Python 3.7 release notes or from the documentation of the typing module.

I explain my use case and the problems these changes have caused below.

= Use case =

I'm implementing automatic argument conversion to Robot Framework, a generic open source test automation framework, based on function annotations. The idea is that if a user has defined a keyword like

    def example(arg: int):
        # ...

we can convert argument passed in plain text test data like

    Example    42

into the correct type automatically. For more details see this issue in our tracker:
https://github.com/robotframework/robotframework/issues/2890


= Problem 1 =

I have implemented converters for different types and use annotations to find out the expected type for each argument. To exclude non-type annotations, my code uses `isinstance(annotation, type)` but in Python 3.7 this excludes also types defined in the typing module.

I could apparently use `isinstance(annoation, (type, typing._GenericAlias))`, but touching private parts like is fragile and feels wrong in general.

= Problem 2 =

Each converter I've implemented is mapped to a certain type (e.g. `list`) and, when applicable, also to an abc (e.g. `collections.abc.MutableSequence`). When finding a correct converter for a certain type, the code uses an equivalent of `issubclass(type_, (converter.type, converter.abc))`. In Python 3.5 and 3.6 this works also if the used type is defined in the typing module but with Python 3.7 it causes a TypeError.

I guess I could handle the types in the typing module by explicitly mapping converters also to these types (e.g. `typing.List`) and then using something like `type_ is converter.typing`. The problem is that although it would work with types like `List`, it wouldn't work if types are used like `List[int]`.

----------
messages: 324518
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Types in `typing` not anymore instances of `type` or subclasses of "real" types

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

From report at bugs.python.org  Mon Sep  3 09:47:59 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 03 Sep 2018 13:47:59 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
Message-ID: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

+364      def _assert_values(self, values):
  +365          for obj in values:
  +366              with self.subTest(obj):
  +367                  interpreters.channel_send(self.cid, obj)
  +368                  got = interpreters.channel_recv(self.cid)
  +369
  +370                  self.assertEqual(got, obj)
  +371                  self.assertIs(type(got), type(obj))
  +372                  # XXX Check the following in the channel tests?
  +373                  #self.assertIsNot(got, obj)
  +374

  +395      def test_int(self):
  +396          self._assert_values(range(-1, 258))
  +397

The assert fails on -1 with:

======================================================================
FAIL: test_int (test.test__xxsubinterpreters.ShareableTypeTests) [-1]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/python3-3.8.0/Lib/test/test__xxsubinterpreters.py", line 371, in _assert_values
    self.assertEqual(got, obj)
AssertionError: 4294967295 != -1

Note that this value is the unsigned value for 32-bit int as -1

root at x066:[/data/prj/python/python3-3.8.0]grep 4294967295 /usr/include/sys/*.h
/usr/include/sys/limits.h:#define ULONG_MAX     (4294967295UL)
/usr/include/sys/limits.h:#define UINT_MAX      (4294967295U)
/usr/include/sys/stdint.h:#define UINT32_MAX    (4294967295U)

After quite a lot of "learning", I narrow the issue to:

 +1432  static int
 +1433  _long_shared(PyObject *obj, _PyCrossInterpreterData *data)
 +1434  {
 +1435      int64_t value = PyLong_AsLongLong(obj);
 +1436      if (value == -1 && PyErr_Occurred()) {
 +1437          if (PyErr_ExceptionMatches(PyExc_OverflowError)) {
 +1438              PyErr_SetString(PyExc_OverflowError, "try sending as bytes");
 +1439          }
 +1440          return -1;
 +1441      }
 +1442      data->data = (void *)value;
 +1443      data->obj = NULL;
 +1444      data->new_object = _new_long_object;
 +1445      data->free = NULL;
 +1446      return 0;
 +1447  }
 +1448

 +1426  static PyObject *
 +1427  _new_long_object(_PyCrossInterpreterData *data)
 +1428  {
 +1429      return PyLong_FromLongLong((int64_t)(data->data));
 +1430  }

The "value" is stored as a void data type, and the high-order 64-bits are zero. When it gets returned as a PyLong... it goes positive.

I do not dare touch anything here without some "mentoring".

Or, we change the test so that it knows it is in 32-bit mode, and compares with something else.

In short, "mentoring" requested.

p.s. not had time to test in 64-bit mode. Will post on that later.

----------
messages: 324519
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX - 32-bit mode

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

From report at bugs.python.org  Mon Sep  3 09:48:02 2018
From: report at bugs.python.org (Marcel Plch)
Date: Mon, 03 Sep 2018 13:48:02 +0000
Subject: [issue34566] pipe read sometimes returns EOF but returncode is still
 None
In-Reply-To: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>
Message-ID: <1535982482.0.0.56676864532.issue34566@psf.upfronthosting.co.za>


Change by Marcel Plch <mplch at redhat.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Mon Sep  3 09:50:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 13:50:12 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1535982612.89.0.56676864532.issue34569@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Mon Sep  3 09:51:17 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Mon, 03 Sep 2018 13:51:17 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1535982677.7.0.56676864532.issue34568@psf.upfronthosting.co.za>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

Basically I'd like to get answers to these two questions:

1. Are the changes deliberate and covered by the fact that typing is a provisional module, or could the old functionality be restored?

2. If we cannot get the old functionality back, is there some other way to reliable detect is an annotation a type defined in the typing module? This should cover both the `List` and `List[int]` cases.

----------

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

From report at bugs.python.org  Mon Sep  3 10:01:47 2018
From: report at bugs.python.org (Pablosky)
Date: Mon, 03 Sep 2018 14:01:47 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
Message-ID: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>


New submission from Pablosky <pawelhrycyk at gmail.com>:

Platform details:
Ubuntu 16.04 LTS (64 bit)
Python 2.7.12

I am using Robot framework environment for testing. It looks segmentation fault appears when there is a lot (like 20) of pybot (Robot Framework component) instances running in the system. When the crash appears single pybot instance is killed. Rest is fine.

It happens sporadically. Like 4% of pybot executions.

----------
components: ctypes
files: segfault.txt
messages: 324521
nosy: Pablosky
priority: normal
severity: normal
status: open
title: Segmentation fault in _PyType_Lookup
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47783/segfault.txt

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

From report at bugs.python.org  Mon Sep  3 10:51:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 14:51:28 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535986288.08.0.56676864532.issue34544@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Sep  3 11:05:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:05:23 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535987123.05.0.56676864532.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8ea09110d413829f71d979d8c7073008cb87fb03 by Victor Stinner in branch 'master':
_Py_CoerceLegacyLocale() restores LC_CTYPE on fail (GH-9044)
https://github.com/python/cpython/commit/8ea09110d413829f71d979d8c7073008cb87fb03


----------

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

From report at bugs.python.org  Mon Sep  3 11:06:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:06:42 +0000
Subject: [issue34567] test.pythoninfo: dump interpreter _PyCoreConfig
In-Reply-To: <1535981304.49.0.56676864532.issue34567@psf.upfronthosting.co.za>
Message-ID: <1535987202.66.0.56676864532.issue34567@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 2094c2bea4f79c31819994d8f0afa97ccc52cca8 by Victor Stinner in branch 'master':
bpo-34567: pythoninfo gets coreconfig (GH-9043)
https://github.com/python/cpython/commit/2094c2bea4f79c31819994d8f0afa97ccc52cca8


----------

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

From report at bugs.python.org  Mon Sep  3 11:10:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:10:17 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535987417.09.0.56676864532.issue34544@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8506

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

From report at bugs.python.org  Mon Sep  3 11:10:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:10:17 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535987417.18.0.665841612001.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8507

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

From report at bugs.python.org  Mon Sep  3 11:12:37 2018
From: report at bugs.python.org (mcdallas)
Date: Mon, 03 Sep 2018 15:12:37 +0000
Subject: [issue34571] help(hashlib.blake2b) causes RuntimeError in 3.7
Message-ID: <1535987557.8.0.56676864532.issue34571@psf.upfronthosting.co.za>


New submission from mcdallas <mcdallas at protonmail.com>:

$ python3.7                                                                       
Python 3.7.0 (default, Jul 23 2018, 20:22:55)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> help(hashlib.blake2b)
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 1996, in wrap_value
    value = eval(s, module_dict)
  File "<string>", line 1, in <module>
NameError: name '_blake2b' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 1999, in wrap_value
    value = eval(s, sys_module_dict)
  File "<string>", line 1, in <module>
NameError: name '_blake2b' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1895, in __call__
    self.help(request)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1954, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1674, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1667, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 386, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1237, in docclass
    signature = inspect.signature(object)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 3070, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2820, in from_callable
    follow_wrapper_chains=follow_wrapped)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2343, in _signature_from_callable
    return _signature_fromstr(sigcls, obj, text_sig)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2067, in _signature_fromstr
    p(name, default)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2037, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ast.py", line 262, in visit
    return visitor(node)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2024, in visit_Attribute
    return wrap_value(value)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2001, in wrap_value
    raise RuntimeError()
RuntimeError


same for blake2s

----------
components: Library (Lib)
messages: 324524
nosy: mcdallas
priority: normal
severity: normal
status: open
title: help(hashlib.blake2b) causes RuntimeError in 3.7
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep  3 11:17:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:17:35 +0000
Subject: [issue34571] help(hashlib.blake2b) causes RuntimeError in 3.7
In-Reply-To: <1535987557.8.0.56676864532.issue34571@psf.upfronthosting.co.za>
Message-ID: <1535987855.01.0.56676864532.issue34571@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Sep  3 11:21:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:21:04 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535988064.77.0.56676864532.issue34544@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8508

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

From report at bugs.python.org  Mon Sep  3 11:21:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 15:21:59 +0000
Subject: [issue34571] help(hashlib.blake2b) causes RuntimeError in 3.7
In-Reply-To: <1535987557.8.0.56676864532.issue34571@psf.upfronthosting.co.za>
Message-ID: <1535988119.5.0.56676864532.issue34571@psf.upfronthosting.co.za>


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

It should be fixed in issue33729.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> Hashlib/blake2* missing 'data' keyword argument

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

From report at bugs.python.org  Mon Sep  3 11:23:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 15:23:50 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1535988230.52.0.56676864532.issue34568@psf.upfronthosting.co.za>


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


----------
nosy: +gvanrossum, levkivskyi

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

From report at bugs.python.org  Mon Sep  3 11:24:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Sep 2018 15:24:03 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1535988243.84.0.56676864532.issue34568@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib)
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep  3 11:32:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:32:34 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535988754.74.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 73b00becbdd40f6a80cfa00abf1ae650a2b5e454 by Victor Stinner in branch 'master':
bpo-34544: pymain_read_conf() don't change LC_ALL (GH-9045)
https://github.com/python/cpython/commit/73b00becbdd40f6a80cfa00abf1ae650a2b5e454


----------

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

From report at bugs.python.org  Mon Sep  3 11:32:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:32:34 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535988754.82.0.902498594338.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 73b00becbdd40f6a80cfa00abf1ae650a2b5e454 by Victor Stinner in branch 'master':
bpo-34544: pymain_read_conf() don't change LC_ALL (GH-9045)
https://github.com/python/cpython/commit/73b00becbdd40f6a80cfa00abf1ae650a2b5e454


----------

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

From report at bugs.python.org  Mon Sep  3 11:33:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 15:33:35 +0000
Subject: [issue34567] test.pythoninfo: dump interpreter _PyCoreConfig
In-Reply-To: <1535981304.49.0.56676864532.issue34567@psf.upfronthosting.co.za>
Message-ID: <1535988815.12.0.56676864532.issue34567@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Sep  3 11:53:21 2018
From: report at bugs.python.org (Tim Burgess)
Date: Mon, 03 Sep 2018 15:53:21 +0000
Subject: [issue34572] C unpickling bypasses import thread safety
Message-ID: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>


New submission from Tim Burgess <ozburgess at gmail.com>:

Retrieving and using a module directly from sys.modules (from C in this case) leads to a race condition where the module may be importing on another thread but has not yet been initialised.  For slow filesystems or large modules (e.g. numpy) this seems to lead to easily reproducible errors (the attached code fails 100% of the time on my work machine - CentOS 7).

I believe they have to be in sys.modules during this phase due to the possibility of circular references.

importlib handles this carefully with locking, but _pickle.c bypasses all that, leading to issues with threaded codes that use pickling, e.g. dask/distributed.

----------
components: Extension Modules
files: reproducer_submit.py
messages: 324528
nosy: tjb900
priority: normal
severity: normal
status: open
title: C unpickling bypasses import thread safety
type: crash
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47784/reproducer_submit.py

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

From report at bugs.python.org  Mon Sep  3 11:55:43 2018
From: report at bugs.python.org (Grant Jenks)
Date: Mon, 03 Sep 2018 15:55:43 +0000
Subject: [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1535990143.6.0.56676864532.issue34549@psf.upfronthosting.co.za>


Change by Grant Jenks <grant.jenks at gmail.com>:


----------
nosy: +grantjenks

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

From report at bugs.python.org  Mon Sep  3 12:06:18 2018
From: report at bugs.python.org (Tim Burgess)
Date: Mon, 03 Sep 2018 16:06:18 +0000
Subject: [issue34572] C unpickling bypasses import thread safety
In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>
Message-ID: <1535990778.79.0.56676864532.issue34572@psf.upfronthosting.co.za>


Change by Tim Burgess <ozburgess at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep  3 12:39:15 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 03 Sep 2018 16:39:15 +0000
Subject: [issue34562] cannot install versions 3.6.5+ on Windows
In-Reply-To: <1535796351.86.0.56676864532.issue34562@psf.upfronthosting.co.za>
Message-ID: <1535992755.63.0.56676864532.issue34562@psf.upfronthosting.co.za>


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

It looks like you have some sort of network protection software that is not allowing the installer to download certain files.

Try running the installer with the "/layout [directory]" option to pre-download all the files you need from a machine that can access the internet, and then you can install optional components on any machine without needing network access.

----------

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

From report at bugs.python.org  Mon Sep  3 13:20:56 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 03 Sep 2018 17:20:56 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
In-Reply-To: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>
Message-ID: <1535995256.58.0.56676864532.issue34570@psf.upfronthosting.co.za>


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

Thanks for the report.
Is the place where it crashes always the same?
Could it be that your system is running out of resources, e.g. RAM?

----------
nosy: +scoder

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

From report at bugs.python.org  Mon Sep  3 13:50:04 2018
From: report at bugs.python.org (Lorenz Mende)
Date: Mon, 03 Sep 2018 17:50:04 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535997004.6.0.56676864532.issue34200@psf.upfronthosting.co.za>


Lorenz Mende <lorenz.mende at gmail.com> added the comment:

@jeremy: nice work
The fix works for me reproducable, tests run normal now.
Why dont you create a PR?

Can someone explain why this issue only came up with parallel tests?

----------

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

From report at bugs.python.org  Mon Sep  3 15:08:12 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 03 Sep 2018 19:08:12 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536001692.84.0.56676864532.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Looks like all sorts of academics are exercised over the run-merging order now.  Here's a paper that's unhappy because timsort's strategy, and 2-merge too, aren't always near-optimal with respect to the entropy of the distribution of natural run lengths:

"Nearly-Optimal Mergesorts:  Fast, Practical Sorting Methods That Optimally Adapt to Existing Runs"
J. Ian Munro
Sebastian Wild
https://arxiv.org/abs/1805.04154

Their alternatives are worth looking at too.  Offhand, their "powersort" ordering looks more promising to me than their "peeksort".  It was very deliberate that timsort looks at whether to merge a run immediately after identifying one, for the "freshness in memory hierarchy" reason.  That peeksort does not is, I expect, more significant in real life than the "one little blemish" they call it.

In any case, don't flip out over this.  On randomly ordered input, timsort already strongly tends toward perfectly balanced merges, and there's no significant improvement to be had over that.  On the other hand, on inputs with significant order that _can_ be exploited by this approach, the gains are far more due to "galloping" than to the order in which runs are merged.  All these papers ignore galloping entirely.  Example:  take range(1_000_000), cut it in half, and riffle shuffle it.  So you get

    0 500000 1 500001 ... 499999 999999 or
    500000 0 500001 1 ... 999999 499999
    
Either way, there are half a million natural runs, each of length 2.  Any balanced way of merging them is as good as it gets.  It's galloping alone that buys huge improvements in cases like this.

Especially in the context of Python, where object comparisons are (in general) far more expensive than moving pointers around, some excess in worst-case memory copying is, well, "one little blemish" ;-)

But still worth addressing if feasible.  Now that sorting often also adapts to avoid the relatively massive expense of PyObject_RichCompareBool, memory-movement costs become more important.  Approaches like 2-merge also give simpler merge_collapse() code that's easier to reason about, and reduces the worst-case stack size (which becomes very easy to compute in advance instead of the current puzzle).

----------

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

From report at bugs.python.org  Mon Sep  3 16:17:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 20:17:11 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1536005831.51.0.56676864532.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 84b0129b5e0a0e22aad22ae8db2e3833a228aa57 by Victor Stinner in branch '3.7':
_Py_CoerceLegacyLocale() restores LC_CTYPE on fail (GH-9044) (GH-9046)
https://github.com/python/cpython/commit/84b0129b5e0a0e22aad22ae8db2e3833a228aa57


----------

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

From report at bugs.python.org  Mon Sep  3 16:17:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 20:17:51 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1536005871.31.0.56676864532.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

test_c_locale_coerce pass again on AMD64 FreeBSD 10.x Shared 3.x, I close the issue.

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

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

From report at bugs.python.org  Mon Sep  3 17:17:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 21:17:24 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1536009444.71.0.56676864532.issue26901@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 65fc98e7b1f62c2e621f04780a3a77c3498cc195 by Victor Stinner in branch 'master':
bpo-26901: Fix the Argument Clinic test suite (GH-8879)
https://github.com/python/cpython/commit/65fc98e7b1f62c2e621f04780a3a77c3498cc195


----------

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

From report at bugs.python.org  Mon Sep  3 17:17:48 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Sep 2018 21:17:48 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1536009468.28.0.56676864532.issue26901@psf.upfronthosting.co.za>


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


----------
pull_requests: +8510

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

From report at bugs.python.org  Mon Sep  3 17:19:58 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 03 Sep 2018 21:19:58 +0000
Subject: [issue21877] External.bat and pcbuild of tkinter do not match.
In-Reply-To: <1403903857.63.0.770312559658.issue21877@psf.upfronthosting.co.za>
Message-ID: <1536009598.62.0.56676864532.issue21877@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I believe this has been fixed some time in the last few years; Terry, please reopen this if I've missed something.

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

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

From report at bugs.python.org  Mon Sep  3 17:20:08 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 03 Sep 2018 21:20:08 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536009608.96.0.56676864532.issue33083@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset e9ba3705de656215d52b8f8f4a2e7ad60190e944 by Pablo Galindo in branch 'master':
bpo-33083 - Make math.factorial reject arguments that are not int-like (GH-6149)
https://github.com/python/cpython/commit/e9ba3705de656215d52b8f8f4a2e7ad60190e944


----------
nosy: +pablogsal

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

From report at bugs.python.org  Mon Sep  3 17:20:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 21:20:47 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1536009647.87.0.56676864532.issue26901@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Any chance to fix Argument Clinic test? Without this we can't add new features, fix bugs and add tests for searching new bugs. This is critical for further converting to Argument Clinic.

Done in master branch. But test_clinic.py is really basic, it should really be extended to add more tests!

I also proposed to backport test_clinic.py to 3.7: PR 9048.

Thanks Pablo for the initial fix and for your review of my PR!

----------

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

From report at bugs.python.org  Mon Sep  3 17:26:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 21:26:37 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536009997.78.0.56676864532.issue34530@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8511

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

From report at bugs.python.org  Mon Sep  3 17:28:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 21:28:47 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536010127.5.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I missed the fact that find_executable() always lookup in the current directory, whereas shutil.which() doesn't. I abandoned my PR 8968 in favor of PR 9049 which only fix the case where PATH env var is not defined. This PR can easily be backported to all branches, whereas backporting PR 8968 to stable branches would be risky: changes to distutils are likely to break a random package on PyPI.

----------
versions: +Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep  3 17:50:11 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 03 Sep 2018 21:50:11 +0000
Subject: [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1536011411.59.0.56676864532.issue13081@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As far as I can tell, this was an application bug in multiprocessing cleanup 7 years ago.  I'm not sure there's really even anything to add to the docs for this, but if anyone disagrees or produces a patch, please reopen.

----------
nosy: +davin, pitrou, zach.ware
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Sep  3 17:55:40 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 03 Sep 2018 21:55:40 +0000
Subject: [issue4453] MSI installer shows error message if "Compile .py files
 to bytecode" option is selected
In-Reply-To: <1227885798.23.0.30127507321.issue4453@psf.upfronthosting.co.za>
Message-ID: <1536011740.55.0.56676864532.issue4453@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

According to Martin in msg112770, this was due to files that could not be compiled.  There shouldn't be any more of those added to 2.7 (which is the last version receiving binary releases using this installer scheme), so I'm closing the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions: +Python 2.7 -Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep  3 18:05:16 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 03 Sep 2018 22:05:16 +0000
Subject: [issue17480] pyvenv should be installed someplace more obvious on
 Windows
In-Reply-To: <1363714170.98.0.299571294884.issue17480@psf.upfronthosting.co.za>
Message-ID: <1536012316.06.0.56676864532.issue17480@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

With pyvenv removed from 3.8 and various other proposals in other issues for where scripts should be installed on Windows, I'm going to go ahead and close this.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.5

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

From report at bugs.python.org  Mon Sep  3 18:15:29 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 03 Sep 2018 22:15:29 +0000
Subject: [issue16892] Windows bug picking up stdin from a pipe
In-Reply-To: <1357652664.69.0.880454684679.issue16892@psf.upfronthosting.co.za>
Message-ID: <1536012929.67.0.56676864532.issue16892@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Eryk's diagnosis sounds like this is not a bug in Python or something that Python needs to or even should fix.

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

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

From report at bugs.python.org  Mon Sep  3 18:24:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 22:24:20 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1536013460.01.0.56676864532.issue26901@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1e921236d7ecc77299d34380d6a2159e9db05a1a by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-26901: Fix the Argument Clinic test suite (GH-8879) (GH-9048)
https://github.com/python/cpython/commit/1e921236d7ecc77299d34380d6a2159e9db05a1a


----------

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

From report at bugs.python.org  Mon Sep  3 18:25:32 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 03 Sep 2018 22:25:32 +0000
Subject: [issue17480] pyvenv should be installed someplace more obvious on
 Windows
In-Reply-To: <1363714170.98.0.299571294884.issue17480@psf.upfronthosting.co.za>
Message-ID: <1536013532.77.0.56676864532.issue17480@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Nice!

Linking to issue25427.

----------

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

From report at bugs.python.org  Mon Sep  3 18:25:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 22:25:34 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1536013534.28.0.56676864532.issue26901@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

We decided to only fix 3.7 and master branches, not 3.6 and older: https://github.com/python/cpython/pull/9048

The initial issue has been fixed, so I close the issue.

A new issue might be opened if someone wants to extend the existing test suite (test_clinic).

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

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

From report at bugs.python.org  Mon Sep  3 18:42:27 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 03 Sep 2018 22:42:27 +0000
Subject: [issue17480] pyvenv should be installed someplace more obvious on
 Windows
In-Reply-To: <1363714170.98.0.299571294884.issue17480@psf.upfronthosting.co.za>
Message-ID: <1536014547.68.0.56676864532.issue17480@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Mon Sep  3 20:49:40 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 04 Sep 2018 00:49:40 +0000
Subject: [issue34566] pipe read sometimes returns EOF but returncode is still
 None
In-Reply-To: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>
Message-ID: <1536022180.94.0.56676864532.issue34566@psf.upfronthosting.co.za>


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

The "grep" process may be closing its end of the pipe before it exits. Or if Grep leaves the pipe open when it exits, the OS may close the pipe before it makes the child exit status available. Either way, I suspect "p.stdout.read()" returns an empty string indicating the pipe is closed, but "p.poll()" returns None because the exit status is not yet ready. Even if it is the OS closing the pipe after the child exits, I doubt there is any guarantee about when that happens relative to the child's exit status becoming available.

The "poll" method does not wait for the child to exit. Normally you use the "wait" method in this situation. I suspect this is a bug in the application, not in Python.

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

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

From report at bugs.python.org  Mon Sep  3 21:06:44 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Tue, 04 Sep 2018 01:06:44 +0000
Subject: [issue33939] Provide a robust O(1) mechanism to check for infinite
 iterators
In-Reply-To: <1529671694.59.0.56676864532.issue33939@psf.upfronthosting.co.za>
Message-ID: <1536023204.18.0.56676864532.issue33939@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

That said, I agree with Antoine that being able to Ctrl-C would be the most useful of these fixes. But it seems clear that people are experiencing these issues differently (if at all).

----------

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

From report at bugs.python.org  Mon Sep  3 21:27:26 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Sep 2018 01:27:26 +0000
Subject: [issue21877] External.bat and pcbuild of tkinter do not match.
In-Reply-To: <1403903857.63.0.770312559658.issue21877@psf.upfronthosting.co.za>
Message-ID: <1536024446.25.0.56676864532.issue21877@psf.upfronthosting.co.za>


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

The fixes, attached to other issues, works flawlessly for me.

----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue Sep  4 00:13:52 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 04:13:52 +0000
Subject: [issue34573] Simplify __reduce__() of set and dict iterators.
Message-ID: <1536034432.71.0.56676864532.issue34573@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

Currently __reduce__() implementation of set and dict iterators saves items to list using next/PyList_Append(), it could be simplified by using PySequence_List().

----------
components: Interpreter Core
messages: 324550
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: Simplify __reduce__() of set and dict iterators.
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  4 00:15:16 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 04:15:16 +0000
Subject: [issue34573] Simplify __reduce__() of set and dict iterators.
In-Reply-To: <1536034432.71.0.56676864532.issue34573@psf.upfronthosting.co.za>
Message-ID: <1536034516.69.0.56676864532.issue34573@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


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

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

From report at bugs.python.org  Tue Sep  4 00:19:39 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 04:19:39 +0000
Subject: [issue34574] OrderedDict iterators are exhausted during pickling
Message-ID: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

In [1]: from collections import OrderedDict

In [2]: od = OrderedDict.fromkeys(range(10))

In [3]: it = iter(od)

In [4]: it.__reduce__()
Out[4]: (<function iter>, ([0, 1, 2, 3, 4, 5, 6, 7, 8, 9],))

In [5]: list(it)
Out[5]: []

----------
messages: 324551
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: OrderedDict iterators are exhausted during pickling
type: behavior

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

From report at bugs.python.org  Tue Sep  4 00:38:03 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 04:38:03 +0000
Subject: [issue34574] OrderedDict iterators are exhausted during pickling
In-Reply-To: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>
Message-ID: <1536035883.57.0.56676864532.issue34574@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


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

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

From report at bugs.python.org  Tue Sep  4 01:02:42 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 05:02:42 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536037362.14.0.56676864532.issue8110@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
pull_requests: +8514

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

From report at bugs.python.org  Tue Sep  4 01:04:47 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Sep 2018 05:04:47 +0000
Subject: [issue34573] Simplify __reduce__() of set and dict iterators.
In-Reply-To: <1536034432.71.0.56676864532.issue34573@psf.upfronthosting.co.za>
Message-ID: <1536037487.13.0.56676864532.issue34573@psf.upfronthosting.co.za>


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

Also take a look at the other places that have similar logic.  I believe these all went in at the same time. See commit 31668b8f7a3efc7b17511bb08525b28e8ff5f23a

----------
nosy: +kristjan.jonsson, rhettinger

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

From report at bugs.python.org  Tue Sep  4 01:07:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Sep 2018 05:07:04 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1536037624.74.0.56676864532.issue26901@psf.upfronthosting.co.za>


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

Thank you Pablo and Victor!

I do not mind backporting to 3.6. Argument Clinic still can take fixes, and they can add new tests.

----------

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

From report at bugs.python.org  Tue Sep  4 01:12:49 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Sep 2018 05:12:49 +0000
Subject: [issue34573] Simplify __reduce__() of set and dict iterators.
In-Reply-To: <1536034432.71.0.56676864532.issue34573@psf.upfronthosting.co.za>
Message-ID: <1536037969.88.0.56676864532.issue34573@psf.upfronthosting.co.za>


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

Seems there is a bug in the dict iter code, leading to a crash when pickle non-initial items iterator. Would be nice to add tests similar to issue34574, and if the bug will be exposed, fix it.

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

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

From report at bugs.python.org  Tue Sep  4 01:14:48 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 05:14:48 +0000
Subject: [issue1654408] Windows installer should split tcl/tk and tkinter
 install options.
Message-ID: <1536038088.49.0.56676864532.issue1654408@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Since installing tkinter without Tcl/Tk would leave tkinter unusable without a separately installed and configured Tcl/Tk (and thus probably generate copious reports about tkinter being broken), I don't think this is a good idea.  If someone *really* wants a different Tcl/Tk environment, they can always create their own.  Closing as rejected.

Terry's suggestion about being able to install Tcl/Tk extensions sounds reasonable, but I haven't played around with it and that should have its own issue if we're going to do anything with it.

----------
assignee: loewis -> 
resolution:  -> rejected
stage: test needed -> resolved
status: open -> closed
title: Installer should split tcl/tk and tkinter install options. -> Windows installer should split tcl/tk and tkinter install options.

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

From report at bugs.python.org  Tue Sep  4 01:17:39 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 05:17:39 +0000
Subject: [issue19955] When adding .PY and .PYW to PATHEXT,
 it replaced string instead of appending
In-Reply-To: <1386803247.34.0.411424382912.issue19955@psf.upfronthosting.co.za>
Message-ID: <1536038259.83.0.56676864532.issue19955@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Tue Sep  4 01:43:04 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 05:43:04 +0000
Subject: [issue23089] Update libffi config files
In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za>
Message-ID: <1536039784.91.0.56676864532.issue23089@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

We no longer bundle a full copy of libffi, and the toplevel config.* files have been kept relatively up to date.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Sep  4 02:13:10 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 06:13:10 +0000
Subject: [issue24401] Windows 8.1 install gives DLL required to complete could
 not run
In-Reply-To: <1433668228.61.0.22658051744.issue24401@psf.upfronthosting.co.za>
Message-ID: <1536041590.22.0.56676864532.issue24401@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Sep  4 02:18:10 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 06:18:10 +0000
Subject: [issue24698] get_externals.bat script fails
In-Reply-To: <1437671978.74.0.066435093939.issue24698@psf.upfronthosting.co.za>
Message-ID: <1536041890.31.0.56676864532.issue24698@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Closing as "out of date"; we no longer use svn to fetch external sources.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Sep  4 02:24:18 2018
From: report at bugs.python.org (chen wu)
Date: Tue, 04 Sep 2018 06:24:18 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1536042258.5.0.56676864532.issue34516@psf.upfronthosting.co.za>


chen wu <wuchen12 at huawei.com> added the comment:

to fix this, we change the code of our urilib3. before passing params to httplib, we set Host in headers if it's ipv6 address.

Thanks so much.

----------
resolution: duplicate -> not a bug
stage:  -> resolved
status: pending -> closed

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

From report at bugs.python.org  Tue Sep  4 02:50:45 2018
From: report at bugs.python.org (nilanjan roy)
Date: Tue, 04 Sep 2018 06:50:45 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1536043845.01.0.56676864532.issue34461@psf.upfronthosting.co.za>


nilanjan roy <roy.nilanjan at gmail.com> added the comment:

@serhiy.storchaka: 

If I concur with your comment then probably declaration of *__all__** over xml initializer(__init__) is little contradictory - because whenever we declare __all__ to enable global-scope means API provides the flexibility to use * during package import. Now this is totally depends on developer how the script need to optimize/simulate during development. Yes agree * should not be used due to high reference of memory usage. But as far __init__.py of xml and python convention this should not be explicitly restricted

----------

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

From report at bugs.python.org  Tue Sep  4 02:53:58 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Sep 2018 06:53:58 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1536044038.48.0.56676864532.issue34569@psf.upfronthosting.co.za>


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

64-bit mode, no error.

root at x066:[/data/prj/python/python3-3.8.0]./python -m test -v test__xxsubinterpreters
== CPython 3.8.0a0 (heads/master-dirty:d500e5307a, Sep 3 2018, 13:55:44) [C]
== AIX-1-00C291F54C00-powerpc-64bit-COFF big-endian
== cwd: /data/prj/python/python3-3.8.0/build/test_python_16908532
== CPU count: 8
== encodings: locale=ISO8859-1, FS=iso8859-1
Run tests sequentially
0:00:00 [1/1] test__xxsubinterpreters
test_bad_id (test.test__xxsubinterpreters.ChannelIDTests) ... ok
...
test_int (test.test__xxsubinterpreters.ShareableTypeTests) ... ok
test_singletons (test.test__xxsubinterpreters.ShareableTypeTests) ... ok
test_types (test.test__xxsubinterpreters.ShareableTypeTests) ... ok

----------------------------------------------------------------------
Ran 111 tests in 4.572s

OK (skipped=5)

== Tests result: SUCCESS ==

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

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

From report at bugs.python.org  Tue Sep  4 02:54:08 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Sep 2018 06:54:08 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1536044048.84.0.56676864532.issue34569@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
components: +Tests

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

From report at bugs.python.org  Tue Sep  4 03:14:15 2018
From: report at bugs.python.org (ron)
Date: Tue, 04 Sep 2018 07:14:15 +0000
Subject: [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1536045255.04.0.56676864532.issue16438@psf.upfronthosting.co.za>


ron <ron at mailinator.com> added the comment:

Any progress on this?

----------
nosy: +ronron

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

From report at bugs.python.org  Tue Sep  4 03:21:29 2018
From: report at bugs.python.org (Pablosky)
Date: Tue, 04 Sep 2018 07:21:29 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
In-Reply-To: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>
Message-ID: <1536045689.31.0.56676864532.issue34570@psf.upfronthosting.co.za>


Pablosky <pawelhrycyk at gmail.com> added the comment:

My system is Hp Z4 with 128GB ram. It is not rather problem of lack of memory. When I monitored free memory it took at most 30GB when these 20 pybots were working.

I wonder if it is possible that these separate programs (pybots) interfere each other. I mean that sharing the same modules/libraries cause that situations. Maybe one instance is recompiling py module to pyc at the same time when this is used by another process. Is it possible?

I have never caught segfault when there was only one instance of pybot.

BTW I caught 3 more different cores. I consider reinstalling my whole system (maybe Ubuntu 18.04). Maybe my system is broken.

----------

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

From report at bugs.python.org  Tue Sep  4 03:23:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 07:23:13 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
In-Reply-To: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>
Message-ID: <1536045793.59.0.56676864532.issue34570@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

You can install and enable faulthandler to get the Python traceback where the bug occurs. It is likely that the bug comes from a third party C extension.

What are the C extensions used by pybot?

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

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

From report at bugs.python.org  Tue Sep  4 04:53:59 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Sep 2018 08:53:59 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536051239.48.0.56676864532.issue33613@psf.upfronthosting.co.za>


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


New changeset ec74d187f50a8a48f94eb37023300583fbd644cc by Antoine Pitrou (Pablo Galindo) in branch 'master':
bpo-33613, test_semaphore_tracker_sigint: fix race condition (#7850)
https://github.com/python/cpython/commit/ec74d187f50a8a48f94eb37023300583fbd644cc


----------

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

From report at bugs.python.org  Tue Sep  4 04:56:19 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 08:56:19 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536051379.1.0.56676864532.issue33613@psf.upfronthosting.co.za>


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


----------
pull_requests: +8515

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

From report at bugs.python.org  Tue Sep  4 04:56:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 08:56:58 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536051418.2.0.56676864532.issue33613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

IMHO the fix should be backported to Python 3.6 and 3.7.

It cannot be backported to 2.7 since 2.7 doesn't have signal.pthread_sigmask().

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

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

From report at bugs.python.org  Tue Sep  4 05:01:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:01:13 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536051673.77.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 39487196c87e28128ea907a0d9b8a88ba53f68d5 by Victor Stinner in branch 'master':
bpo-34530: Fix distutils find_executable() (GH-9049)
https://github.com/python/cpython/commit/39487196c87e28128ea907a0d9b8a88ba53f68d5


----------

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

From report at bugs.python.org  Tue Sep  4 05:01:21 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 09:01:21 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536051681.57.0.56676864532.issue34530@psf.upfronthosting.co.za>


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


----------
pull_requests: +8516

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

From report at bugs.python.org  Tue Sep  4 05:01:30 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 09:01:30 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536051690.83.0.56676864532.issue34530@psf.upfronthosting.co.za>


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


----------
pull_requests: +8517

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

From report at bugs.python.org  Tue Sep  4 05:01:34 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Sep 2018 09:01:34 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536051694.73.0.56676864532.issue33613@psf.upfronthosting.co.za>


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

As I wrote on Github: no user-visible bug is fixed here, and we shouldn't risk introducing regressions by backporting those changes.

If buildbots hurt, I suggest skipping the tests on the buildbots.

----------
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep  4 05:12:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:12:33 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536052353.18.0.56676864532.issue33613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> If buildbots hurt, I suggest skipping the tests on the buildbots.

Let's do that. Pablo: do you want to write a PR to always skip TestSemaphoreTracker with a reference to this issue? Example: skipIf(True, "bpo-33613: the test has a race condition").

----------

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

From report at bugs.python.org  Tue Sep  4 05:13:22 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Sep 2018 09:13:22 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536052402.52.0.56676864532.issue33613@psf.upfronthosting.co.za>


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

Please only skip those tests on buildbots. They work fine otherwise.

----------

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

From report at bugs.python.org  Tue Sep  4 05:16:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:16:36 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536052596.67.0.56676864532.issue33613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Please only skip those tests on buildbots.

There is no easy wait to only skip a test on buildbots.

> They work fine otherwise.

The race condition impacts everyone. It's just less likely if your computer is fast enough. The bug is much more likely if you "force" the bad path:

diff --git a/Lib/multiprocessing/semaphore_tracker.py b/Lib/multiprocessing/semaphore_tracker.py
index 3b50a46ddc..7261b43725 100644
--- a/Lib/multiprocessing/semaphore_tracker.py
+++ b/Lib/multiprocessing/semaphore_tracker.py
@@ -107,6 +107,8 @@ getfd = _semaphore_tracker.getfd
 def main(fd):
     '''Run semaphore tracker.'''
     # protect the process from ^C and "killall python" etc
+    import time
+    time.sleep(0.5)
     signal.signal(signal.SIGINT, signal.SIG_IGN)
     signal.signal(signal.SIGTERM, signal.SIG_IGN)
 
diff --git a/Lib/test/_test_multiprocessing.py b/Lib/test/_test_multiprocessing.py
index 5c625dd495..6f9f7583e2 100644
--- a/Lib/test/_test_multiprocessing.py
+++ b/Lib/test/_test_multiprocessing.py
@@ -4193,7 +4193,6 @@ class TestSemaphoreTracker(unittest.TestCase):
         _multiprocessing.sem_unlink(name1)
         p.terminate()
         p.wait()
-        time.sleep(2.0)
         with self.assertRaises(OSError) as ctx:
             _multiprocessing.sem_unlink(name2)
         # docs say it should be ENOENT, but OSX seems to give EINVAL

----------

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

From report at bugs.python.org  Tue Sep  4 05:17:21 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Sep 2018 09:17:21 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1536052596.67.0.56676864532.issue33613@psf.upfronthosting.co.za>
Message-ID: <7df5a514-6923-26e4-f64c-23bd31c197b5@free.fr>


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

Le 04/09/2018 ? 11:16, STINNER Victor a ?crit?:
> 
>> They work fine otherwise.
> 
> The race condition impacts everyone. It's just less likely if your computer is fast enough. The bug is much more likely if you "force" the bad path:

Which bug? It's only a failing test.

----------

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

From report at bugs.python.org  Tue Sep  4 05:17:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:17:57 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536052677.46.0.56676864532.issue33613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

By the way, "no user-visible bug is fixed here": I agree that it's not easy to trigger manually the bug (when pressing CTRL+C), but I don't see why an user couldn't hit this bug. The race condition is now obvious to me.

----------

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

From report at bugs.python.org  Tue Sep  4 05:18:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:18:07 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536052687.33.0.56676864532.issue34530@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8518

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

From report at bugs.python.org  Tue Sep  4 05:18:42 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Sep 2018 09:18:42 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536052721.99.0.56676864532.issue33613@psf.upfronthosting.co.za>


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

I don't want to spend hours arguing.  This issue is sufficiently rare and unlikely in normal conditions that I don't think we should risk regressions by trying to fix it.

----------

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

From report at bugs.python.org  Tue Sep  4 05:18:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:18:49 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1536052729.81.0.56676864532.issue33613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Which bug? It's only a failing test.

Linux vendors run the full test suite. If the test suite fails, the build of the package fails as well. It's annoying.

----------

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

From report at bugs.python.org  Tue Sep  4 05:19:20 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 09:19:20 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536052760.54.0.56676864532.issue34530@psf.upfronthosting.co.za>


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


New changeset 7aa3eadca2a50ce651ce603d6100b05bb7106f1c by Miss Islington (bot) in branch '3.7':
bpo-34530: Fix distutils find_executable() (GH-9049)
https://github.com/python/cpython/commit/7aa3eadca2a50ce651ce603d6100b05bb7106f1c


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

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

From report at bugs.python.org  Tue Sep  4 05:31:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:31:27 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
Message-ID: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Example on my PR:
https://github.com/python/cpython/pull/9057

https://ci.appveyor.com/project/python/cpython/build/3.6build21480/job/lge7r4qknx0t0tlv

LINK : fatal error C1047: The object or library file 'C:\projects\cpython\PCBuild\win32\libeay.lib' was created with an older compiler than other objects; rebuild old objects and libraries [C:\projects\cpython\PCbuild\_hashlib.vcxproj]
LINK : fatal error LNK1257: code generation failed [C:\projects\cpython\PCbuild\_hashlib.vcxproj]
LINK : fatal error C1047: The object or library file 'C:\projects\cpython\PCBuild\win32\libeay.lib' was created with an older compiler than other objects; rebuild old objects and libraries [C:\projects\cpython\PCbuild\_ssl.vcxproj]
LINK : fatal error LNK1257: code generation failed [C:\projects\cpython\PCbuild\_ssl.vcxproj]
Command exited with code 1

----------
components: Build, Windows
messages: 324576
nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.6 compilation fails on AppVeyor: libeay.lib was created with an older compiler
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  4 05:34:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:34:44 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536053684.67.0.56676864532.issue34246@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Tue Sep  4 05:39:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:39:03 +0000
Subject: [issue34576] SimpleHTTPServer: warn users on security
Message-ID: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Larry Hastings proposed on the PSRT mailing list to add the following note of the SimpleHTTPServer documentation:

    Note: SimpleHTTPServer is, as its name implies, a simple HTTP
    server.  We provide it as a sample implementation of the Python HTTP
    server API.  However, SimpleHTTPServer is neither secure nor
    high-performance, and as such you should not use SimpleHTTPServer in
    security-sensitive or performance-sensitive applications.

For example, if you create a symbolic link outside the directory served by SimpleHTTPServer, SimpleHTTPServer follows symbolic links.

----------
components: Library (Lib)
messages: 324577
nosy: vstinner
priority: normal
severity: normal
status: open
title: SimpleHTTPServer: warn users on security
type: security
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep  4 05:40:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:40:35 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536054035.19.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7056ca880bf4ff428dfb2c4eee67919dc43ecd34 by Victor Stinner in branch '2.7':
bpo-34530: Fix distutils find_executable() (GH-9049) (GH-9058)
https://github.com/python/cpython/commit/7056ca880bf4ff428dfb2c4eee67919dc43ecd34


----------

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

From report at bugs.python.org  Tue Sep  4 06:13:35 2018
From: report at bugs.python.org (Windson Yang)
Date: Tue, 04 Sep 2018 10:13:35 +0000
Subject: [issue34576] SimpleHTTPServer: warn users on security
In-Reply-To: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>
Message-ID: <1536056015.4.0.56676864532.issue34576@psf.upfronthosting.co.za>


Windson Yang <wiwindson at gmail.com> added the comment:

The SimpleHTTPServer module has been merged into http.server in Python 3. So we add this to python2 document?

----------
nosy: +Windson Yang

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

From report at bugs.python.org  Tue Sep  4 06:37:46 2018
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 04 Sep 2018 10:37:46 +0000
Subject: [issue34573] Simplify __reduce__() of set and dict iterators.
In-Reply-To: <1536037487.13.0.56676864532.issue34573@psf.upfronthosting.co.za>
Message-ID: <CAP8kY6anXZryKd224ppkRhwvkqPpAUk8+YxJucTrvPq8q=zbLg@mail.gmail.com>


Kristj?n Valur J?nsson <sweskman at gmail.com> added the comment:

Interesting, I'll have a look when I'm back from vacation.

On Tue, 4 Sep 2018, 07:04 Raymond Hettinger, <report at bugs.python.org> wrote:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> Also take a look at the other places that have similar logic.  I believe
> these all went in at the same time. See commit
> 31668b8f7a3efc7b17511bb08525b28e8ff5f23a
>
> ----------
> nosy: +kristjan.jonsson, rhettinger
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34573>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Sep  4 06:46:26 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 10:46:26 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536057986.22.0.56676864532.issue1621@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
pull_requests: +8519

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

From report at bugs.python.org  Tue Sep  4 06:59:22 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 04 Sep 2018 10:59:22 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536058762.69.0.56676864532.issue8110@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue Sep  4 07:00:46 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 04 Sep 2018 11:00:46 +0000
Subject: [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1536058846.03.0.56676864532.issue16438@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue Sep  4 08:04:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Sep 2018 12:04:36 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536062676.15.0.56676864532.issue26544@psf.upfronthosting.co.za>


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


New changeset 7917aadb3edb7616d6164c5eaba24df6ac0a5fc6 by Serhiy Storchaka in branch 'master':
bpo-26544: Add test for platform._comparable_version(). (GH-8973)
https://github.com/python/cpython/commit/7917aadb3edb7616d6164c5eaba24df6ac0a5fc6


----------

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

From report at bugs.python.org  Tue Sep  4 08:32:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 12:32:50 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536064370.94.0.56676864532.issue26544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks for adding tests ;-) It now looks better to me ;-)

----------

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

From report at bugs.python.org  Tue Sep  4 08:33:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 12:33:22 +0000
Subject: [issue34576] SimpleHTTPServer: warn users on security
In-Reply-To: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>
Message-ID: <1536064402.37.0.56676864532.issue34576@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> The SimpleHTTPServer module has been merged into http.server in Python 3. So we add this to python2 document?

The node should be added to Python 2 and Python 3 documentations.

----------

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

From report at bugs.python.org  Tue Sep  4 08:36:39 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 04 Sep 2018 12:36:39 +0000
Subject: [issue34576] SimpleHTTPServer: warn users on security
In-Reply-To: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>
Message-ID: <1536064599.54.0.56676864532.issue34576@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Sep  4 08:42:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 04 Sep 2018 12:42:52 +0000
Subject: [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536064972.66.0.56676864532.issue34549@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Are you asking for a separate section grouping together all the assert methods from different parts which I think is useful. If you are looking for a better link then there is a link in the below text at the start of the page 

> If you are already familiar with the basic concepts of testing, you might want to skip to the list of assert methods.

The text "list of assert methods" links to https://docs.python.org/3.7/library/unittest.html#assert-methods which I hope is what you are looking for.


Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Sep  4 09:37:29 2018
From: report at bugs.python.org (Nick)
Date: Tue, 04 Sep 2018 13:37:29 +0000
Subject: [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536068249.12.0.56676864532.issue34549@psf.upfronthosting.co.za>


Nick <manifes7o at gmail.com> added the comment:

Ah, yes! Was searching for one of those helpful "Permalink to this ___" options. Didn't even see the link at the top.

Thank you!

----------

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

From report at bugs.python.org  Tue Sep  4 09:50:55 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Sep 2018 13:50:55 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1536069055.24.0.56676864532.issue34546@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  4 10:11:45 2018
From: report at bugs.python.org (Nikita Velykanov)
Date: Tue, 04 Sep 2018 14:11:45 +0000
Subject: [issue34577] imaplib Cyrillic password
Message-ID: <1536070305.76.0.56676864532.issue34577@psf.upfronthosting.co.za>


New submission from Nikita Velykanov <nvelykanov at jerasoft.net>:

Let's consider there is an email box with password which contains Cyrillic symbols. When loging in

  imaplib.IMAP4_SSL(host, port).login(login, password)

password field is passed as "?????????" (type is str, not unicode).
Then, I get this traceback:

  File "/usr/lib64/python2.7/imaplib.py", line 518, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib64/python2.7/imaplib.py", line 1083, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python2.7/imaplib.py", line 870, in _command
    self.send('%s%s' % (data, CRLF))
  File "/usr/lib64/python2.7/imaplib.py", line 1191, in send
    sent = self.sslobj.write(data)
  File "/usr/lib64/python2.7/ssl.py", line 669, in write
    return self._sslobj.write(data)

This is because self._sslobj.write method requires unicode string.

In other case, if password field is passed as u"?????????" (type unicode, not str), I get another traceback:

  File "/usr/lib64/python2.7/imaplib.py", line 518, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib64/python2.7/imaplib.py", line 1083, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python2.7/imaplib.py", line 852, in _command
    data = '%s %s' % (data, self._checkquote(arg))

It's because '%s' % u"some unicode string" doesn't work.

I guess the problem was described in details.
The problem is that two different libraries are using different string types but they must be agreed.

----------
components: Library (Lib), Unicode
messages: 324586
nosy: Nikita Velykanov, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: imaplib Cyrillic password
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  4 10:27:14 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 04 Sep 2018 14:27:14 +0000
Subject: [issue34577] imaplib Cyrillic password
In-Reply-To: <1536070305.76.0.56676864532.issue34577@psf.upfronthosting.co.za>
Message-ID: <1536071234.54.0.56676864532.issue34577@psf.upfronthosting.co.za>


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

You have cut off the exception message. Please provide a full traceback including the exception name and message.

Password algorithms typically handle only bytes. The encoding depends on your target system and is usually utf-8.

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

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

From report at bugs.python.org  Tue Sep  4 10:31:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Sep 2018 14:31:26 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536071486.19.0.56676864532.issue26544@psf.upfronthosting.co.za>


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


New changeset 20a8392cec2967f15ae81633c1775645b3ca40da by Serhiy Storchaka in branch '3.7':
[3.7] bpo-26544: Get rid of dependence from distutils in platform. (GH-8356). (GH-8970)
https://github.com/python/cpython/commit/20a8392cec2967f15ae81633c1775645b3ca40da


----------

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

From report at bugs.python.org  Tue Sep  4 10:31:37 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 14:31:37 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536071497.31.0.56676864532.issue26544@psf.upfronthosting.co.za>


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


----------
pull_requests: +8521

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

From report at bugs.python.org  Tue Sep  4 10:43:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Sep 2018 14:43:17 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536072197.66.0.56676864532.issue26544@psf.upfronthosting.co.za>


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


----------
pull_requests: +8522

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

From report at bugs.python.org  Tue Sep  4 10:50:41 2018
From: report at bugs.python.org (Arselon)
Date: Tue, 04 Sep 2018 14:50:41 +0000
Subject: [issue34578] Pipenv lock : ModuleNotFoundError: No module named
 '_ctypes'
Message-ID: <1536072641.34.0.56676864532.issue34578@psf.upfronthosting.co.za>


New submission from Arselon <arslanaliev at yahoo.com>:

I migrated from 3.6.6 to 3.7.
Error during command: pipenv lock (environment was created before successfully):
LOG:
PS C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python\repos\DjangoPollsNew> pipenv lock
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
ser\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\core.py", line 8, in <module>
    from .types import convert_type, IntRange, BOOL
  File "c:\users\user\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\types.py", line 4, in <module>
    from ._compat import open_stream, text_type, filename_to_ui, \
  File "c:\users\user\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\_compat.py", line 536, in <module>
    from ._winconsole import _get_windows_console_stream
  File "c:\users\user\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\_winconsole.py", line 16, in <module>
    import ctypes
  File "C:\Users\User\AppData\Local\Programs\Python\Python37\Lib\ctypes\__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'

What can I do?
I need to create new Pipfile.lock for heroku hosting.
Thanks in advance))

----------
components: Library (Lib)
hgrepos: 378
messages: 324589
nosy: Arselon
priority: normal
severity: normal
status: open
title: Pipenv lock : ModuleNotFoundError: No module named '_ctypes'
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep  4 11:06:52 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Sep 2018 15:06:52 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
Message-ID: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

test_init_default_config (test.test_embed.InitConfigTests) ... FAIL
test_init_dev_mode (test.test_embed.InitConfigTests) ... FAIL
test_init_env (test.test_embed.InitConfigTests) ... FAIL
test_init_from_config (test.test_embed.InitConfigTests) ... ok
test_init_global_config (test.test_embed.InitConfigTests) ... FAIL
test_init_isolated (test.test_embed.InitConfigTests) ... FAIL

This seems to be caused because the dump_config() output is not
'(null)' for the keys allocator, program, and pycache_prefix.

When these are 'expected' to be '' (rather than '(null)', all tests pass.

See PR

----------
messages: 324590
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_embed.InitConfigTests fail on AIX

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

From report at bugs.python.org  Tue Sep  4 11:10:31 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Sep 2018 15:10:31 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1536073831.23.0.56676864532.issue34579@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
components: +Tests
versions: +Python 3.8

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

From report at bugs.python.org  Tue Sep  4 11:15:14 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Sep 2018 15:15:14 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1536074114.05.0.56676864532.issue34579@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


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

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

From report at bugs.python.org  Tue Sep  4 11:16:36 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Tue, 04 Sep 2018 15:16:36 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
Message-ID: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>


New submission from Daniel Jakots <lolbuntu at chown.me>:

In my experience, the first encounter for beginners with the context manager is with files. The highlighted feature is that you don't need to close the file, 'with' is going to do it for you.

The sqlite3 documentation talks about the context manager in "12.6.8.3. Using the connection as a context manager". The problem in my opinion is that people may believe that the context manager may manage the open/close which is not the case, reading the Modules/_sqlite/connection.c:pysqlite_connection_exit shows that it only does the commit or the rollback.

I'm not sure about the best fix. It can be either (or both) a sentence in the description and/or adding at then end of the code snippet "con.close()" to show that it still needs to be done.

Thanks!

----------
messages: 324591
nosy: vigdis
priority: normal
severity: normal
status: open
title: sqlite doc: clarify the scope of the context manager
type: enhancement

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

From report at bugs.python.org  Tue Sep  4 11:29:30 2018
From: report at bugs.python.org (Nikita Velykanov)
Date: Tue, 04 Sep 2018 15:29:30 +0000
Subject: [issue34577] imaplib Cyrillic password
In-Reply-To: <1536070305.76.0.56676864532.issue34577@psf.upfronthosting.co.za>
Message-ID: <1536074970.37.0.56676864532.issue34577@psf.upfronthosting.co.za>


Nikita Velykanov <nvelykanov at jerasoft.net> added the comment:

Thank you for fast reply.
Here's full traceback for first case:

Traceback (most recent call last):
  File "some_my_file.py", line 10, in some_function
    self.mail.login(login, password)
  File "/usr/lib64/python2.7/imaplib.py", line 518, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib64/python2.7/imaplib.py", line 1083, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python2.7/imaplib.py", line 870, in _command
    self.send('%s%s' % (data, CRLF))
  File "/usr/lib64/python2.7/imaplib.py", line 1191, in send
    sent = self.sslobj.write(data)
  File "/usr/lib64/python2.7/ssl.py", line 669, in write
    return self._sslobj.write(data)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 30-39: ordinal not in range(128)

Full traceback for second case:

Traceback (most recent call last):
  File "some_my_file.py", line 10, in some_function
    self.mail.login(login, password)
  File "/usr/lib64/python2.7/imaplib.py", line 518, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib64/python2.7/imaplib.py", line 1083, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python2.7/imaplib.py", line 852, in _command
    data = '%s %s' % (data, self._checkquote(arg))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 1: ordinal not in range(128)


But okay, even if encoding depends on target system and it's usually utf-8 so why string operations in imaplib are not in usual format but in some other?

----------

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

From report at bugs.python.org  Tue Sep  4 12:07:09 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 04 Sep 2018 16:07:09 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536077229.38.0.56676864532.issue34575@psf.upfronthosting.co.za>


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

Works on VSTS build. I suspect AppVeyor is caching files between builds, but I'm not familiar enough with the configuration to fix that.

----------

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

From report at bugs.python.org  Tue Sep  4 12:10:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 16:10:37 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536077437.79.0.56676864532.issue34563@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 266f4904a222a784080e29aad0916849e507515d by Victor Stinner (Alexander Buchkovsky) in branch 'master':
bpo-34563: Fix for invalid assert on big output of multiprocessing.Process (GH-9027)
https://github.com/python/cpython/commit/266f4904a222a784080e29aad0916849e507515d


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

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

From report at bugs.python.org  Tue Sep  4 12:11:12 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 16:11:12 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536077472.24.0.56676864532.issue34563@psf.upfronthosting.co.za>


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


----------
pull_requests: +8524

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

From report at bugs.python.org  Tue Sep  4 12:35:55 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 04 Sep 2018 16:35:55 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1536078955.0.0.56676864532.issue34565@psf.upfronthosting.co.za>


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


New changeset 3876af4f7c2ef87db6d2d83efc229955968926dd by Steve Dower (Brendan Gerrity) in branch 'master':
bpo-34565: Change a PC/launcher.c comment to accurately describe valid major versions. (GH-9037)
https://github.com/python/cpython/commit/3876af4f7c2ef87db6d2d83efc229955968926dd


----------

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

From report at bugs.python.org  Tue Sep  4 12:35:57 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Sep 2018 16:35:57 +0000
Subject: [issue34565] Launcher does not validate major versions
In-Reply-To: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>
Message-ID: <1536078957.27.0.56676864532.issue34565@psf.upfronthosting.co.za>


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


----------
pull_requests: +8525

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

From report at bugs.python.org  Tue Sep  4 14:27:11 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Tue, 04 Sep 2018 18:27:11 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536085631.15.0.56676864532.issue34561@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

It doesn?t seem like there?s a real problem here, but you seem to suggest there would be some useful improvements possible here. I don?t know much about sorting algorithms per se. What do you mean by galloping?

----------
nosy: +koos.zevenhoven

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

From report at bugs.python.org  Tue Sep  4 14:46:31 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 04 Sep 2018 18:46:31 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536086791.56.0.56676864532.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

"Galloping" is the heart & soul of Python's sorting algorithm.  It's explained in detail here:

https://github.com/python/cpython/blob/master/Objects/listsort.txt

The Java fork of the sorting code has had repeated bugs due to reducing the size of "the stack" used to hold merge states.  Read the papers already referenced for details about that.

There is no "bug" here in the Python version.  It's that the complex code Java keeps tripping over ;-) , _could_ (possibly) be replaced by simpler code where the max stack size needed is obvious; that (e.g.) 2-merge moves around less memory overall in some cases where the current scheme is particularly wasteful in this respect; and that Munro & Wild present more ambitious merge-ordering schemes that are said to be provably near-optimal in a broader sense than 2-merge achieves.

----------

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

From report at bugs.python.org  Tue Sep  4 14:58:42 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Sep 2018 18:58:42 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536087522.59.0.56676864532.issue8110@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +giampaolo.rodola, gregory.p.smith
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/issue8110>
_______________________________________

From report at bugs.python.org  Tue Sep  4 15:05:55 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 04 Sep 2018 19:05:55 +0000
Subject: [issue34577] imaplib Cyrillic password
In-Reply-To: <1536070305.76.0.56676864532.issue34577@psf.upfronthosting.co.za>
Message-ID: <1536087955.91.0.56676864532.issue34577@psf.upfronthosting.co.za>


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

This is not a bug in Python's imaplib but a limitation of the LDAP protocol. It's not possible to enable UTF-8 mode before the session is authenticatd. LOGIN supports only ASCII user name and password. You have to use SASL PLAIN handshake with AUTHENTICATE, see https://tools.ietf.org/html/rfc6855.html#page-5

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

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

From report at bugs.python.org  Tue Sep  4 15:15:45 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Sep 2018 19:15:45 +0000
Subject: [issue1654408] Windows installer should split tcl/tk and tkinter
 install options.
Message-ID: <1536088545.89.0.56676864532.issue1654408@psf.upfronthosting.co.za>


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

In support of closing this, I note that we have gone the opposite direction on Mac, installing current tcl/tk together with _tkinter compiled against the tcl/tk being installed.

----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue Sep  4 15:24:26 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Sep 2018 19:24:26 +0000
Subject: [issue31512] Add non-elevated symlink support for dev mode Windows 10
In-Reply-To: <1505762190.77.0.84923243723.issue31512@psf.upfronthosting.co.za>
Message-ID: <1536089066.67.0.56676864532.issue31512@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  4 15:27:35 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Sep 2018 19:27:35 +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: <1536089255.77.0.56676864532.issue31226@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  4 15:40:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 19:40:08 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536090008.63.0.56676864532.issue34563@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset e8ca8806a9f47b3bac4ae1c6b8a54c47d1aad8f3 by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-34563: Fix for invalid assert on big output of multiprocessing.Process (GH-9027) (GH-9064)
https://github.com/python/cpython/commit/e8ca8806a9f47b3bac4ae1c6b8a54c47d1aad8f3


----------

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

From report at bugs.python.org  Tue Sep  4 16:33:35 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Sep 2018 20:33:35 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536093215.41.0.56676864532.issue33083@psf.upfronthosting.co.za>


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

The issue description mentions 3.7 and 2.7, but GH-6149 wasn't marked for backport. My feeling is that it isn't worth backporting the fix, in which case this issue can be closed.

----------

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

From report at bugs.python.org  Tue Sep  4 16:34:25 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Sep 2018 20:34: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: <1536093265.7.0.56676864532.issue33083@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Tue Sep  4 17:05:20 2018
From: report at bugs.python.org (Erik Janssens)
Date: Tue, 04 Sep 2018 21:05:20 +0000
Subject: [issue34581] Windows : use of __pragma msvc extension without ifdef
Message-ID: <1536095120.63.0.56676864532.issue34581@psf.upfronthosting.co.za>


New submission from Erik Janssens <erik.janssens at conceptive.be>:

The socketmodule uses the MSVC extension __pragma.

The use of this extension is not enabled/disable by an #ifdef _MSC_VER.

This prevents compilation with other compilers then MSVC on Windows.

----------
components: Extension Modules
messages: 324603
nosy: erikjanss
priority: normal
severity: normal
status: open
title: Windows : use of __pragma msvc extension without ifdef
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  4 17:10:39 2018
From: report at bugs.python.org (Erik Janssens)
Date: Tue, 04 Sep 2018 21:10:39 +0000
Subject: [issue34581] Windows : use of __pragma msvc extension without ifdef
In-Reply-To: <1536095120.63.0.56676864532.issue34581@psf.upfronthosting.co.za>
Message-ID: <1536095439.98.0.56676864532.issue34581@psf.upfronthosting.co.za>


Change by Erik Janssens <erik.janssens at conceptive.be>:


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

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

From report at bugs.python.org  Tue Sep  4 17:33:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 21:33:33 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536096813.64.0.56676864532.issue33083@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I agree to not backport the change to 3.7 and older. The change can be seen as subtle behaviour change which breaks backward compatibility.

----------
status: pending -> closed
versions:  -Python 2.7, Python 3.7

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

From report at bugs.python.org  Tue Sep  4 17:37:11 2018
From: report at bugs.python.org (David Staheli)
Date: Tue, 04 Sep 2018 21:37:11 +0000
Subject: [issue34582] VSTS builds should use new YAML syntax and pools
Message-ID: <1536097031.78.0.56676864532.issue34582@psf.upfronthosting.co.za>


Change by David Staheli <david at staheli.org>:


----------
nosy: David Staheli
priority: normal
severity: normal
status: open
title: VSTS builds should use new YAML syntax and pools

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

From report at bugs.python.org  Tue Sep  4 17:55:33 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Sep 2018 21:55:33 +0000
Subject: [issue34582] VSTS builds should use new YAML syntax and pools
Message-ID: <1536098133.22.0.56676864532.issue34582@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  4 18:09:14 2018
From: report at bugs.python.org (Isaac Shabtay)
Date: Tue, 04 Sep 2018 22:09:14 +0000
Subject: [issue34583] os.stat() wrongfully returns False for symlink on
 Windows 10 v1803
Message-ID: <1536098954.93.0.56676864532.issue34583@psf.upfronthosting.co.za>


New submission from Isaac Shabtay <isaac at shabtay.com>:

Windows 10 Pro, v1803.
Created a directory: D:\Test
Created a symbolic link to it: C:\Test -> D:\Test

The current user has permissions to access the link, however os.stat() fails:

>>> os.stat('C:\\Test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [WinError 5] Access is denied: 'C:\\Test'

The only change in my system since this has last worked, is that I upgraded to v1803 (used to be v1709 up until about a week ago).

----------
components: Library (Lib)
messages: 324605
nosy: Isaac Shabtay
priority: normal
severity: normal
status: open
title: os.stat() wrongfully returns False for symlink on Windows 10 v1803
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep  4 19:15:12 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 04 Sep 2018 23:15:12 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1536102912.33.0.56676864532.issue34568@psf.upfronthosting.co.za>


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

It was a deliberate decision. You can find some motivation in PEP 560, and yes we used provisional status here. It was a hard decision, but we decided that giving up few percent of backwards compatibility is a reasonable price for up to 5x performance boost.

It looks like some of your problems may be solved by https://github.com/ilevkivskyi/typing_inspect (use `pip install typing_inspect`) that aims at providing cross-version runtime introspection of typing objects by carefully wrapping some "hidden" internal API.

There is a plan to include most used part of typing_inspect in typing itself, see for example https://github.com/python/typing/issues/570.
(it is hard to give an estimate about when, I really want to do this soon, but just don't have time).

----------

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

From report at bugs.python.org  Tue Sep  4 21:28:28 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Wed, 05 Sep 2018 01:28:28 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536110908.94.0.56676864532.issue34563@psf.upfronthosting.co.za>


Change by Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com>:


----------
pull_requests: +8528

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

From report at bugs.python.org  Wed Sep  5 01:55:10 2018
From: report at bugs.python.org (Tim Peters)
Date: Wed, 05 Sep 2018 05:55:10 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536126910.29.0.56676864532.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

A new version of the file models a version of the `powersort` merge ordering too.  It clearly dominates timsort and 2-merge in all cases tried, for this notion of "cost".

Against it, its code is much more complex, and the algorithm is very far from obvious.  The paper "motivates" it but doesn't really explain it in enough detail to make most of it clear (but refers to other papers where pieces of it are developed).

Curious:  unless a run is the last in an array, powersort never merges it immediately upon finding it.  Instead its start and length are used to compute a "power", in turn used to decide whether to merge some previous number of runs.  A dollar to anyone who can figure out what the heck the "power" computation is really doing in less than a full day without reading the paper ;-)  Then two dollars if you can prove that the "never equal!" assert holds.

It would require timing lots of C code on various cases to see whether the possible delay in merging new runs really matters.  It's unclear to me a priori, because it buys something too (less memory copying overall).

In any case, just switching to 2-merge would be easy, and that alone is enough to squash the contrived "bad cases" for the current approach.  `powersort` would too, but may also actually help a bit in ordinary cases.  Or not.

----------
Added file: https://bugs.python.org/file47785/runstack.py

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

From report at bugs.python.org  Wed Sep  5 02:29:47 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 05 Sep 2018 06:29:47 +0000
Subject: [issue34581] Windows : use of __pragma msvc extension without ifdef
In-Reply-To: <1536095120.63.0.56676864532.issue34581@psf.upfronthosting.co.za>
Message-ID: <1536128987.83.0.56676864532.issue34581@psf.upfronthosting.co.za>


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


New changeset 874809ea389e6434787e773a6054a08e0b81f734 by Benjamin Peterson (Erik Janssens) in branch 'master':
closes bpo-34581 : Conditionalize use of __pragma in Modules/socketmodule.c. (GH-9067)
https://github.com/python/cpython/commit/874809ea389e6434787e773a6054a08e0b81f734


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Sep  5 02:29:58 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Sep 2018 06:29:58 +0000
Subject: [issue34581] Windows : use of __pragma msvc extension without ifdef
In-Reply-To: <1536095120.63.0.56676864532.issue34581@psf.upfronthosting.co.za>
Message-ID: <1536128998.17.0.56676864532.issue34581@psf.upfronthosting.co.za>


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


----------
pull_requests: +8529

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

From report at bugs.python.org  Wed Sep  5 02:45:07 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Sep 2018 06:45:07 +0000
Subject: [issue34581] Windows : use of __pragma msvc extension without ifdef
In-Reply-To: <1536095120.63.0.56676864532.issue34581@psf.upfronthosting.co.za>
Message-ID: <1536129907.88.0.56676864532.issue34581@psf.upfronthosting.co.za>


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


New changeset 5b17d7fccd8f0b4d5030b03924eb00904585ba31 by Miss Islington (bot) in branch '3.7':
closes bpo-34581 : Conditionalize use of __pragma in Modules/socketmodule.c. (GH-9067)
https://github.com/python/cpython/commit/5b17d7fccd8f0b4d5030b03924eb00904585ba31


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

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

From report at bugs.python.org  Wed Sep  5 03:07:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 07:07:07 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536131227.59.0.56676864532.issue34561@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Sep  5 03:39:43 2018
From: report at bugs.python.org (Pablosky)
Date: Wed, 05 Sep 2018 07:39:43 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
In-Reply-To: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>
Message-ID: <1536133183.21.0.56676864532.issue34570@psf.upfronthosting.co.za>


Pablosky <pawelhrycyk at gmail.com> added the comment:

Victor,

I am not familiar with code of pybot and RobotFramwework. So I don't know what extensions they are using.

I am attaching more backtraces of cores I was able to catch.

I am doing now some experiments and I am trying to find maximum amount of pybot processes which can run simultaneously without crash.

----------
Added file: https://bugs.python.org/file47786/python_cores.zip

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

From report at bugs.python.org  Wed Sep  5 04:27:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 08:27:09 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
In-Reply-To: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>
Message-ID: <1536136029.78.0.56676864532.issue34570@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Core dumps are usually unusable on a different platform. You should extract informations yourself using gdb or something else. At least, I'm sure that I will be unable to use your core dump on Fedora (you are using Ubuntu). You can open a core dump using "gdb python2.7 -c coredump" and then type "where" to get the C traceback.

----------

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

From report at bugs.python.org  Wed Sep  5 04:27:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 08:27:48 +0000
Subject: [issue34570] Segmentation fault in _PyType_Lookup
In-Reply-To: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>
Message-ID: <1536136068.93.0.56676864532.issue34570@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Again, I'm 90% sure that it's a bug in a third party module and so you should report the crash to pybot, not to Python.

----------

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

From report at bugs.python.org  Wed Sep  5 04:30:40 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 08:30:40 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536136240.46.0.56676864532.issue34575@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

If it's due to cache then there is a REST API to clear the cache manually and someone with access to Appveyor credentials can give it a try to clear the cache and see if it's fixed.

Ref : https://github.com/appveyor/ci/issues/985

Log in and execute the below from the console as per https://github.com/appveyor/ci/issues/985#issuecomment-279199811

$.ajax({
    url: 'https://ci.appveyor.com/api/projects/<username>/<project>/buildcache',
    type: 'DELETE'})

A workaround : https://help.appveyor.com/discussions/questions/1310-delete-cache


Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Sep  5 05:06:25 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 05 Sep 2018 09:06:25 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536138385.98.0.56676864532.issue8110@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

If os.name == 'nt' is True on IronPython then why not simply do:

    mswindows = sys.platform == "win32" or os.name == "nt"

For the record, both variants are used in different places in cPython source code. It would nice to figure out a golden standard and apply it everywhere. Maybe even add it as a new WINDOWS constant in the platform module.

----------

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

From report at bugs.python.org  Wed Sep  5 05:32:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 09:32:07 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536139927.31.0.56676864532.issue34575@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

REST API for the AppVeyor build cache:
https://www.appveyor.com/docs/build-cache/#rest-api

Authentication of the REST API:
https://www.appveyor.com/docs/api/#authentication

I tried:

$ curl -H "Authorization: Bearer <MY_PRIVATE_TOKEN>" -X "DELETE" https://ci.appveyor.com/api/projects/python/cpython/buildcache; echo

{"message":"You do not have required permissions to perform this action."}

Oh. I'm not allowed to clear the build cache :-(

I'm logged as "python" and my role is "Super User". If a Super User is not allowed to clear the cache, who is allowed to do that? Maybe my URL is wrong? The documentation says:

DELETE https://ci.appveyor.com/api/projects/{accountName}/{projectSlug}/buildcache

----------

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

From report at bugs.python.org  Wed Sep  5 05:46:53 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 05 Sep 2018 09:46:53 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536139927.31.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <CACac1F9J4V7bBP0Gd3V2pZ-5PFQnZA5bax3LczPFvh+WUjX6dg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

I don't see an appveyor.yml file in the CPython repository. How are
the appveyor builds configured? I was going to take a look, but need
to see the config :-(
On Wed, 5 Sep 2018 at 10:32, STINNER Victor <report at bugs.python.org> wrote:
>
>
> STINNER Victor <vstinner at redhat.com> added the comment:
>
> REST API for the AppVeyor build cache:
> https://www.appveyor.com/docs/build-cache/#rest-api
>
> Authentication of the REST API:
> https://www.appveyor.com/docs/api/#authentication
>
> I tried:
>
> $ curl -H "Authorization: Bearer <MY_PRIVATE_TOKEN>" -X "DELETE" https://ci.appveyor.com/api/projects/python/cpython/buildcache; echo
>
> {"message":"You do not have required permissions to perform this action."}
>
> Oh. I'm not allowed to clear the build cache :-(
>
> I'm logged as "python" and my role is "Super User". If a Super User is not allowed to clear the cache, who is allowed to do that? Maybe my URL is wrong? The documentation says:
>
> DELETE https://ci.appveyor.com/api/projects/{accountName}/{projectSlug}/buildcache
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34575>
> _______________________________________

----------

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

From report at bugs.python.org  Wed Sep  5 05:48:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 09:48:04 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536140884.78.0.56676864532.issue34575@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Ah! If I user my personal account which has a different token, I'm able to list my roles using the REST API.

So it seems that I lack some permissions on the "python" account of AppVeyor. Who owns this account?

----------

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

From report at bugs.python.org  Wed Sep  5 05:48:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 09:48:09 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536140889.84.0.56676864532.issue34575@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Another way will be to invalidate the cache by manually updating cleanup-cache.txt in the end. But this requires a commit that has to be reverted later to enable caching and I don't think it's worthy to pollute git history for this.

https://help.appveyor.com/discussions/questions/1310-delete-cache#comment_36916917


> You can have any file as dependency that will be triggering cache invalidation, even "cleanup-cache.txt" say in the root of your repo:
> cache:
>     - my_cached_folder -> cleanup-cache.txt
> Whenever CRC32 of cleanup-cache.txt is changed the cache is invalidated, i.e. not restored in the beginning of the build.

@paul.moore It's here : https://github.com/python/cpython/blob/master/.github/appveyor.yml


Thanks

----------

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

From report at bugs.python.org  Wed Sep  5 05:53:19 2018
From: report at bugs.python.org (pmoravec)
Date: Wed, 05 Sep 2018 09:53:19 +0000
Subject: [issue34566] pipe read sometimes returns EOF but returncode is still
 None
In-Reply-To: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>
Message-ID: <1536141199.42.0.56676864532.issue34566@psf.upfronthosting.co.za>


pmoravec <pmoravec at redhat.com> added the comment:

> The "poll" method does not wait for the child to exit. Normally you use the "wait" method in this situation. I suspect this is a bug in the application, not in Python.

Thanks for clarification. Could you please confirm what code change in that script is safe, then?

1) looping "while p.poll() == None   pass" to really ensure some status is returned.

2) calling p.wait() before p.poll()

>From a blackbox perspective, I would expect either to provide similar fixing mechanism of my script. But as we call this code snippet concurrently, for random commands that randomly terminates with random outcome / status, can't either fix attempt cause e.g. a deadlock?

Thanks in advance for help / advice.

(just for context if it matters: the snippet is from https://github.com/sosreport/sos/blob/master/sos/utilities.py#L158 where the sos_get_command_output method is called concurrently by more threads)

----------
nosy: +pmoravec

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

From report at bugs.python.org  Wed Sep  5 06:00:48 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 10:00:48 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536141648.77.0.56676864532.issue34575@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

One another way will be to set environment variable to skip the cache restore and trigger a build to see if cache is the actual problem. I don't know how configurable environment variables are from the UI to trigger a specific build with the set of environment variable values.

https://www.appveyor.com/docs/build-cache/#skipping-cache-operations-for-specific-build

> Skipping cache operations for specific build

> You can skip cache restore or save stages with the following tweak environment variables:

> APPVEYOR_CACHE_SKIP_RESTORE - set to true to disable cache restore
> APPVEYOR_CACHE_SKIP_SAVE - set to true to disable cache update


Thanks

----------

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

From report at bugs.python.org  Wed Sep  5 06:03:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 10:03:41 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536141821.84.0.56676864532.issue34575@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> APPVEYOR_CACHE_SKIP_RESTORE - set to true to disable cache restore
> APPVEYOR_CACHE_SKIP_SAVE - set to true to disable cache update

I see these as well, but it would only be a temporary solution and may make build much slower, whereas AppVeyor is already a bottleneck in our workflow. AppVeyor only give us two jobs in parallel which take 10-30 min, whereas it's common that we have much more new pull requests per hour.

----------

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

From report at bugs.python.org  Wed Sep  5 06:09:14 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 Sep 2018 10:09:14 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536142154.41.0.56676864532.issue34200@psf.upfronthosting.co.za>


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

My guess as to why we're only seeing this for parallel test cases is taht for sequential tests, the implicit import inside open() is unlikely to happen while test_pkg is running, whereas for parallel tests, test_pkg will run in a relatively pristine process, and hence be more likely to trigger the implicit import.

----------

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

From report at bugs.python.org  Wed Sep  5 06:09:55 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 10:09:55 +0000
Subject: [issue34584] subprocess
In-Reply-To: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>
Message-ID: <1536142195.21.0.56676864532.issue34584@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Might be related to the below : 

open issue : https://bugs.python.org/issue14576

https://bugs.python.org/issue14576
https://bugs.python.org/issue16758
https://bugs.python.org/issue10722
https://bugs.python.org/issue7217

I think from the above threads you have something in path that collides with the name of some file in Python standard library.

Ref : https://stackoverflow.com/questions/29567051/python-error-idles-subprocess-didnt-make-connection-either-idle-cant-start

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Sep  5 06:21:08 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 10:21:08 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536142868.44.0.56676864532.issue34575@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ah ok, I thought disabling the cache with APPVEYOR_CACHE_SKIP_RESTORE as true will trigger a successful build and in the end it will store the new set of artifacts from the recent compiler to the cache and then we can toggle the environment variable (APPVEYOR_CACHE_SKIP_RESTORE) so that for the next build artifacts built from old compiler are replaced with the newer ones resembling a cache clear. Sorry I might be wrong here and it's a workaround that I thought will work as in the other CI systems. I will be happy if it's solved through API then with the right credentials.

Thanks

----------

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

From report at bugs.python.org  Wed Sep  5 06:30:08 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 05 Sep 2018 10:30:08 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536143408.68.0.56676864532.issue34575@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

One thought - appveyor.yml says that the cache of externals depends on PCBuild. Could it be that appveyor is caching PCBuild to verify whether it's changed (and hence whether to use the cached externals)? I know that sounds bizarre, but I'm not entirely sure why externals should be dependent on the *whole* of PCBuild anyway - maybe we should change it to depend only on PCBuild/get_externals.bat?

Clutching at straws here, there's definitely nothing obvious I can see though.

----------

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

From report at bugs.python.org  Wed Sep  5 06:57:22 2018
From: report at bugs.python.org (Ross Burton)
Date: Wed, 05 Sep 2018 10:57:22 +0000
Subject: [issue34585] Don't use AC_RUN_IFELSE to determine float endian
Message-ID: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>


New submission from Ross Burton <ross at burtonini.com>:

Currently configure.ac uses AC_RUN_IFELSE to determine the byte order of floats and doubles.  This hurts when cross-compiling because a default is set, resulting in Python silently falling back to sub-optimal codepaths.

A partial improvement would be to not set a fallback, to force the user to set the right byte order explicitly.

However this test can be done without running anything.  autoconf-archive has a macro that uses a carefully constructed double that encodes to an ASCII string in the binary, which is then examined using grep.  Evil genius.

Attached is a POC using this.  Currently the autoconf-archive macro only handles big and little endian not the ARM OABI mixed-endian format, so configure.ac assumes if the byte order is unknown then it's the crazy mixed-endian.

To be honest OABI is so old now, I don't believe anyone actually uses it anymore: everyone still on ARMv4 should have moved to EABI many years ago, and the mixed-endian support could be removed from Py3 in the future.

----------
components: Build
files: 0001-Don-t-do-runtime-test-to-get-float-byte-order.patch
keywords: patch
messages: 324627
nosy: rossburton
priority: normal
severity: normal
status: open
title: Don't use AC_RUN_IFELSE to determine float endian
versions: Python 3.8
Added file: https://bugs.python.org/file47788/0001-Don-t-do-runtime-test-to-get-float-byte-order.patch

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

From report at bugs.python.org  Wed Sep  5 07:26:26 2018
From: report at bugs.python.org (Joseph)
Date: Wed, 05 Sep 2018 11:26:26 +0000
Subject: [issue34584] subprocess
In-Reply-To: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>
Message-ID: <1536146786.64.0.56676864532.issue34584@psf.upfronthosting.co.za>


Change by Joseph <zengjoseph at hotmail.com>:


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

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

From report at bugs.python.org  Wed Sep  5 07:30:55 2018
From: report at bugs.python.org (Joseph)
Date: Wed, 05 Sep 2018 11:30:55 +0000
Subject: [issue34584] subprocess
In-Reply-To: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>
Message-ID: <1536147055.94.0.56676864532.issue34584@psf.upfronthosting.co.za>


Joseph <zengjoseph at hotmail.com> added the comment:

Problem saved... turns out I saved a math.py file in my python location and thats what cause the crash. when i remove the math.py file or change its name, python got back to work. thanks

----------

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

From report at bugs.python.org  Wed Sep  5 07:39:06 2018
From: report at bugs.python.org (Fredrik Larsen)
Date: Wed, 05 Sep 2018 11:39:06 +0000
Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 )
In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>
Message-ID: <1536147546.72.0.56676864532.issue7727@psf.upfronthosting.co.za>


Change by Fredrik Larsen <fredrik.h.larsen at gmail.com>:


----------
nosy: +fredrikhl

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

From report at bugs.python.org  Wed Sep  5 08:04:49 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 Sep 2018 12:04:49 +0000
Subject: [issue34584] subprocess
In-Reply-To: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>
Message-ID: <1536149089.65.0.56676864532.issue34584@psf.upfronthosting.co.za>


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

I'm not to happy about the crash, the interpreter shouldn't crash like this. This may well be Tk related though.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> pending
type:  -> crash

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

From report at bugs.python.org  Wed Sep  5 08:29:35 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 05 Sep 2018 12:29:35 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1536150575.78.0.56676864532.issue34481@psf.upfronthosting.co.za>


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

I've left a mostly finished PR on #8983, but I've decided it's not really worth continuing to work on. Anyone can feel free to take it and run with it if they want to implement the fix for this.

As Alexey mentions, that PR indeed already fixes this bug, I mainly blocked on getting consistent behavior across all platforms. Currently that PR has consistent behavior across all platforms if you disable wcsftime *except* Ubuntu 14.0, which seems to have some kind of funky bug in wcstombs, though for the life of me I don't know how to consistently trigger it. I suspect that using strftime instead of wcsftime on all platforms would lead to simpler code that works most consistently, but I am guessing wcsftime is faster.

Another option is to use wsftime but fall back to strftime on MacOS in the event that the error condition (blank output from non-blank input) is detected.

----------

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

From report at bugs.python.org  Wed Sep  5 08:48:23 2018
From: report at bugs.python.org (Nikita Velykanov)
Date: Wed, 05 Sep 2018 12:48:23 +0000
Subject: [issue34577] imaplib Cyrillic password
In-Reply-To: <1536070305.76.0.56676864532.issue34577@psf.upfronthosting.co.za>
Message-ID: <1536151703.23.0.56676864532.issue34577@psf.upfronthosting.co.za>


Nikita Velykanov <nvelykanov at jerasoft.net> added the comment:

It works. Thanks a lot!

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

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

From report at bugs.python.org  Wed Sep  5 09:51:03 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Sep 2018 13:51:03 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536155463.31.0.56676864532.issue34575@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Wed Sep  5 10:00:10 2018
From: report at bugs.python.org (Zahari Dim)
Date: Wed, 05 Sep 2018 14:00:10 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
Message-ID: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>


New submission from Zahari Dim <zaharid at gmail.com>:

When using ChainMap I have frequently needed to know the mapping inside the list
that contains the effective instance of a particular key. I have needed this
when using ChainMap to contain a piece of configuration with multiple sources,
like for example

```
from mycollections import ChainMap
configsources = ["Command line", "Config file", "Defaults"]
config = ChainMap(config_from_commandline(), config_from_file(),
                  default_config())

class BadConfigError(Exception): pass
def get_key(key):
    try:
        index, value = config.get_where(key)
    except KeyError as e:
        raise BadConfigError(f"No such key: '{key}'") from e
    try:
        result = validate(key, value)
    except ValidationError as e:
        raise BadConfigError(f"Key '{key}' defined in {configsources[index] }"
                             f"is invalid: {e}") from e
    return result
```

I have also needed this when implementing custom DSLs (e.g. specifying which
context is a particular construct allowed to see).

I think this method would be generally useful for the ChainMap class and
moreover the best way of implementing it I can think of is  by copying the
`__getitem__` method and retaining the index:

```
class ChainMap(collections.ChainMap):
    def get_where(self, key):
        for i, mapping in enumerate(self.maps):
            try:
                return i, mapping[key]             # can't use 'key in mapping' with defaultdict
            except KeyError:
                pass
        return self.__missing__(key)            # support subclasses that define __missing__
```

I'd be happy to write a patch that does just this.

----------
components: Library (Lib)
messages: 324632
nosy: Zahari.Dim
priority: normal
severity: normal
status: open
title: collections.ChainMap should have a get_where method
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  5 10:09:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:09:11 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536156551.12.0.56676864532.issue34575@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Discussion on python-dev:
https://mail.python.org/pipermail/python-dev/2018-September/155075.html

----------

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

From report at bugs.python.org  Wed Sep  5 10:35:57 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 05 Sep 2018 14:35:57 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1536158157.36.0.56676864532.issue34568@psf.upfronthosting.co.za>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

Thanks for the PEP-560 reference. It explains the reasoning for the underlying changes, performance, and also mentions backwards incompatibility problems, including `issubclass(List[int], List)` causing a TypeError. It doesn't mention that `issubclass(List, list)` also raises a TypeError, though, nor that `isinstance(List, type)` now returns False.

I understand changing the implementation for performance reason, but I don't understand why that would require changing the behavior of `isinstance` and `issubclass`. The PEP explicitly mentions that the new `types.resolved_base` isn't called by them without explaining why. I guess that could be for performance reasons, but even then types in the typing could themselves implement `__instancecheck__` and `__subclasscheck__` and retain the old behavior. Or is there some actual reason for changing the behavior?

----------

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

From report at bugs.python.org  Wed Sep  5 10:42:56 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Sep 2018 14:42:56 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1536158576.31.0.56676864532.issue34575@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset 635461fca5e90c6e091f1e5b46adafc0d28bf0e2 by Zachary Ware in branch '3.6':
[3.6] bpo-34575: Build with only VS2015 on AppVeyor (GH-9066)
https://github.com/python/cpython/commit/635461fca5e90c6e091f1e5b46adafc0d28bf0e2


----------

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

From report at bugs.python.org  Wed Sep  5 10:44:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:44:48 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536158688.13.0.56676864532.issue34530@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8531

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

From report at bugs.python.org  Wed Sep  5 10:45:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:45:11 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536158711.54.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset e2c1657dff86decf1e232b66e766d2e51381109c by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-34530: Fix distutils find_executable() (GH-9049) (GH-9057)
https://github.com/python/cpython/commit/e2c1657dff86decf1e232b66e766d2e51381109c


----------

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

From report at bugs.python.org  Wed Sep  5 10:46:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:46:01 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536158761.08.0.56676864532.issue26544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1a3eb125dc07a28a5af62446778ed7cca95ed3da by Victor Stinner (Miss Islington (bot)) in branch '3.6':
[3.7] bpo-26544: Get rid of dependence from distutils in platform. (GH-8356) (GH-8970) (GH-9061)
https://github.com/python/cpython/commit/1a3eb125dc07a28a5af62446778ed7cca95ed3da


----------

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

From report at bugs.python.org  Wed Sep  5 10:46:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:46:29 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536158789.29.0.56676864532.issue26544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 9734024ec65311e33936faa83fb1cb249ef0de9d by Victor Stinner (Miss Islington (bot)) in branch '2.7':
bpo-26544: Get rid of dependence from distutils in platform. (GH-8356) (GH-8952)
https://github.com/python/cpython/commit/9734024ec65311e33936faa83fb1cb249ef0de9d


----------

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

From report at bugs.python.org  Wed Sep  5 10:46:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:46:55 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536158815.65.0.56676864532.issue26544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks everybody! The issue should now be fixed in all supported branches ;-)

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

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

From report at bugs.python.org  Wed Sep  5 10:48:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 14:48:46 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1536158926.47.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I chose to merge the simplest change:

-        path = os.environ['PATH']
+        path = os.environ.get('PATH', os.defpath)

And I added unit tests for find_executable(). The bug is now fixed.

I'm not longer interested to reuse shutil.which() in distutils.find_executable(), since find_executable() first checks if the executable is in the current directory.

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

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

From report at bugs.python.org  Wed Sep  5 10:53:03 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Sep 2018 14:53:03 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536159183.8.0.56676864532.issue8110@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

The real question isn't "are we on Windows?" but rather "should we use msvcrt/_winapi or _posixsubprocess/select?", which is what my PR is designed to better fit.  I could see how we wouldn't want to backport that patch to maintenance branches, though; it's a significant rearrangement.  If we do want to backport *a* fix, I agree that simply adding `or os.name == 'nt'` should be sufficiently low-impact.

----------

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

From report at bugs.python.org  Wed Sep  5 10:58:12 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 05 Sep 2018 14:58:12 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1536159492.14.0.56676864532.issue34568@psf.upfronthosting.co.za>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

While studying the types in the typing module more, I noticed they have a special `__origin__` attribute which seems to contain the "real" type they represent. I was able to make my type conversion code to work by adding these lines:

    if hasattr(type_, '__origin__'):
        type_ = type_.__origin__

All our tests pass with this simple fix, but I'm slightly worried using it because `__origin__` doesn't seem to be documented. This means I'm not sure is my usage OK and, more importantly, makes me worried that another change in typing changes the behavior or removes the attribute altogether. Hopefully someone with more insight on this can comment my worries. Perhaps the attribute should also be documented as discussed earlier: https://github.com/python/typing/issues/335

I'd also be a little bit happier with the above fix if I could write it like

    if isinstance(type_, typing.SomeBaseType):
        type_ = type_.__origin__

but apparently types in the typing module don't have any public base class. I guess odds that some unrelated class would have `__origin__` defined is small enough that using `hasattr(type_, '__origin__')` is safe.

----------

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

From report at bugs.python.org  Wed Sep  5 11:01:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 15:01:19 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
Message-ID: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Hi,

test_socket started to hang recently on my Fedora 28 laptop. No idea why it started to hang.

vstinner at apu$ ./python -m test -v test_socket -m testCongestion --timeout=5
== CPython 3.8.0a0 (heads/master-dirty:39487196c8, Sep 4 2018, 23:08:20) [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)]
== Linux-4.17.19-200.fc28.x86_64-x86_64-with-glibc2.26 little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_29510
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.34 [1/1] test_socket
testCongestion (test.test_socket.RDSTest) ... Timeout (0:00:05)!
Thread 0x00007fccf51b1700 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 2074 in _testCongestion
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 332 in clientRun

Thread 0x00007fcd082ee080 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/threading.py", line 296 in wait
  File "/home/vstinner/prog/python/master/Lib/threading.py", line 552 in wait
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 2059 in testCongestion
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 610 in run
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 658 in __call__
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/prog/python/master/Lib/unittest/runner.py", line 176 in run
  File "/home/vstinner/prog/python/master/Lib/test/support/__init__.py", line 1900 in _run_suite
  File "/home/vstinner/prog/python/master/Lib/test/support/__init__.py", line 1990 in run_unittest
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 6032 in test_main
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/runtest.py", line 179 in runtest_inner
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 384 in run_tests_sequential
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 488 in run_tests
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 566 in _main
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 531 in main
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 584 in main
  File "/home/vstinner/prog/python/master/Lib/test/__main__.py", line 2 in <module>
  File "/home/vstinner/prog/python/master/Lib/runpy.py", line 85 in _run_code
  File "/home/vstinner/prog/python/master/Lib/runpy.py", line 193 in _run_module_as_main

----------
components: Tests
messages: 324643
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_socket: testCongestion() hangs on my Fedora 28
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  5 05:10:46 2018
From: report at bugs.python.org (Joseph)
Date: Wed, 05 Sep 2018 09:10:46 +0000
Subject: [issue34584] subprocess
Message-ID: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>


New submission from Joseph <zengjoseph at hotmail.com>:

Every time IDLE is opened this message "IDLE's subprocess didn't make connection.  Either IDLE can't start a subprocess or personal firewall software is blocking the connection" shows up.
When I open IDLE through .py programs the app crashes
crash code:
Process:               Python [5021]
Path:                  /Applications/Python 3.7/IDLE.app/Contents/MacOS/Python
Identifier:            org.python.IDLE
Version:               3.7.0 (3.7.0)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Python [5021]
User ID:               501

Date/Time:             2018-09-05 17:09:24.893 +0800
OS Version:            Mac OS X 10.13.4 (17E199)
Report Version:        12
Anonymous UUID:        01609E2F-27A5-CB5F-4612-5BA977830EA2

Sleep/Wake UUID:       30FAEA7D-EBF8-44D0-AE53-A40B0636777A

Time Awake Since Boot: 87000 seconds
Time Since Wake:       510 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace OBJC, Code 0x1

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x0000000101922ed6 __abort_with_payload + 10
1   libsystem_kernel.dylib        	0x000000010191d2cf abort_with_payload_wrapper_internal + 89
2   libsystem_kernel.dylib        	0x000000010191d276 abort_with_reason + 22
3   libobjc.A.dylib               	0x0000000100e16962 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 108
4   libobjc.A.dylib               	0x0000000100e16814 _objc_fatal(char const*, ...) + 135
5   libobjc.A.dylib               	0x0000000100e21f63 (anonymous namespace)::AutoreleasePoolPage::busted(bool) + 123
6   libobjc.A.dylib               	0x0000000100e09da5 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 79
7   com.apple.CoreFoundation      	0x0000000100047a56 _CFAutoreleasePoolPop + 22
8   com.apple.Foundation          	0x0000000103ee28ad -[NSAutoreleasePool drain] + 144
9   com.apple.Foundation          	0x0000000103f165a4 _NSAppleEventManagerGenericHandler + 120
10  com.apple.AE                  	0x000000010a9ccdd0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788
11  com.apple.AE                  	0x000000010a9cc677 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41
12  com.apple.AE                  	0x000000010a9cc565 aeProcessAppleEvent + 383
13  com.apple.HIToolbox           	0x00000001078ad4a0 AEProcessAppleEvent + 55
14  com.apple.AppKit              	0x00000001045e1d32 _DPSNextEvent + 2788
15  com.apple.AppKit              	0x0000000104d77e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
16  libtk8.6.dylib                	0x0000000103d4594a -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 44
17  com.apple.AppKit              	0x0000000104813e7b -[NSApplication _doModalLoop:peek:] + 476
18  com.apple.AppKit              	0x00000001049f8c9f __35-[NSApplication runModalForWindow:]_block_invoke_2 + 64
19  com.apple.AppKit              	0x00000001049f8c4c __35-[NSApplication runModalForWindow:]_block_invoke + 75
20  com.apple.AppKit              	0x0000000104ea7219 _NSTryRunModal + 100
21  com.apple.AppKit              	0x0000000104811911 -[NSApplication runModalForWindow:] + 133
22  com.apple.AppKit              	0x00000001049e6eab __19-[NSAlert runModal]_block_invoke_2 + 158
23  com.apple.AppKit              	0x00000001049e6dfa __19-[NSAlert runModal]_block_invoke + 75
24  com.apple.AppKit              	0x0000000104ea7219 _NSTryRunModal + 100
25  com.apple.AppKit              	0x0000000104886609 -[NSAlert runModal] + 124
26  libtk8.6.dylib                	0x0000000103d32f31 Tk_MessageBoxObjCmd + 2098
27  libtcl8.6.dylib               	0x0000000103b12f08 TclNRRunCallbacks + 58
28  _tkinter.cpython-37m-darwin.so	0x0000000101beebf7 Tkapp_Call + 183
29  org.python.python             	0x000000010077aa7b cfunction_call_varargs + 299
30  org.python.python             	0x0000000100856376 _PyEval_EvalFrameDefault + 28614
31  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
32  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
33  org.python.python             	0x000000010084f04f call_function + 671
34  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
35  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
36  org.python.python             	0x000000010077a795 _PyFunction_FastCallDict + 469
37  org.python.python             	0x0000000100851eb4 _PyEval_EvalFrameDefault + 11012
38  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
39  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
40  org.python.python             	0x000000010084f04f call_function + 671
41  org.python.python             	0x0000000100854a78 _PyEval_EvalFrameDefault + 22216
42  org.python.python             	0x000000010077a367 function_code_fastcall + 135
43  org.python.python             	0x000000010084f04f call_function + 671
44  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
45  org.python.python             	0x000000010077a367 function_code_fastcall + 135
46  org.python.python             	0x000000010084f04f call_function + 671
47  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
48  org.python.python             	0x000000010077a367 function_code_fastcall + 135
49  org.python.python             	0x000000010084f04f call_function + 671
50  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
51  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
52  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
53  org.python.python             	0x000000010084f04f call_function + 671
54  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
55  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
56  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
57  org.python.python             	0x000000010084f04f call_function + 671
58  org.python.python             	0x0000000100851843 _PyEval_EvalFrameDefault + 9363
59  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
60  org.python.python             	0x000000010084e904 PyEval_EvalCode + 100
61  org.python.python             	0x0000000100894d8e PyRun_FileExFlags + 206
62  org.python.python             	0x000000010089502f PyRun_SimpleFileExFlags + 447
63  org.python.python             	0x00000001008b376d pymain_main + 2733
64  org.python.python             	0x00000001008b3afa _Py_UnixMain + 218
65  Python                        	0x0000000100000f14 0x100000000 + 3860

Thread 1:
0   libsystem_kernel.dylib        	0x0000000101924292 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x000000010195a20e _pthread_wqthread + 1552
2   libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 2:
0   libsystem_kernel.dylib        	0x0000000101924292 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x000000010195a009 _pthread_wqthread + 1035
2   libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 3:
0   libsystem_kernel.dylib        	0x0000000101923cfa __select + 10
1   libtcl8.6.dylib               	0x0000000103c064c7 NotifierThreadProc + 558
2   libsystem_pthread.dylib       	0x000000010195a661 _pthread_body + 340
3   libsystem_pthread.dylib       	0x000000010195a50d _pthread_start + 377
4   libsystem_pthread.dylib       	0x0000000101959bf9 thread_start + 13

Thread 4:
0   libsystem_kernel.dylib        	0x0000000101924292 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x000000010195a20e _pthread_wqthread + 1552
2   libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 5:: Dispatch queue: NSCGSDisableUpdates
0   libsystem_kernel.dylib        	0x000000010191a20a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x0000000101919724 mach_msg + 60
2   com.apple.SkyLight            	0x00000001069ab9f5 CGSUpdateManager::enable_updates_common() + 565
3   com.apple.SkyLight            	0x000000010694fb28 CGSUpdateManager::enable_update(unsigned long long) + 320
4   libdispatch.dylib             	0x00000001014a964a _dispatch_call_block_and_release + 12
5   libdispatch.dylib             	0x00000001014a1e08 _dispatch_client_callout + 8
6   libdispatch.dylib             	0x00000001014b6267 _dispatch_queue_serial_drain + 635
7   libdispatch.dylib             	0x00000001014a91b6 _dispatch_queue_invoke + 373
8   libdispatch.dylib             	0x00000001014b6f5d _dispatch_root_queue_drain_deferred_wlh + 332
9   libdispatch.dylib             	0x00000001014bad71 _dispatch_workloop_worker_thread + 880
10  libsystem_pthread.dylib       	0x0000000101959fd2 _pthread_wqthread + 980
11  libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 6:
0   libsystem_pthread.dylib       	0x0000000101959bdc start_wqthread + 0
1   ???                           	0x0004000200080003 0 + 1125908497301507

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000002000209  rbx: 0x0000000000000001  rcx: 0x00007fff5bffba98  rdx: 0x0000000000000000
  rdi: 0x0000000000000008  rsi: 0x0000000000000001  rbp: 0x00007fff5bffbaf0  rsp: 0x00007fff5bffba98
   r8: 0x000000011583b040   r9: 0x0000000000000080  r10: 0x0000000000000000  r11: 0x0000000000000246
  r12: 0x0000000000000000  r13: 0x0000000000000000  r14: 0x0000000000000008  r15: 0x0000000000000080
  rip: 0x0000000101922ed6  rfl: 0x0000000000000246  cr2: 0x0000000116d88000
  
Logical CPU:     0
Error Code:      0x02000209
Trap Number:     133


Binary Images:
       0x100000000 -        0x100000fff +Python (???) <772D781E-3DF3-3A7E-9620-5A4CAE438B7B> /Applications/Python 3.7/IDLE.app/Contents/MacOS/Python
       0x100003000 -        0x1004a4fef  com.apple.CoreFoundation (6.9 - 1452.23) <945E5C0A-86C5-336E-A64F-5BF06E78985A> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x100757000 -        0x1009a1ff7 +org.python.python (3.7.0, [c] 2001-2018 Python Software Foundation. - 3.7.0) <8D0890E3-4550-11C2-704A-D0571C9442A8> /Library/Frameworks/Python.framework/Versions/3.7/Python
       0x100af8000 -        0x100af9ffb  libSystem.B.dylib (1252.50.4) <C7810EA7-A61F-3817-8E54-E2EC4E26F946> /usr/lib/libSystem.B.dylib
       0x100b00000 -        0x100b01ff3  libDiagnosticMessagesClient.dylib (104) <9712E980-76EE-3A89-AEA6-DF4BAF5C0574> /usr/lib/libDiagnosticMessagesClient.dylib
       0x100b07000 -        0x100d2effb  libicucore.A.dylib (59173.0.1) <CECAD5E5-3EFD-3AAC-AD9B-E355B2DD5E9C> /usr/lib/libicucore.A.dylib
       0x100e00000 -        0x1011ee7e7  libobjc.A.dylib (723) <DD9E5EC5-B507-3249-B700-93433E2D5EDF> /usr/lib/libobjc.A.dylib
       0x10139f000 -        0x1013b1ffb  libz.1.dylib (70) <48C67CFC-940D-3857-8DAD-857774605352> /usr/lib/libz.1.dylib
       0x1013b7000 -        0x1013bbff7  libcache.dylib (80) <092479CB-1008-3A83-BECF-E115F24D13C1> /usr/lib/system/libcache.dylib
       0x1013c1000 -        0x1013cbff3  libcommonCrypto.dylib (60118.50.1) <029F5985-9B6E-3DCB-9B96-FD007678C6A7> /usr/lib/system/libcommonCrypto.dylib
       0x1013d9000 -        0x1013e0fff  libcompiler_rt.dylib (62) <968B8E3F-3681-3230-9D78-BB8732024F6E> /usr/lib/system/libcompiler_rt.dylib
       0x1013ee000 -        0x1013f7ffb  libcopyfile.dylib (146.50.5) <3885083D-50D8-3EEC-B481-B2E605180D7F> /usr/lib/system/libcopyfile.dylib
       0x1013fe000 -        0x101483fff  libcorecrypto.dylib (562.50.17) <67007279-24E1-3F30-802D-A55CD5C27946> /usr/lib/system/libcorecrypto.dylib
       0x1014a0000 -        0x1014d9ff7  libdispatch.dylib (913.50.12) <848EEE57-4235-3A61-9A52-C0097DD2AB5E> /usr/lib/system/libdispatch.dylib
       0x101514000 -        0x101531ff7  libdyld.dylib (551.3) <CF59A5A5-288B-30E6-BD42-9056B4E4139A> /usr/lib/system/libdyld.dylib
       0x10154c000 -        0x10154cffb  libkeymgr.dylib (28) <E34E283E-90FA-3C59-B48E-1277CDB9CDCE> /usr/lib/system/libkeymgr.dylib
       0x101551000 -        0x101551ff7  liblaunch.dylib (1205.50.76) <4D52BB64-C568-3A36-8935-2480427EE2A2> /usr/lib/system/liblaunch.dylib
       0x101558000 -        0x10155cffb  libmacho.dylib (906) <1902A611-081A-3452-B11E-EBD1B166E831> /usr/lib/system/libmacho.dylib
       0x101563000 -        0x101565ff3  libquarantine.dylib (86) <26C0BA22-8F93-3A07-9A4E-C8D53D2CE42E> /usr/lib/system/libquarantine.dylib
       0x10156c000 -        0x10156dff3  libremovefile.dylib (45) <711E18B2-5BBE-3211-A916-56740C27D17A> /usr/lib/system/libremovefile.dylib
       0x101573000 -        0x10158afff  libsystem_asl.dylib (356.50.1) <3B24F2D1-B578-359D-ADB2-0ED19A364C38> /usr/lib/system/libsystem_asl.dylib
       0x101598000 -        0x101598fff  libsystem_blocks.dylib (67) <17303FDF-0D2D-3963-B05E-B4DF63052D47> /usr/lib/system/libsystem_blocks.dylib
       0x10159d000 -        0x101626ff7  libsystem_c.dylib (1244.50.9) <1187BFE8-4576-3247-8177-481554E1F9E7> /usr/lib/system/libsystem_c.dylib
       0x10164f000 -        0x101652ffb  libsystem_configuration.dylib (963.50.8) <DF6B5287-203E-30CB-9947-78DF446C72B8> /usr/lib/system/libsystem_configuration.dylib
       0x101659000 -        0x10165cffb  libsystem_coreservices.dylib (51) <486000D3-D8CB-3BE7-8EE5-8BF380DE6DF7> /usr/lib/system/libsystem_coreservices.dylib
       0x101662000 -        0x101663fff  libsystem_darwin.dylib (1244.50.9) <09C21A4A-9EE0-388B-A9D9-DFF8F6758791> /usr/lib/system/libsystem_darwin.dylib
       0x101669000 -        0x10166fff7  libsystem_dnssd.dylib (878.50.17) <9033B909-BCF7-37EB-A040-ADE8081611D6> /usr/lib/system/libsystem_dnssd.dylib
       0x101676000 -        0x1016bfff7  libsystem_info.dylib (517.30.1) <AB634A98-B8AA-3804-8436-38261FC8EC4D> /usr/lib/system/libsystem_info.dylib
       0x1016d7000 -        0x101722fcb  libsystem_m.dylib (3147.50.1) <FC2E58BA-E6D5-3D2A-89CA-67F212294136> /usr/lib/system/libsystem_m.dylib
       0x101731000 -        0x101750fff  libsystem_malloc.dylib (140.50.6) <7FD43735-9DDD-300E-8C4A-F909A74BDF49> /usr/lib/system/libsystem_malloc.dylib
       0x10175d000 -        0x10188dff3  libsystem_network.dylib (1229.51.2) <F65ED095-8ABA-3355-93F8-B9D0505932F4> /usr/lib/system/libsystem_network.dylib
       0x1018ce000 -        0x1018d8ffb  libsystem_networkextension.dylib (767.50.25) <758F1414-796D-3422-83C9-92D2915A06CE> /usr/lib/system/libsystem_networkextension.dylib
       0x1018e5000 -        0x1018eeff3  libsystem_notify.dylib (172) <08012EC0-2CD2-34BE-BF93-E7F56491299A> /usr/lib/system/libsystem_notify.dylib
       0x1018f6000 -        0x1018f9fff  libsystem_sandbox.dylib (765.50.51) <B48D256E-D7DB-3D4F-BC95-34557170C7AA> /usr/lib/system/libsystem_sandbox.dylib
       0x101900000 -        0x101901ff3  libsystem_secinit.dylib (30) <DE8D14E8-A276-3FF8-AE13-77F7040F33C1> /usr/lib/system/libsystem_secinit.dylib
       0x101907000 -        0x10192dff7  libsystem_kernel.dylib (4570.51.1) <5CAAB092-02CC-3A37-9D5F-C4AD1083AB96> /usr/lib/system/libsystem_kernel.dylib
       0x101947000 -        0x10194eff7  libsystem_platform.dylib (161.50.1) <6355EE2D-5456-3CA8-A227-B96E8F1E2AF8> /usr/lib/system/libsystem_platform.dylib
       0x101957000 -        0x101962fff  libsystem_pthread.dylib (301.50.1) <0E51CCBA-91F2-34E1-BF2A-FEEFD3D321E4> /usr/lib/system/libsystem_pthread.dylib
       0x10196f000 -        0x101976ff7  libsystem_symptoms.dylib (820.50.37) <ED7350E0-B68B-374A-9AB7-DC1F195A8327> /usr/lib/system/libsystem_symptoms.dylib
       0x10197d000 -        0x101990fff  libsystem_trace.dylib (829.50.17) <6568D68B-1D4C-38EE-90A9-54821D6403C0> /usr/lib/system/libsystem_trace.dylib
       0x10199f000 -        0x1019a4ff7  libunwind.dylib (35.3) <BEF3FB49-5604-3B5F-82B5-332B80023AC3> /usr/lib/system/libunwind.dylib
       0x1019ac000 -        0x1019d9fff  libxpc.dylib (1205.50.76) <25DB244E-217D-3CE0-A8F2-0C4255783B42> /usr/lib/system/libxpc.dylib
       0x1019fc000 -        0x101a2fff7  libclosured.dylib (551.3) <DC3DA678-9C40-339C-A9C6-32AB74FCC682> /usr/lib/closure/libclosured.dylib
       0x101a4b000 -        0x101a6fff7  libc++abi.dylib (400.8.2) <EF5E37D7-11D9-3530-BE45-B986612D13E2> /usr/lib/libc++abi.dylib
       0x101a7f000 -        0x101ad5fff  libc++.1.dylib (400.9) <7D3DACCC-3804-393C-ABC1-1A580FD00CB6> /usr/lib/libc++.1.dylib
       0x101be8000 -        0x101bf0ff7 +_tkinter.cpython-37m-darwin.so (???) <DE56789A-8D90-430A-22B2-784218C38568> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_tkinter.cpython-37m-darwin.so
       0x101bfa000 -        0x101bfafff  com.apple.Cocoa (6.11 - 22) <4CF8E31C-B5C7-367B-B73D-1A8AC8E41B7F> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
       0x101fe0000 -        0x101fe0fff  com.apple.Carbon (158 - 158) <F8B370D9-2103-3276-821D-ACC756167F86> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
       0x101fe4000 -        0x101fe4fff  com.apple.CoreServices (822.31 - 822.31) <615919A2-AE11-3F27-9A37-FB0CFF8D36B6> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
       0x101fe9000 -        0x101fe9fff  com.apple.ApplicationServices (48 - 50) <8DA47D38-B07B-3AE2-B343-4579864430C6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
       0x101fed000 -        0x101fedfff  libenergytrace.dylib (16) <A92AB8B8-B986-3CE6-980D-D55090FEF387> /usr/lib/libenergytrace.dylib
       0x101ff2000 -        0x101ff6ffb  libScreenReader.dylib (562.18.4) <E239923D-54C9-3BBF-852F-87C09DEF4091> /usr/lib/libScreenReader.dylib
       0x103951000 -        0x103974ffb  com.apple.RemoteViewServices (2.0 - 125) <592323D1-CB44-35F1-9921-4C2AB8D920A0> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
       0x10399c000 -        0x1039abff7  com.apple.framework.DFRFoundation (1.0 - 191.7) <3B8ED6F7-5DFF-34C3-BA90-DDB85679684C> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation
       0x1039be000 -        0x1039befff  com.apple.Accelerate (1.11 - Accelerate 1.11) <8632A9C5-19EA-3FD7-A44D-80765CC9C540> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
       0x1039c2000 -        0x1039c9ffb  com.apple.IOSurface (211.12 - 211.12) <392CA7DE-B365-364E-AF4A-33EC2CC48E6F> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
       0x1039d8000 -        0x1039d8fff  com.apple.audio.units.AudioUnit (1.14 - 1.14) <513C9A4B-4F6D-3A21-921F-2CA101B97830> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
       0x1039e3000 -        0x1039e4ff7  com.apple.performance.SignpostNotification (1.2.4 - 2.4) <9957B2C0-4D48-3337-8A4D-5E457CC7B542> /System/Library/PrivateFrameworks/SignpostNotification.framework/Versions/A/SignpostNotification
       0x1039eb000 -        0x1039f1fff  com.apple.speech.recognition.framework (6.0.3 - 6.0.3) <2ED8643D-B0C3-3F17-82A2-BBF13E6CBABC> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
       0x1039fb000 -        0x1039fbfff  libOpenScriptingUtil.dylib (174) <610F0242-7CE5-3C86-951B-B646562694AF> /usr/lib/libOpenScriptingUtil.dylib
       0x103b00000 -        0x103c48fef +libtcl8.6.dylib (8.6.8 - 8.6.8) <59169476-3443-1D5C-BC78-58A1A2DB71AD> /Library/Frameworks/Python.framework/Versions/3.7/lib/libtcl8.6.dylib
       0x103c7a000 -        0x103d95fe7 +libtk8.6.dylib (8.6.8 - 8.6.8) <6EA5315E-A60D-EC83-B930-17671B128CE7> /Library/Frameworks/Python.framework/Versions/3.7/lib/libtk8.6.dylib
       0x103de9000 -        0x103e84ff7  com.apple.framework.IOKit (2.0.2 - 1445.50.26) <A63CAC8D-BF57-34FD-9A88-2F74546F2000> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
       0x103ecd000 -        0x104293fff  com.apple.Foundation (6.9 - 1452.23) <E64540AD-1755-3C16-8537-552A00E92541> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
       0x1045a0000 -        0x1053fefff  com.apple.AppKit (6.9 - 1561.40.112) <C839B0C1-F7EE-3056-985C-63CF1A030EC4> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
       0x105e5e000 -        0x1061b4fef  com.apple.CoreData (120 - 851) <A2B59780-FB16-36A3-8EE0-E0EF072454E0> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
       0x106364000 -        0x106513fff  com.apple.UIFoundation (1.0 - 547.3) <ACC12DF5-E528-33F3-A358-4E1BEA68239C> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
       0x1065f3000 -        0x106674ff7  com.apple.Metal (125.25 - 125.25) <B2ECA050-4C13-3EAD-A1C8-AC21EFF122F1> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
       0x10676a000 -        0x106899fff  com.apple.desktopservices (1.12.4 - 1.12.4) <47C3FBF3-5E75-3821-B003-2A4DC3657D8D> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
       0x10693e000 -        0x106bdafff  com.apple.SkyLight (1.600.0 - 312.50) <0CF4C608-8748-32BF-9586-A1601945F82C> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
       0x106cbc000 -        0x1072ccfef  com.apple.CoreGraphics (2.0 - 1161.10) <31C36FA0-4026-3347-93FD-71CD7287A6F0> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
       0x1073e9000 -        0x107676ff7  com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <87D81714-F167-39F5-B5E7-A7A432EDAB5B> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
       0x1077b5000 -        0x10782bfff  com.apple.datadetectorscore (7.0 - 590.3) <83E85A62-44A8-33F8-AD79-AC4C807184C4> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
       0x10786e000 -        0x107b73fff  com.apple.HIToolbox (2.1.1 - 911.10) <BF7F9C0E-C732-3FB2-9BBC-362888BDA57B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
       0x107d00000 -        0x107f4bff7  com.apple.QuartzCore (1.11 - 584.40) <ABC7F8FA-5F5A-31F4-868B-FDC4175BAFAC> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
       0x10803c000 -        0x108364fff  com.apple.security (7.0 - 58286.51.6) <7212D257-5324-3DBA-8C26-504D6B8F632A> /System/Library/Frameworks/Security.framework/Versions/A/Security
       0x10853b000 -        0x10853bff3  libauto.dylib (187) <A05C7900-F8C7-3E75-8D3F-909B40C19717> /usr/lib/libauto.dylib
       0x108541000 -        0x108628fff  libxml2.2.dylib (31.10) <503721DB-0D8D-379E-B743-18CE59304155> /usr/lib/libxml2.2.dylib
       0x108661000 -        0x108795fff  com.apple.coreui (2.1 - 494.1) <19624CAA-74DE-3DD3-9585-E64BE866EBFF> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
       0x108969000 -        0x1089fcff7  com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <6E3F958D-79BB-3658-99AD-59F16BF756F1> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
       0x108a2a000 -        0x108a2ffff  com.apple.DiskArbitration (2.7 - 2.7) <A6450227-DD23-3100-ADBF-DB1C21E979F7> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
       0x108a3a000 -        0x108a3bfff  liblangid.dylib (128) <39C39393-0D05-301D-93B2-F224FC4949AA> /usr/lib/liblangid.dylib
       0x108a40000 -        0x108a6affb  com.apple.MultitouchSupport.framework (1404.4 - 1404.4) <45374A2A-C0BC-3A70-8183-37295205CDFA> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
       0x108a7f000 -        0x108a8fffb  com.apple.PerformanceAnalysis (1.194 - 194) <D0211AD1-72B3-3493-92C9-B4F40ED581D5> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
       0x108aac000 -        0x108abbfff  com.apple.opengl (16.5.10 - 16.5.10) <BC4EEFE3-A09B-3998-B723-1415B995B0EE> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
       0x108ac6000 -        0x108b7ffff  com.apple.ColorSync (4.13.0 - 3325) <D283C285-447D-3258-A7E4-59532123B8FF> /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync
       0x108bcc000 -        0x108ebbfff  com.apple.CoreImage (13.0.0 - 579.4.11) <702F8035-26FE-3C78-8587-4C9563E03CC4> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
       0x10905c000 -        0x1091acfff  com.apple.CoreText (352.0 - 578.18) <B8454115-2A4B-3585-A7A1-B47A638F2EEB> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
       0x109276000 -        0x1093effe7  com.apple.ImageIO.framework (3.3.0 - 1739.1) <E5E88083-26A7-3E48-8EB4-A1F04E0737CE> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
       0x1094a4000 -        0x10952bff7  com.apple.backup.framework (1.9.5 - 1.9.5) <BC020BDD-7C93-37E5-A762-4FDCBD2056A8> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
       0x10959c000 -        0x1095c6ff3  libarchive.2.dylib (54) <8FC28DD8-E315-3C3E-95FE-D1D2CBE49888> /usr/lib/libarchive.2.dylib
       0x1095d1000 -        0x10996bff7  com.apple.CFNetwork (897.15 - 897.15) <0C03AF39-3527-3E0D-8413-8E1B2A962F0D> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
       0x109c97000 -        0x109d07ff3  com.apple.SystemConfiguration (1.17 - 1.17) <8532B8E9-7E30-35A3-BC4A-DDE8E0614FDA> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
       0x109d3f000 -        0x109d78ff7  libCRFSuite.dylib (41) <FE5EDB68-2593-3C2E-BBAF-1C52D206F296> /usr/lib/libCRFSuite.dylib
       0x109d92000 -        0x109da2ff3  libbsm.0.dylib (39) <6BC96A72-AFBE-34FD-91B1-748A530D8AE6> /usr/lib/libbsm.0.dylib
       0x109dac000 -        0x109db8ff3  libkxld.dylib (4570.51.1) <C2B927F3-E9D9-3ACF-A358-A51A61749FB4> /usr/lib/system/libkxld.dylib
       0x109dbe000 -        0x109dd6ff7  libcoretls.dylib (155.50.1) <D350052E-DC4D-3185-ADBA-BA48EDCEE955> /usr/lib/libcoretls.dylib
       0x109de2000 -        0x109de3ff3  libcoretls_cfhelpers.dylib (155.50.1) <B297F5D8-F2FE-3566-A752-E9D998B9C039> /usr/lib/libcoretls_cfhelpers.dylib
       0x109de9000 -        0x109dedfff  libpam.2.dylib (22) <7B4D2CE2-1438-387A-9802-5CEEFBF26F86> /usr/lib/libpam.2.dylib
       0x109df3000 -        0x109f86ff7  libsqlite3.dylib (274.8.1) <FCAD6A57-829E-3701-B16E-1833D620E0E8> /usr/lib/libsqlite3.dylib
       0x109fae000 -        0x109fbbfff  libxar.1.dylib (400) <0316128D-3B47-3052-995D-97B4FE5491DC> /usr/lib/libxar.1.dylib
       0x109fc5000 -        0x109fd2ffb  libbz2.1.0.dylib (38) <0A5086BB-4724-3C14-979D-5AD4F26B5B45> /usr/lib/libbz2.1.0.dylib
       0x109fd8000 -        0x109ff1ffb  liblzma.5.dylib (10) <3D419A50-961F-37D2-8A01-3DC7AB7B8D18> /usr/lib/liblzma.5.dylib
       0x109ffa000 -        0x10a174fff  libnetwork.dylib (1229.51.2) <D64FE2A1-CBFD-3817-A701-9A0DDBD70DCF> /usr/lib/libnetwork.dylib
       0x10a1ce000 -        0x10a1e4ff7  libapple_nghttp2.dylib (1.24) <01402BC4-4822-3676-9C80-50D83F816424> /usr/lib/libapple_nghttp2.dylib
       0x10a1f1000 -        0x10a225fff  libpcap.A.dylib (79.20.1) <FA13918B-A247-3181-B256-9B852C7BA316> /usr/lib/libpcap.A.dylib
       0x10a235000 -        0x10a2edff3  libboringssl.dylib (109.50.14) <E6813F87-B5E4-3F7F-A725-E6A7F2BD02EC> /usr/lib/libboringssl.dylib
       0x10a366000 -        0x10a3c6ff3  libusrtcp.dylib (1229.51.2) <3D8806D9-4BA9-35EE-BC44-F58BC2A0962D> /usr/lib/libusrtcp.dylib
       0x10a3d4000 -        0x10a3d4fff  libapple_crypto.dylib (109.50.14) <48BA2E76-BF2F-3522-A54E-D7FB7EAF7A57> /usr/lib/libapple_crypto.dylib
       0x10a3d8000 -        0x10a3e0ffb  com.apple.CoreServices.FSEvents (1239.50.1 - 1239.50.1) <3637CEC7-DF0E-320E-9634-44A442925C65> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
       0x10a3e8000 -        0x10a6bffff  com.apple.CoreServices.CarbonCore (1178.4 - 1178.4) <0D5E19BF-18CB-3FA4-8A5F-F6C787C5EE08> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
       0x10a736000 -        0x10a7e6ff7  com.apple.Metadata (10.7.0 - 1191.4.13) <B5C22E70-C265-3C9F-865F-B138994A418D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
       0x10a865000 -        0x10a8c5fff  com.apple.CoreServices.OSServices (822.31 - 822.31) <690E3C93-8799-39FF-8663-190A49B002E3> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
       0x10a911000 -        0x10a97ffff  com.apple.SearchKit (1.4.0 - 1.4.0) <3662545A-B1CF-3079-BDCD-C83855CEFEEE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
       0x10a9c3000 -        0x10aa37ffb  com.apple.AE (735.1 - 735.1) <08EBA184-20F7-3725-AEA6-C314448161C6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
       0x10aa69000 -        0x10ac26ff7  com.apple.LaunchServices (822.31 - 822.31) <BDFAB0FF-C2C6-375B-9E84-E43E267E2F82> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
       0x10ad37000 -        0x10ad6bfff  com.apple.DictionaryServices (1.2 - 284.2) <6505B075-41C3-3C62-A4C3-85CE3F6825CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
       0x10ad97000 -        0x10adbbffb  com.apple.coreservices.SharedFileList (71.21 - 71.21) <7DB79D78-9925-33F8-96BA-35AB7AEB326A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
       0x10addf000 -        0x10adebffb  com.apple.NetFS (6.0 - 4.0) <471DD96F-FA2E-3FE9-9746-2519A6780D1A> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
       0x10adf5000 -        0x10ae00fff  com.apple.NetAuth (6.2 - 6.2) <B3795F63-C14A-33E1-9EE6-02A2E7661321> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
       0x10ae0d000 -        0x10ae0fffb  com.apple.loginsupport (1.0 - 1) <D1232C1B-80EA-3DF8-9466-013695D0846E> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
       0x10ae15000 -        0x10ae1dff7  com.apple.TCC (1.0 - 1) <E1EB7272-FE6F-39AB-83CA-B2B5F2A88D9B> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
       0x10ae28000 -        0x10b050ff7  libmecabra.dylib (779.7.6) <F462F170-E872-3D09-B219-973D5E99C09F> /usr/lib/libmecabra.dylib
       0x10b0ae000 -        0x10b114fff  com.apple.ApplicationServices.ATS (377 - 445.3) <000C4E9F-E0D9-371D-B304-83BA37460724> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
       0x10b140000 -        0x10b144ff3  com.apple.ColorSyncLegacy (4.13.0 - 1) <A5FB2694-1559-34A8-A3D3-2029F68A63CA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy
       0x10b14d000 -        0x10b19fffb  com.apple.HIServices (1.22 - 624) <828E189A-62F9-3961-8A89-22F508870CC5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
       0x10b1d9000 -        0x10b1e7fff  com.apple.LangAnalysis (1.7.0 - 1.7.0) <B65FF7E6-E9B5-34D8-8CA7-63D415A8A9A6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
       0x10b1f6000 -        0x10b242fff  com.apple.print.framework.PrintCore (13.4 - 503.2) <B90C67C1-0292-3CEC-885D-F1882CD104BE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
       0x10b271000 -        0x10b2abfff  com.apple.QD (3.12 - 404.2) <38B20AFF-9D54-3B52-A6DC-C0D71380AA5F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
       0x10b2d7000 -        0x10b2e3fff  com.apple.speech.synthesis.framework (7.5.1 - 7.5.1) <84ADDF38-36F1-3D3B-B28D-8865FA10FCD7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
       0x10b2f8000 -        0x10b3ddff7  com.apple.CoreDisplay (1.0 - 97.16) <FCFB2A8C-7A5E-314B-AA12-04D33656A0E6> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay
       0x10b40c000 -        0x10b90afc3  com.apple.vImage (8.1 - ???) <A243A7EF-0C8E-3A9A-AA38-44AFD7507F00> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
       0x10b969000 -        0x10b969fff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <54FF3B43-E66C-3F36-B34B-A2B3B0A36502> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
       0x10b96d000 -        0x10bb1afc3  libvDSP.dylib (622.50.5) <40690941-CF89-3F90-A0AC-A4D200744A5D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
       0x10bb29000 -        0x10bb57fef  libBNNS.dylib (38.1) <7BAEFDCA-3227-3E07-80D8-59B6370B89C6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
       0x10bb61000 -        0x10bb66ff3  libQuadrature.dylib (3) <3D6BF66A-55B2-3692-BAC7-DEB0C676ED29> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
       0x10bb6b000 -        0x10bc1cfff  libvMisc.dylib (622.50.5) <BA2532DF-2D68-3DD0-9B59-D434BF702AA4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
       0x10bc29000 -        0x10bfe8ff7  libLAPACK.dylib (1211.50.2) <40ADBA5F-8B2D-30AC-A7AD-7B17C37EE52D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
       0x10c049000 -        0x10c1a3fe3  libBLAS.dylib (1211.50.2) <62C659EB-3E32-3B5F-83BF-79F5DF30D5CE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
       0x10c1c5000 -        0x10c1daff7  libLinearAlgebra.dylib (1211.50.2) <E8E0B7FD-A0B7-31E5-AF01-81781F71EBBE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
       0x10c1e4000 -        0x10c264fff  libSparse.dylib (79.50.2) <0DC25CDD-F8C1-3D6E-B472-8B060708424F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
       0x10c27e000 -        0x10c291fff  libSparseBLAS.dylib (1211.50.2) <722573CC-31CC-34B2-9032-E4F652A9CCFE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
       0x10c299000 -        0x10c29eff7  com.apple.GPUWrangler (3.18.48 - 3.18.48) <D2BA4CFA-ED0A-3FEC-B5FF-2D6C0557334E> /System/Library/PrivateFrameworks/GPUWrangler.framework/Versions/A/GPUWrangler
       0x10c2a5000 -        0x10c2acff7  com.apple.IOAccelerator (378.18.1 - 378.18.1) <E47DDE66-1B2B-310F-A060-638CA5D86F9C> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
       0x10c2b7000 -        0x10c2cffff  com.apple.IOPresentment (1.0 - 35.1) <214AD582-466F-3844-A0A4-DE0742A8B899> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment
       0x10c2ea000 -        0x10c2eeffb  com.apple.DSExternalDisplay (3.1 - 380) <8D03D346-887A-3CE7-9483-4AD7804D1FBB> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay
       0x10c2f5000 -        0x10c2faffb  libCoreFSCache.dylib (162.6.1) <879B2738-2E8A-3596-AFF8-9C3FB1B6828B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
       0x10c300000 -        0x10c33afff  com.apple.CoreVideo (1.8 - 0.0) <86CCC036-51BB-3DD1-9601-D93798BCCD0F> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
       0x10c363000 -        0x10c372fff  com.apple.GraphVisualizer (1.0 - 5) <B993B8A2-5700-3DFC-9EB7-4CCEE8F959F1> /System/Library/PrivateFrameworks/GraphVisualizer.framework/Versions/A/GraphVisualizer
       0x10c37d000 -        0x10c37dff7  com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <20ECB52B-B5C2-39EA-88E3-DFEC0C3CC9FF> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders
       0x10c382000 -        0x10c54cff3  libFosl_dynamic.dylib (17.8) <C58ED77A-4986-31C2-994C-34DDFB8106F0> /usr/lib/libFosl_dynamic.dylib
       0x10c584000 -        0x10c9b2fff  com.apple.vision.FaceCore (3.3.2 - 3.3.2) <B574FE33-4A41-3611-9738-388EBAF03E37> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
       0x10cbd0000 -        0x10cc1efff  com.apple.opencl (2.8.15 - 2.8.15) <83ED39D0-1D39-3593-BA25-70A8A911DE71> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
       0x10cc37000 -        0x10cc4dfff  libcompression.dylib (47.50.1) <491784AE-CB90-3E27-9081-95C3A1211760> /usr/lib/libcompression.dylib
       0x10cc55000 -        0x10cd77fff  libFontParser.dylib (222.1.4) <FF68FAF6-70BB-3E39-A263-E17B6F5E00D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
       0x10cdfa000 -        0x10ce44ff7  libFontRegistry.dylib (221.3) <C84F7112-4764-3F4B-9FBA-4A022CF6346B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
       0x10ce78000 -        0x10ce9bff7  libJPEG.dylib (1739.1) <E925D511-B457-3732-9B67-1A7DFB228EA4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
       0x10cea4000 -        0x10cef2fef  libTIFF.dylib (1739.1) <AD819413-29E3-3B2F-8997-2F88A82D9D83> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
       0x10cf03000 -        0x10cf29feb  libPng.dylib (1739.1) <48633B0C-BE01-3D94-9D9D-A95D50466AF9> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
       0x10cf35000 -        0x10cf39ffb  libGIF.dylib (1739.1) <D39BE184-279C-36AC-B233-EE17CACDEDB3> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
       0x10cf3f000 -        0x10d026fef  libJP2.dylib (1739.1) <053925CD-59DB-372F-98A8-C2372FF0B899> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
       0x10d050000 -        0x10d052ffb  libRadiance.dylib (1739.1) <A6F1064A-FFFC-3B06-8CBF-5204CDFC41C6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
       0x10d057000 -        0x10d09fff3  com.apple.AppleJPEG (1.0 - 1) <8DD410CB-76A1-3F22-9A9F-0491FA0CEB4A> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
       0x10d0ac000 -        0x10d0c7fff  com.apple.MetalPerformanceShaders.MPSCore (1.0 - 1) <0B4455FE-5C97-345C-B416-325EC6D88A2A> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSCore.framework/Versions/A/MPSCore
       0x10d0d9000 -        0x10d148fef  com.apple.MetalPerformanceShaders.MPSImage (1.0 - 1) <87F14199-C445-34C2-90F8-57C29212483E> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSImage.framework/Versions/A/MPSImage
       0x10d178000 -        0x10d25fff7  com.apple.MetalPerformanceShaders.MPSNeuralNetwork (1.0 - 1) <FBDDCAE6-EC6E-361F-B924-B3EBDEAC2D2F> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSNeuralNetwork.framework/Versions/A/MPSNeuralNetwork
       0x10d2c5000 -        0x10d2e9fff  com.apple.MetalPerformanceShaders.MPSMatrix (1.0 - 1) <BD50FD9C-CE92-34AF-8663-968BF89202A0> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSMatrix.framework/Versions/A/MPSMatrix
       0x10d2f9000 -        0x10d362ff7  com.apple.gpusw.MetalTools (1.0 - 1) <B5F66CF4-BE75-3A0B-A6A0-2F22C7C259D9> /System/Library/PrivateFrameworks/MetalTools.framework/Versions/A/MetalTools
       0x10d3e5000 -        0x10d423ffb  libGLU.dylib (16.5.10) <F6844912-1B86-34DF-9FB5-A428CC7B5B18> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
       0x10d433000 -        0x10d43cff7  libGFXShared.dylib (16.5.10) <6024B1FE-ACD7-3314-B390-85972CB9B778> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
       0x10d444000 -        0x10d44ffff  libGL.dylib (16.5.10) <AB8B6C73-8496-3784-83F6-27737ED03B09> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
       0x10d464000 -        0x10d49ffe7  libGLImage.dylib (16.5.10) <5B41D074-3132-3587-91B6-E441BA8C9F13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
       0x10d4a8000 -        0x10d4aafff  libCVMSPluginSupport.dylib (16.5.10) <BF5D065A-A38B-3446-9418-799F598072EF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
       0x10d4b0000 -        0x10d4b4fff  libCoreVMClient.dylib (162.6.1) <64ED0A84-225F-39BC-BE0D-C896ACF5B50A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
       0x10d4bc000 -        0x10d512ff3  libcups.2.dylib (462.2) <64864CBE-03A3-34C7-9DBB-C93601F183FD> /usr/lib/libcups.2.dylib
       0x10d52c000 -        0x10d545ff7  com.apple.Kerberos (3.0 - 1) <F86DCCDF-93C1-38B3-82C2-477C12E8EE6D> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
       0x10d55f000 -        0x10d58ffff  com.apple.GSS (4.0 - 2.0) <41087278-74AE-3FA5-8C0E-9C78EB696299> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
       0x10d5b1000 -        0x10d5cdffb  libresolv.9.dylib (65) <E8F3415B-4472-3202-8901-41FD87981DB2> /usr/lib/libresolv.9.dylib
       0x10d5d9000 -        0x10d6caff7  libiconv.2.dylib (51.50.1) <2FEC9707-3FAF-3828-A50D-8605086D060F> /usr/lib/libiconv.2.dylib
       0x10d6db000 -        0x10d74ffff  com.apple.Heimdal (4.0 - 2.0) <18607D75-DB78-3CC7-947E-AC769195164C> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
       0x10d781000 -        0x10d786ff3  libheimdal-asn1.dylib (520.50.6) <E358445A-B84E-31B5-BCCD-7E1397519D96> /usr/lib/libheimdal-asn1.dylib
       0x10d78d000 -        0x10d798fff  com.apple.OpenDirectory (10.13 - 207.50.1) <220FB6F2-4892-3A66-8838-C134CF657D3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
       0x10d7ad000 -        0x10d7b6ff3  com.apple.CommonAuth (4.0 - 2.0) <4D237B25-27E5-3577-948B-073659F6D3C0> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
       0x10d7be000 -        0x10d7daffb  com.apple.CFOpenDirectory (10.13 - 207.50.1) <C2715A7A-2E5C-3A21-ADB4-726F707A1294> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
       0x10d7fc000 -        0x10d888ff7  com.apple.securityfoundation (6.0 - 55185.50.5) <087D601E-7813-3F9E-97EE-BC7081F520BD> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
       0x10d8f7000 -        0x10d98aff7  com.apple.APFS (1.0 - 1) <D1CE52E0-45C0-30C4-B440-E2CF2F74CEE5> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
       0x10d9a2000 -        0x10d9a5ffb  libutil.dylib (51.20.1) <216D18E5-0BAF-3EAF-A38E-F6AC37CBABD9> /usr/lib/libutil.dylib
       0x10d9ac000 -        0x10d9d4fff  com.apple.applesauce (1.0 - ???) <CCA8B094-1BCE-3AE3-A0A7-D544C818DE36> /System/Library/PrivateFrameworks/AppleSauce.framework/Versions/A/AppleSauce
       0x10d9df000 -        0x10d9e6ff7  com.apple.LinguisticData (1.0 - 238.3) <49A54649-1021-3DBD-99B8-1B2EDFFA5378> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
       0x10d9ee000 -        0x10da04ff7  libmarisa.dylib (9) <D6D2D55D-1D2E-3442-B152-B18803C0ABB4> /usr/lib/libmarisa.dylib
       0x10da12000 -        0x10da54fff  com.apple.Lexicon-framework (1.0 - 33.5) <DC94CF9E-1EB4-3C0E-B298-CA1190885276> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
       0x10da64000 -        0x10da6ffff  libChineseTokenizer.dylib (28) <53633C9B-A3A8-36F7-A53C-432D802F4BB8> /usr/lib/libChineseTokenizer.dylib
       0x10da7e000 -        0x10da8efff  libcmph.dylib (6) <A5509EE8-7E00-3224-8814-015B077A3CF5> /usr/lib/libcmph.dylib
       0x10da97000 -        0x10db8cff7  com.apple.LanguageModeling (1.0 - 159.5.3) <7F0AC200-E3DD-39FB-8A95-00DD70B66A9F> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
       0x10dbb2000 -        0x10dbc2ff7  com.apple.CoreEmoji (1.0 - 69.3) <A4357F5C-0C38-3A61-B456-D7321EB2CEE5> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
       0x10dbcc000 -        0x10dbd0ffb  com.apple.xpc.ServiceManagement (1.0 - 1) <5BFDB3ED-73A7-3035-A5BC-ADA6E4F74BFD> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
       0x10dbd8000 -        0x10dbdfff7  com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <51A41CA3-DB1D-3380-993E-99C54AEE518E> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
       0x10dbeb000 -        0x10dc13fff  libxslt.1.dylib (15.12) <4A5E011D-8B29-3135-A52B-9A9070ABD752> /usr/lib/libxslt.1.dylib
       0x10dc21000 -        0x10dcb6ffb  com.apple.ink.framework (10.9 - 221) <5206C8B0-22DA-36C9-998E-846EDB626D5B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
       0x10dcea000 -        0x10dda7ff7  com.apple.TextureIO (3.7 - 3.7) <F8BAC954-405D-3CC3-AB7B-048C866EF980> /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO
       0x10ddc7000 -        0x10de48fdf  libate.dylib (1.13.1) <178ACDAD-DE7E-346C-A613-1CBF7929AC07> /usr/lib/libate.dylib
       0x10de52000 -        0x10de62ff7  com.apple.CrashReporterSupport (10.13 - 1) <4D0DF741-8BFA-3BCF-971D-6EF849019534> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
       0x10de74000 -        0x10df86fff  com.apple.Sharing (1019.46 - 1019.46) <1266C41E-3CA9-3EFC-8413-A37D52EA9FB2> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
       0x10e076000 -        0x10e09cffb  com.apple.IconServices (97.6 - 97.6) <A56D826D-20D2-34BE-AACC-A80CFCB4E915> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
       0x10e0be000 -        0x10e0e6fff  com.apple.framework.Apple80211 (13.0 - 1361.7) <16627876-8CF5-3502-A1D6-35FCBDD5E79A> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
       0x10e0f5000 -        0x10e225ff7  com.apple.CoreUtils (5.5 - 550.44) <DFC364C3-0812-31B5-9C79-C81C2DFDDB8B> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils
       0x10e2dd000 -        0x10e368ff3  com.apple.framework.CoreWLAN (13.0 - 1350.1) <E862CC02-69D2-3503-887B-B6E8223081E7> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN
       0x10e3c6000 -        0x10e4caffb  com.apple.Bluetooth (6.0.5 - 6.0.5f3) <85F1B5A6-03C5-3D5A-90B8-5FC86349E330> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth
       0x10e556000 -        0x10e574fff  com.apple.ProtocolBuffer (1 - 260) <40704740-4A53-3010-A49B-08D1D69D1D5E> /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer
       0x10e591000 -        0x10e5f5fff  com.apple.framework.CoreWiFi (13.0 - 1350.1) <6EC5DEB3-6E2F-3DC2-BE59-1FD05175FB0C> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
       0x10e657000 -        0x10e680ffb  com.apple.CoreBluetooth (1.0 - 1) <E1335074-9D07-370E-8440-61C4874BAC56> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
       0x10e69f000 -        0x10e6dfff7  com.apple.DebugSymbols (181.0 - 181.0) <299A0238-ED78-3676-B131-274D972824AA> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
       0x10e6ff000 -        0x10e790fff  com.apple.CoreSymbolication (9.3 - 64026) <BAF3CE6E-8140-3159-BF1B-B953816459A0> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
       0x10e7e5000 -        0x10e86efc7  com.apple.Symbolication (9.3 - 64033) <FAA17252-6378-34A4-BBBB-22DF54EC1626> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
       0x10e8c8000 -        0x10e8d7fef  com.apple.AppleFSCompression (96.30.2 - 1.0) <ABFF224B-22D6-35F6-A072-9548FD388EB7> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
       0x10e8e1000 -        0x10e8eeff7  com.apple.SpeechRecognitionCore (4.0.13 - 4.0.13) <8B5418A4-CDC5-3200-AEF0-F109E0DF9019> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore
       0x10e8fe000 -        0x10e901ffb  com.apple.CommonPanels (1.2.6 - 98) <2391761C-5CAA-3F68-86B7-50B37927B104> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
       0x10e909000 -        0x10e90cffb  com.apple.help (1.3.8 - 66) <DEBADFA8-C189-3195-B0D6-A1F2DE95882A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
       0x10e913000 -        0x10e918fff  com.apple.ImageCapture (9.0 - 9.0) <23B4916F-3B43-3DFF-B956-FC390EECA284> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
       0x10e928000 -        0x10e942ff7  com.apple.openscripting (1.7 - 174) <1B2A1F9E-5534-3D61-83CA-9199B39E8708> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
       0x10e958000 -        0x10e959fff  com.apple.print.framework.Print (12 - 267) <3682ABFB-2561-3419-847D-02C247F4800D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
       0x10e95f000 -        0x10e961ff7  com.apple.securityhi (9.0 - 55006) <C1406B8D-7D05-3959-808F-9C82189CF57F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
       0x10ed99000 -        0x10ed9afff +_heapq.cpython-37m-darwin.so (???) <3CD355DB-06FD-4E99-E801-06B3ECCCF9F7> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x10ee1e000 -        0x10ee1ffff +_posixsubprocess.cpython-37m-darwin.so (???) <34B55F18-A4D9-36F1-11C7-0FC66AE97445> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x10ee22000 -        0x10ee25ff7 +select.cpython-37m-darwin.so (???) <3DD32E0F-132E-3613-1CB9-BEB4C4815BDA> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x10ee2b000 -        0x10ee30fef +math.cpython-37m-darwin.so (???) <9878F8E7-373C-2423-36D4-9DBBAE9D567A> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x10ee77000 -        0x10ee81fff +_socket.cpython-37m-darwin.so (???) <C08ADF4F-9F1F-D919-B538-10795D149307> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x10ef4e000 -        0x10ef4efff +_opcode.cpython-37m-darwin.so (???) <251AA31E-2E67-2250-24DD-7B3EDDDAD9EA> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x10efd1000 -        0x10efd5fff +zlib.cpython-37m-darwin.so (???) <0BE8B1F5-A68E-9802-8043-3CE8271E7450> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x10efdb000 -        0x10efdcfff +_bz2.cpython-37m-darwin.so (???) <EB1A185C-1EDA-6182-24CC-EA76C92B05D5> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x10efe0000 -        0x10efe0fff +grp.cpython-37m-darwin.so (???) <F2B045D2-8CDC-17B4-327E-4ED961454078> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x10efe3000 -        0x10efe6ff7 +_hashlib.cpython-37m-darwin.so (???) <786E4EA8-7224-954C-D3F5-33D6CA3AB15C> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x10efeb000 -        0x10eff4ff7 +_blake2.cpython-37m-darwin.so (???) <78BCCB2C-1863-8A50-91EC-F60557ABCE86> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x10eff9000 -        0x10eff9fff +_bisect.cpython-37m-darwin.so (???) <E138D47F-CDEE-8171-FD12-2BD1FF7A04F3> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x10effc000 -        0x10effdfff +_random.cpython-37m-darwin.so (???) <E1AF77F9-BDC7-959E-CB7D-B5B722B8B543> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x110440000 -        0x11046efff +_lzma.cpython-37m-darwin.so (???) <EC0EF344-1C71-8B81-1F9F-5077430D0106> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x1105b8000 -        0x110610ff7 +libssl.1.1.dylib (1.1) <266D2584-1056-919E-B3E4-B243BE332899> /Library/Frameworks/Python.framework/Versions/3.7/lib/libssl.1.1.dylib
       0x110630000 -        0x1108347b7 +libcrypto.1.1.dylib (1.1) <649634DF-2DE0-43F0-95B3-E9702FD64B4B> /Library/Frameworks/Python.framework/Versions/3.7/lib/libcrypto.1.1.dylib
       0x1108b3000 -        0x1108c6fff +_sha3.cpython-37m-darwin.so (???) <8473A44B-5561-B9BE-C7BC-71A17C29BBB3> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x11094c000 -        0x110951fff +_struct.cpython-37m-darwin.so (???) <24D14CF9-5325-366E-DEF1-62C5DFEBC1B8> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x11095a000 -        0x11096dfff +_pickle.cpython-37m-darwin.so (???) <C852BFFB-37E4-4131-CC1B-E98CAA484E4C> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x11097a000 -        0x11097bfff +_queue.cpython-37m-darwin.so (???) <6709FF22-F75F-B847-D335-00DB34CE04F8> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so
       0x1123d8000 -        0x112409ff3  com.apple.CoreServicesInternal (309.1 - 309.1) <EB09CAFC-AE9B-3257-BE45-5471D9F64AAD> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/CoreServicesInternal
       0x11268b000 -        0x1126beff7  libTrueTypeScaler.dylib (222.1.4) <4734ECD6-6F41-3A16-AE35-265BDC1572C5> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Resources/libTrueTypeScaler.dylib
       0x1126fd000 -        0x112713fef  libCGInterfaces.dylib (417.2) <ED0EAE3C-D963-3DF7-A408-4F00FF1C8C34> /System/Library/Frameworks/Accelerate.framework/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib
       0x112817000 -        0x112817fff  libmetal_timestamp.dylib (802.4.5) <BCA42032-C91F-3463-BA1E-1433262ACA0A> /System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/3802/Libraries/libmetal_timestamp.dylib
       0x113ebe000 -        0x113fb4ff7  com.apple.driver.AppleIntelBDWGraphicsMTLDriver (10.32.48 - 10.3.2) <CB899415-0073-3FD5-973D-2E49BDF5FC43> /System/Library/Extensions/AppleIntelBDWGraphicsMTLDriver.bundle/Contents/MacOS/AppleIntelBDWGraphicsMTLDriver
       0x1146f9000 -        0x1146fafff  libodfde.dylib (24.50.1) <972F9662-D4FA-304F-9D13-AC440F908A6F> /usr/lib/libodfde.dylib
       0x114940000 -        0x1149defff  ColorSyncDeprecated.dylib (3325) <1938C255-8221-32C4-8D37-9E27E6C9085E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/Resources/ColorSyncDeprecated.dylib
       0x114af8000 -        0x114af9fff  com.apple.TrustEvaluationAgent (2.0 - 31) <39F533B2-211E-3635-AF47-23F27749FF4A> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
       0x114e37000 -        0x114e59fff  com.apple.framework.familycontrols (4.1 - 410) <F8720CCF-6E8F-33E1-9328-A2875971B97B> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
       0x114e6f000 -        0x114e7bffb  com.apple.CommerceCore (1.0 - 656.20) <AF242149-5360-3552-99E6-7C98623C1A08> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
       0x114e8b000 -        0x114eb7fff  com.apple.framework.SystemAdministration (1.0 - 1.0) <2916D56F-1F72-3A6B-8F2F-9E6EFE6B962A> /System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/SystemAdministration
       0x114ee2000 -        0x114ee5ff3  com.apple.SecCodeWrapper (4.0 - 360.50.7) <D7136CA5-CC5E-3B3C-AF1A-A8E5FF2023DF> /System/Library/PrivateFrameworks/SecCodeWrapper.framework/Versions/A/SecCodeWrapper
       0x114eec000 -        0x114ef1fff  com.apple.LoginUICore (4.0 - 4.0) <29953093-7A93-3547-8BB8-FBBB422CE20D> /System/Library/PrivateFrameworks/LoginUIKit.framework/Versions/A/Frameworks/LoginUICore.framework/Versions/A/LoginUICore
       0x1159da000 -        0x1159f5ff3  com.apple.AppContainer (4.0 - 360.50.7) <59F95A1A-15DF-33CE-9E52-DDEEFDC4D138> /System/Library/PrivateFrameworks/AppContainer.framework/Versions/A/AppContainer
       0x115a0d000 -        0x115afbff7  com.apple.DiskManagement (11.4 - 1428) <BEA3294F-3BF2-3395-A5C2-B26BEF9508C5> /System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/DiskManagement
       0x115b47000 -        0x115b52ff7  com.apple.DirectoryService.Framework (10.13 - 207.50.1) <29D21437-7B41-3E9D-B5D4-462986AED83F> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
       0x115b5c000 -        0x115c2eff7  com.apple.DiskImagesFramework (480.50.10 - 480.50.10) <08B48BB9-51A4-3AC4-9E24-AA1C338BA548> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
       0x115c90000 -        0x115d1dff7  libCoreStorage.dylib (546.50.1) <6AFD6AAE-2EFE-3CF3-90C6-A66F67FCB309> /usr/lib/libCoreStorage.dylib
       0x115d47000 -        0x115d52ff7  libcsfde.dylib (546.50.1) <D02562A4-CCE6-35FE-8BDE-05BB68DA0038> /usr/lib/libcsfde.dylib
       0x115d5f000 -        0x115d92ff7  com.apple.MediaKit (16 - 873) <EC6E742E-305D-362F-9E22-BF313013054C> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
       0x115da6000 -        0x115e60fff  com.apple.DiscRecording (9.0.3 - 9030.4.5) <35D1FF9A-432C-39AD-9C1F-9022246EC5C0> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
       0x115ecb000 -        0x115ecefff  com.apple.EFILogin (2.0 - 2) <65FC80C1-965D-3FE9-9666-41DB87A934A6> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin
       0x115ed7000 -        0x115f2effb  com.apple.ProtectedCloudStorage (1.0 - 1) <351DCB70-4AA2-326E-B14E-0874AA37FA9B> /System/Library/PrivateFrameworks/ProtectedCloudStorage.framework/Versions/A/ProtectedCloudStorage
       0x115f73000 -        0x115fc7ffb  libcurl.4.dylib (105.40.1) <B04E7791-EAF9-3D72-B4ED-DD8F135140EC> /usr/lib/libcurl.4.dylib
       0x115fdd000 -        0x11616efff  libcrypto.35.dylib (22.50.2) <97828BFD-4675-35DF-BE2E-C6D1555BB71D> /usr/lib/libcrypto.35.dylib
       0x1161e3000 -        0x116236ffb  libssl.35.dylib (22.50.2) <AF523E9B-7183-3A87-8FB4-E26936EC4FDB> /usr/lib/libssl.35.dylib
       0x116253000 -        0x116288fff  com.apple.LDAPFramework (2.4.28 - 194.5) <08888215-BBCE-3402-8142-2C9ADB091580> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
       0x116296000 -        0x1162a8fff  libsasl2.2.dylib (211) <04EF3F61-12EC-3319-A649-851999F4C7A4> /usr/lib/libsasl2.2.dylib
       0x1162b1000 -        0x1162baff7  com.apple.frameworks.CoreDaemon (1.3 - 1.3) <35A43584-2AF8-3202-A139-27D916E444BE> /System/Library/PrivateFrameworks/CoreDaemon.framework/Versions/B/CoreDaemon
       0x1162c8000 -        0x1162d0ff3  com.apple.AppleSRP (5.0 - 1) <4CEC34CF-63E3-3023-B61B-F8D133698534> /System/Library/PrivateFrameworks/AppleSRP.framework/Versions/A/AppleSRP
    0x7fff6942c000 -     0x7fff694769df  dyld (551.3) <AFAB4EFA-7020-34B1-BBEF-0F26C6D3CA36> /usr/lib/dyld

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 50201
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=196.0M resident=0K(0%) swapped_out_or_unallocated=196.0M(100%)
Writable regions: Total=109.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=109.3M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Accelerate framework               128K        2 
Activity Tracing                   256K        2 
CG backing stores                 3488K        6 
CG image                             4K        2 
CoreGraphics                         8K        2 
CoreImage                            8K        3 
CoreUI image data                  852K        6 
CoreUI image file                  180K        4 
Dispatch continuations            8192K        2 
Kernel Alloc Once                    8K        2 
MALLOC                            76.4M       58 
MALLOC guard page                   48K       11 
MALLOC_LARGE (reserved)            512K        3         reserved VM address space (unallocated)
Memory Tag 242                      12K        2 
STACK GUARD                         24K        7 
Stack                             2668K        7 
VM_ALLOCATE                        168K       18 
__DATA                            23.3M      335 
__FONT_DATA                          4K        2 
__LINKEDIT                        46.6M      274 
__TEXT                           149.4M      274 
__UNICODE                          560K        2 
__UNIXSTACK                       16.0M        2 
mapped file                       52.3M       18 
shared memory                      628K       10 
===========                     =======  ======= 
TOTAL                            381.3M     1029 
TOTAL, minus reserved VM space   380.8M     1029 

Model: MacBookAir7,2, BootROM MBA71.0176.B00, 2 processors, Intel Core i5, 1.8 GHz, 8 GB, SMC 2.27f2
Graphics: Intel HD Graphics 6000, Intel HD Graphics 6000, Built-In
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x483943434E4E4E424C54424C41522D4E5444
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x483943434E4E4E424C54424C41522D4E5444
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x117), Broadcom BCM43xx 1.0 (7.77.37.29.1a7)
Bluetooth: Version 6.0.5f3, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0128G, 121.33 GB
USB Device: USB 3.0 Bus
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Air, Apple Inc., 27.2

----------
files: Screen Shot 2018-09-05 at 15.36.57.png
messages: 324615
nosy: JokeNeverSoke
priority: normal
severity: normal
status: open
title: subprocess
versions: Python 3.7
Added file: https://bugs.python.org/file47787/Screen Shot 2018-09-05 at 15.36.57.png

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

From report at bugs.python.org  Wed Sep  5 11:23:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 15:23:36 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536161016.85.0.56676864532.issue8110@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't think that we should backport this change to 3.7 and older.

I understand that the change is about supporting Cygwin. My policy to support a new platform is always the same: first fix *all* issues in master, get a working CI, find a core developer responsible to fix all issues specific to this platform, and only after that we can start discussing about backporting specific changes for that platform.

https://pythondev.readthedocs.io/cpython.html#i-want-cpython-to-support-my-platform

----------

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

From report at bugs.python.org  Wed Sep  5 11:26:18 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 05 Sep 2018 15:26:18 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536161178.4.0.56676864532.issue8110@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This one has nothing to do with Cygwin, this is about minimizing patching that IronPython (or other implementations) have to do to standard library modules.

----------

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

From report at bugs.python.org  Wed Sep  5 11:29:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Sep 2018 15:29:01 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <1536161341.12.0.56676864532.issue34586@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Wed Sep  5 11:37:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 15:37:22 +0000
Subject: [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536161842.49.0.56676864532.issue34549@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You're welcome. Feel free to close this if it answers your question.

Thanks

----------

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

From report at bugs.python.org  Wed Sep  5 11:38:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Sep 2018 15:38:31 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1536161911.26.0.56676864532.issue34481@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  5 11:50:05 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 05 Sep 2018 15:50:05 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1536162605.79.0.56676864532.issue34568@psf.upfronthosting.co.za>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

My concerns with the behavior of `__origin__` possibly changing in the future seem to valid. In Python 3.5 and 3.6 the behavior is 

    List.__origin__ is None
    List[int].__origin__ is List

while in Python 3.7

    List.__origin is list
    List[int].__origin__ is list

Is it likely that this is going to change again or can I rely on the current behavior with Python 3.7+?

----------

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

From report at bugs.python.org  Wed Sep  5 12:27:20 2018
From: report at bugs.python.org (Nick)
Date: Wed, 05 Sep 2018 16:27:20 +0000
Subject: [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536164840.31.0.56676864532.issue34549@psf.upfronthosting.co.za>


Change by Nick <manifes7o at gmail.com>:


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

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

From report at bugs.python.org  Wed Sep  5 13:52:12 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 05 Sep 2018 17:52:12 +0000
Subject: [issue34588] traceback module can drop a frame
Message-ID: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Consider the following script:
import traceback

def fill_stack(depth):
    if depth <= 1:
        return traceback.format_stack()
    else:
        return fill_stack(depth - 1)

assert fill_stack(4) != fill_stack(5)

On the Python 3 versions I tested, this script doesn't fail! Somehow traceback is producing identical tracebacks for different callstacks.

----------
components: Library (Lib)
messages: 324648
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: traceback module can drop a frame
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep  5 15:36:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 19:36:35 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
Message-ID: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

According to Nick Coghlan, author of the PEP 538, the C locale coercion should not be enabled by Py_Initialize() and Py_Main(), only by the python3 program.

Attached PR fix this issue.

----------
components: Interpreter Core
messages: 324649
nosy: vstinner
priority: normal
severity: normal
status: open
title: Py_Initialize() and Py_Main() should not enable C locale coercion
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep  5 15:40:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 19:40:26 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536176426.02.0.56676864532.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Wed Sep  5 16:05:08 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 05 Sep 2018 20:05:08 +0000
Subject: [issue34574] OrderedDict iterators are exhausted during pickling
In-Reply-To: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>
Message-ID: <1536177908.86.0.56676864532.issue34574@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

This would presumably be a side-effect of all generic pickling operations of iterators; figuring out what the iterator produces requires running out the iterator. You could special case it case-by-case, but that just makes the behavior unreliable/confusing; now some iterators pickle without being mutated, and others don't. Do you have a proposal to fix it? Is it something that needs to be fixed at all, when the option to pickle the original OrderedDict directly is there?

----------
nosy: +josh.r

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

From report at bugs.python.org  Wed Sep  5 16:13:19 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Wed, 05 Sep 2018 20:13:19 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536178399.2.0.56676864532.issue34561@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

Haha ok. Cache optimization makes it pretty complicated to reason about true costs. Anyway, it?s not obvious to me even that the run lengths would need to be descending for best performace. I?m not even starting to think about how the merging order might affect galloping boosts on realistic data ;-). I didn?t get to that power thing at this point, but it looks like it?s unrelated to this consideration, except perhaps by chance. I might have time tonight to have a look at that. Surely we don?t want an algorithm that?s optimized for what they call ?Timsort drag? sequences in the literature ;-).

----------

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

From report at bugs.python.org  Wed Sep  5 16:39:26 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 05 Sep 2018 20:39:26 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
Message-ID: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

https://docs.python.org/3.8/howto/logging.html#configuring-logging-for-a-library is a bit too short and doesn't answer some questions that I have as a library author about the best ways to use logging in a library.

Should I make use of a single logger object in my library, multiple loggers in a tree, or multiple unrelated loggers? Since I have just one public module, I'm tempted to say that I should just use one logger object.

Should I present as part of my public API the name of the logger object(s) used? Probably - the documentation starts with "When developing a library which uses logging, you should take care to document how the library uses logging - for example, the names of loggers used.". But should I also include the logger objects in my API? If an application wants to reach my logger, why should they use "logging.getLogger(<name that I shared with them>)" rather than "my_library.LOGGER"?

Should I use my library's fully-qualified name as the name of its logger? This seems like a great idea because it's unlikely to bring up any new conflicts. Is it a best practice? Is there any better practice?

The "Configuring Logging for a Library" text could answer these questions, and maybe it should, but... I really think a toy library example that library authors could follow would also help a great deal.

----------
assignee: docs at python
components: Documentation
messages: 324652
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: "Logging HOWTO" should share an example of best practices for using logging in a library
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/issue34590>
_______________________________________

From report at bugs.python.org  Wed Sep  5 16:41:44 2018
From: report at bugs.python.org (Quae Quack)
Date: Wed, 05 Sep 2018 20:41:44 +0000
Subject: [issue34591] smtplib mixes RFC821 and RFC822 addresses
Message-ID: <1536180104.03.0.56676864532.issue34591@psf.upfronthosting.co.za>


New submission from Quae Quack <quae at daurnimator.com>:

smtplib.sendmsg is documented to take RFC822 addresses. and e.g. if the `to_addrs` argument isn't provided then it gets the To address directly from the headers (which is in RFC822 form).

However it then proceeds to use it as an RFC821 address and sends it over the SMTP connection. https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Lib/smtplib.py#L542

----------
components: Library (Lib)
messages: 324653
nosy: Quae Quack
priority: normal
severity: normal
status: open
title: smtplib mixes RFC821 and RFC822 addresses
type: security

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

From report at bugs.python.org  Wed Sep  5 17:35:41 2018
From: report at bugs.python.org (Sergei Lebedev)
Date: Wed, 05 Sep 2018 21:35:41 +0000
Subject: [issue34592] cdll.LoadLibrary allows None as an argument
Message-ID: <1536183341.44.0.56676864532.issue34592@psf.upfronthosting.co.za>


New submission from Sergei Lebedev <superbobry at gmail.com>:

LoadLibrary in Python 2.7 through 3.7 accepts None as an argument. I wonder if this has been allowed for a reason? If not, it should probably be changed to raise a TypeError instead.

>>> ctypes.cdll.LoadLibrary(None)
<CDLL 'None', handle fffffffffffffffe at 10eedbe90>

Interestingly, on Python 2.7 LoadLibrary explicitly mentions None as allowed in the error message:

>>> ctypes.cdll.LoadLibrary(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]/ctypes/__init__.py", line 444, in LoadLibrary
    return self._dlltype(name)
  File "[...]/ctypes/__init__.py", line 366, in __init__
    self._handle = _dlopen(self._name, mode)
TypeError: dlopen() argument 1 must be string or None, not int

A side-effect of None being allowed is that chaining find_library and LoadLibrary is error-prone:

>>> ctypes.cdll.LoadLibrary(find_library("foobar"))
<CDLL 'None', handle fffffffffffffffe at 10ef35fd0>

----------
messages: 324654
nosy: superbobry
priority: normal
severity: normal
status: open
title: cdll.LoadLibrary allows None as an argument
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/issue34592>
_______________________________________

From report at bugs.python.org  Wed Sep  5 20:54:33 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Thu, 06 Sep 2018 00:54:33 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1536195273.59.0.56676864532.issue34486@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

I agree. From code in threading.Condition.wait looks like if it is interrupted either after calling _release_save and before entering try block or in finally block before calling _acquire_restore - it will leave the lock in non-acquired state. 

First part in theory can be solved if _release_save is moved into try block and instead of returning saved_state as a result it will accept reference to saved_state local and set it in C code.

Second part looks more interesting ... :)

----------
nosy: +v2m

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

From report at bugs.python.org  Wed Sep  5 21:10:24 2018
From: report at bugs.python.org (Gary Simpson)
Date: Thu, 06 Sep 2018 01:10:24 +0000
Subject: [issue34593] Missing inttypes.h
Message-ID: <1536196224.28.0.56676864532.issue34593@psf.upfronthosting.co.za>


New submission from Gary Simpson <gary at garysimpson.org>:

I started with Anaconda3 (python3.64). When I add #include "python.h" to my C++ code, I get the visual studio 2012 compile error:
anaconda3\include\pyport.h(6): fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory

I then installed python 3.7, and put that include directory into my project. But I get the same error when I try to compile. 
python.h calls pyport.h, which tries to call inttypes.h, which it can't find. I searched and cannot find inttypes.h anywhere on my computer.

----------
messages: 324656
nosy: garyrsimpson
priority: normal
severity: normal
status: open
title: Missing inttypes.h
type: compile error
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep  5 21:44:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Sep 2018 01:44:22 +0000
Subject: [issue34593] Missing inttypes.h
In-Reply-To: <1536196224.28.0.56676864532.issue34593@psf.upfronthosting.co.za>
Message-ID: <1536198262.63.0.56676864532.issue34593@psf.upfronthosting.co.za>


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

Python 3.6 requires a C compiler that supports C99. So, not MSVC 2012.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Sep  5 23:31:54 2018
From: report at bugs.python.org (hongweipeng)
Date: Thu, 06 Sep 2018 03:31:54 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1536204714.92.0.56676864532.issue34410@psf.upfronthosting.co.za>


Change by hongweipeng <hongweichen8888 at sina.com>:


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

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

From report at bugs.python.org  Wed Sep  5 23:34:22 2018
From: report at bugs.python.org (hongweipeng)
Date: Thu, 06 Sep 2018 03:34:22 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1536204862.54.0.56676864532.issue34410@psf.upfronthosting.co.za>


hongweipeng <hongweichen8888 at sina.com> added the comment:

Multi-process need uses multiprocessing.Manager to share, the current problem should be tee-objcet thread safety issue.As Xiang Zhang said,`PyIter_Next` in `teedataobject_getitem` releases GIL.So the thread lock is necessary,and only lead iterator uses it when runs `PyIter_Next`.Can anyone help me review it.

----------
nosy: +hongweipeng

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

From report at bugs.python.org  Thu Sep  6 00:33:02 2018
From: report at bugs.python.org (Martin Panter)
Date: Thu, 06 Sep 2018 04:33:02 +0000
Subject: [issue34566] pipe read sometimes returns EOF but returncode is still
 None
In-Reply-To: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>
Message-ID: <1536208382.08.0.56676864532.issue34566@psf.upfronthosting.co.za>


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

You probably only need to call "wait" once. That blocks the thread until it gets a result, so it is more CPU-efficient than calling "poll" in a busy loop.

Since you open a separate pipe for "stderr" in script.py, but don't do anything with it, there could be a deadlock with the child writing to the stderr pipe versus the parent reading from "stdout" or waiting for the exit status.

I guess your script is an approximation of the "sos" application. I don't have time to understand everything it is trying to do, but I added some comments at <https://github.com/sosreport/sos/commit/2fcf5f0#r30410300>.

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

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

From report at bugs.python.org  Thu Sep  6 00:54:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Sep 2018 04:54:17 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536209657.69.0.56676864532.issue34590@psf.upfronthosting.co.za>


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

FWIW, I think the practices vary somewhat widely and that none of your questions have generally agreed upon answers.  Part of the reason that there are so many ways to go is that the package was modeled after Java APIs where the practices and needs were also widely varied.  Given the absence of clear-cut best practices, the docs should probably defer to StackOverflow and various blog posts.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Sep  6 01:07:10 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Sep 2018 05:07:10 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <1536210430.89.0.56676864532.issue34586@psf.upfronthosting.co.za>


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

I haven't run across this requirement before but it does seem plausible that a person might want to know which underlying mapping found a match (compare with the "which" utility in Bash). On the other hand, we haven't had requests for anything like this for other lookup chains such as determining where a variable appears in the sequence locals-to-nested-scopes-to-globals-to-builtins.

Also, I'm not sure I like the proposed API (the method name and signature).  Perhaps, this should be a docs recipe for a ChainMap subclass or be an example of a standalone search function that the takes the *maps* attribute as one of its arguments.  Will discuss this with the other core devs to get their thoughts.

----------

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

From report at bugs.python.org  Thu Sep  6 01:48:47 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 06 Sep 2018 05:48:47 +0000
Subject: [issue34594] Some tests use hardcoded errno values
Message-ID: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

test_spwd.py and test_tabnanny.py use hardcoded errno values when they test some exception messages.

----------
components: Tests
messages: 324662
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Some tests use hardcoded errno values
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep  6 01:52:11 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 06 Sep 2018 05:52:11 +0000
Subject: [issue34594] Some tests use hardcoded errno values
In-Reply-To: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>
Message-ID: <1536213131.0.0.56676864532.issue34594@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  6 01:54:34 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Sep 2018 05:54:34 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536213274.81.0.56676864532.issue34588@psf.upfronthosting.co.za>


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

Further investigation reveals this is a general off-by-one error with the recursive traceback pruning feature.

----------
components: +Interpreter Core
title: traceback module can drop a frame -> traceback formatting can drop a frame

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

From report at bugs.python.org  Thu Sep  6 02:03:02 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Sep 2018 06:03:02 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536213782.27.0.56676864532.issue34588@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  6 02:40:38 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 06 Sep 2018 06:40:38 +0000
Subject: [issue34574] OrderedDict iterators are exhausted during pickling
In-Reply-To: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>
Message-ID: <1536216038.32.0.56676864532.issue34574@psf.upfronthosting.co.za>


Sergey Fedoseev <fedoseev.sergey at gmail.com> added the comment:

Other iterators either don't support pickling or aren't mutated during pickling:

In [10]: it = iter({1})

In [11]: pickle.dumps(it)
Out[11]: b'\x80\x04\x95\x1e\x00\x00\x00\x00\x00\x00\x00\x8c\x08builtins\x94\x8c\x04iter\x94\x93\x94]\x94K\x01a\x85\x94R\x94.'

In [12]: list(it)
Out[12]: [1]

In [13]: it = (x for x in {1})

In [14]: pickle.dumps(it)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-14-7e86a183a31c> in <module>()
----> 1 pickle.dumps(it)

TypeError: can't pickle generator objects

----------

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

From report at bugs.python.org  Thu Sep  6 02:51:16 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 06:51:16 +0000
Subject: [issue34574] OrderedDict iterators are exhausted during pickling
In-Reply-To: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>
Message-ID: <1536216676.1.0.56676864532.issue34574@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep  6 02:53:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 06:53:18 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536216798.37.0.56676864532.issue34580@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep  6 03:01:08 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 06 Sep 2018 07:01:08 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536217268.18.0.56676864532.issue30977@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  6 03:10:39 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 06 Sep 2018 07:10:39 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536217839.17.0.56676864532.issue30977@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

See new PR which addresses pickle forward and backward compatibility.

----------
nosy: +taleinat

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

From report at bugs.python.org  Thu Sep  6 03:17:13 2018
From: report at bugs.python.org (Julien Palard)
Date: Thu, 06 Sep 2018 07:17:13 +0000
Subject: [issue32430] Simplify Modules/Setup{,.dist,.local}
In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za>
Message-ID: <1536218233.48.0.56676864532.issue32430@psf.upfronthosting.co.za>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +8537

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

From report at bugs.python.org  Thu Sep  6 03:29:10 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Thu, 06 Sep 2018 07:29:10 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
In-Reply-To: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>
Message-ID: <1536218950.79.0.56676864532.issue26208@psf.upfronthosting.co.za>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

Just noticed this myself when testing with Python 3.5-3.7:

    >>> from decimal import Decimal
    >>> d = Decimal('foo')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]


With Python 2.7 I get this error instead:

    decimal.InvalidOperation: Invalid literal for Decimal: 'foo'


I'm writing type conversion code and was planning to include the error message by Python along with some higher level explanation when reporting errors. `[<class 'decimal.ConversionSyntax'>]` would be such a strange message that I need to make a special case with decimal.

----------
nosy: +pekka.klarck

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

From report at bugs.python.org  Thu Sep  6 03:38:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 07:38:19 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536219499.05.0.56676864532.issue34580@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  6 03:40:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 07:40:50 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536219650.69.0.56676864532.issue34580@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems like an extra note is reasonable here. I have created a PR for this. Feedback welcome on the wording.

Thanks.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.8

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

From report at bugs.python.org  Thu Sep  6 03:52:46 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 07:52:46 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1536220366.91.0.56676864532.issue34587@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems there was a similar report pointing to the same line in the test using Fedora 28. Ref : https://bugs.python.org/issue34354

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep  6 03:55:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 07:55:09 +0000
Subject: [issue34354] Memory leak on _testCongestion
In-Reply-To: <1533705661.31.0.56676864532.issue34354@psf.upfronthosting.co.za>
Message-ID: <1536220509.28.0.56676864532.issue34354@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems related : https://bugs.python.org/issue34587

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep  6 04:03:34 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 06 Sep 2018 08:03:34 +0000
Subject: [issue31371] Remove deprecated tkinter.tix module in 3.7
In-Reply-To: <1504733600.21.0.0387108366765.issue31371@psf.upfronthosting.co.za>
Message-ID: <1536221014.25.0.56676864532.issue31371@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

We should decide on this.

I agree with Serhiy that in accordance with PEP 4, as long as Tix still works, we should keep it.

----------
nosy: +taleinat

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

From report at bugs.python.org  Thu Sep  6 04:25:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 08:25:48 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536222348.07.0.56676864532.issue30977@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I close the issue because of the pickle issue that hasn't been addressed by the wouter bolsterlee (the author) didn't reply for 1 month 1/2.

@wouter bolsterlee: if you still want to work on that issue, you should try to address the pickle issue first, then reopen this issue or maybe create a new issue pointing to this one.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Sep  6 04:26:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 08:26:25 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536222385.36.0.56676864532.issue30977@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Oops. I missed the fact that Tal created PR 9078. Sorry, I reopen the issue ;-)

----------
resolution: out of date -> 
status: closed -> open

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

From report at bugs.python.org  Thu Sep  6 04:26:47 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Sep 2018 08:26:47 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
In-Reply-To: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>
Message-ID: <1536222407.33.0.56676864532.issue26208@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

The thing is that Python explicitly supports any object as the "message".

I was quite pleased when I discovered that because it provides a way
to include both signals and the condition list in the "message", which can be used in programs for dispatching on the condition, not only
on the signal.

Signals directly map to the exceptions, but there can be more than one
condition that caused the signal.

----------

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

From report at bugs.python.org  Thu Sep  6 04:48:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 08:48:04 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1536223684.94.0.56676864532.issue34587@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Linux RDS manual page says:
https://linux.die.net/man/7/rds

"The receive queue size limits how much data RDS will put on the receive queue of a socket before marking the socket as congested. When a socket becomes congested, RDS will send a congestion map update to the other participating hosts, who are then expected to stop sending more messages to this port."

=> "other participating hosts (...) are (...) expected to stop sending"

By design, it seems like the Python unit test is going to fail, so I suggest to remove the test.

I don't think that the role of Python is to check how the kernel handles congestion on local RDS sockets.

----------

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

From report at bugs.python.org  Thu Sep  6 05:13:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 09:13:30 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
Message-ID: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

The PEP 399 requires that C accelerator behaves exactly as Python, but a lot of C code truncates type name to an arbitrary length: 80, 100, 200, up to 500 (not sure if it's a number of bytes or characters).

Py_TYPE(obj)->tp_name is a common pattern: it would be nice to have a new "%T" format in PyUnicode_FromFormat(), so it can be used directly in PyErr_Format(), to format an object type name.

Attached PR implements the proposed %T format and modify unicodeobject.c to use it.

I propose to then write a second PR to modify all C code of CPython using Py_TYPE(obj)->tp_name to use the new %T type.

----------
components: Interpreter Core
messages: 324675
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormat(): add %T format for an object type name
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep  6 05:19:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 09:19:20 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536225560.36.0.56676864532.issue34595@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Thu Sep  6 05:23:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 09:23:39 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536225819.81.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

My previous attempt to fix that issue, 7 years ago: bpo-10833 :-)

See also bpo-7330 where I implemented width and precision (ex: "%5.3s") in PyUnicode_FromFormat().

----------

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

From report at bugs.python.org  Thu Sep  6 05:26:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 09:26:57 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536226017.52.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I cannot find %T in printf() manual pages on Fedora 28 (Linux).

I can find it in the strftime() documentation:

   %T     The time in 24-hour notation (%H:%M:%S).  (SU)

But I don't think that it's an issue since printf() and strftime() formatters are exclusive, no? For example, strftime() %s means "number of seconds since the Epoch" whereas printf() %s means a "const char*" byte string.

----------

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

From report at bugs.python.org  Thu Sep  6 05:29:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 09:29:05 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536226145.5.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, PyUnicode_FromFormat() has %A to format as ASCII, whereas printf() already has %A but for a different meaning:

   a, A   For a conversion, the double argument is converted to hexadecimal notation (using the letters abcdef) in the style [-]0xh.hhhhp+-; for A conversion the prefix  0X,  the  letters  ABCDEF, and the exponent separator P is used. (...)

----------

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

From report at bugs.python.org  Thu Sep  6 05:33:51 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Sep 2018 09:33:51 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536226431.19.0.56676864532.issue34595@psf.upfronthosting.co.za>


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

I don't think you have to worry about %T being used by other formatting functions. If (heaven forbid) dates were ever supported by PyUnicode_FromFormat(), there would have to be a way to switch from "normal" argument processing to argument-specific formatting specifiers, anyway.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Sep  6 06:01:32 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 06 Sep 2018 10:01:32 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1536228092.68.0.56676864532.issue34568@psf.upfronthosting.co.za>


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

> but even then types in the typing could themselves implement `__instancecheck__` and `__subclasscheck__` and retain the old behavior.

It doesn't work that way. `__instancecheck__` and `__subclasscheck__` tweaks the behaviour of superclass (i.e. the right argument) in `isinstance()` and `issubclass()`. This is how `isinstance([], typing.Iterable)` works, you can't use the same to tweak `isinstance(typing.Iterable, type)`.

> Hopefully someone with more insight on this can comment my worries. Perhaps the attribute should also be documented as discussed earlier: https://github.com/python/typing/issues/335

No, it is not safe to use it and will not be documented. You missed the point of my previous post, the idea is to add public wrappers in typing that will hide `__origin__` (or whatever else) as an implementation detail. Using `__origin__` is OK however as a *temporary* measure, if you don't want to use `typing_inspect` in the meantime.

----------

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

From report at bugs.python.org  Thu Sep  6 06:20:59 2018
From: report at bugs.python.org (Zahari Dim)
Date: Thu, 06 Sep 2018 10:20:59 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536210430.89.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <CANx7HSYzRXZruKu4eDH5gvyqNP8BONbFVnmxWyupTbS=FodTGQ@mail.gmail.com>


Zahari Dim <zaharid at gmail.com> added the comment:

I believe an argument for including this functionality in the standard library
is that it facilitates writing better error messages and thus better code. Some
results that are returned when one searches for *python ChainMap* are:

  - <https://stackoverflow.com/questions/23392976/what-is-the-purpose-of-collections-chainmap>
  - <http://www.blog.pythonlibrary.org/2016/03/29/python-201-what-is-a-chainmap/>
  - <http://rahmonov.me/posts/python-chainmap/>

All of these mention prominently a layered configuration of some kind. I would
argue that all of the examples would benefit from error checking done along the
lines of the snippet above.

An additional consideration is that the method is best implemented by copying
the `__getitem__` method, which, while short, contains a couple of non trivial
details.

One analog could be `re.search`, which returns an object with information of
both the value that is found and its location, though the `span` attribute of
the Match object. Maybe the method could be called ChainMap.search?
On Thu, Sep 6, 2018 at 6:07 AM Raymond Hettinger <report at bugs.python.org> wrote:
>
>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> I haven't run across this requirement before but it does seem plausible that a person might want to know which underlying mapping found a match (compare with the "which" utility in Bash). On the other hand, we haven't had requests for anything like this for other lookup chains such as determining where a variable appears in the sequence locals-to-nested-scopes-to-globals-to-builtins.
>
> Also, I'm not sure I like the proposed API (the method name and signature).  Perhaps, this should be a docs recipe for a ChainMap subclass or be an example of a standalone search function that the takes the *maps* attribute as one of its arguments.  Will discuss this with the other core devs to get their thoughts.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34586>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Sep  6 07:34:32 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 06 Sep 2018 11:34:32 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536233672.23.0.56676864532.issue30977@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 3e2b29dccc3ca9fbc418bfa312ad655782e250f2 by Tal Einat in branch 'master':
bpo-30977: make uuid.UUID use __slots__ (GH-9078)
https://github.com/python/cpython/commit/3e2b29dccc3ca9fbc418bfa312ad655782e250f2


----------

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

From report at bugs.python.org  Thu Sep  6 07:35:57 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 06 Sep 2018 11:35:57 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536233757.37.0.56676864532.issue30977@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the suggestion and the original patch, Wouter!

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

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

From report at bugs.python.org  Thu Sep  6 07:46:14 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Thu, 06 Sep 2018 11:46:14 +0000
Subject: [issue34568] Types in `typing` not anymore instances of `type` or
 subclasses of "real" types
In-Reply-To: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>
Message-ID: <1536234374.87.0.56676864532.issue34568@psf.upfronthosting.co.za>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

You are obviously right with how `__instancecheck__` and `__subclasscheck__` work. We'd either need something like `__rinstancecheck__` and `__rsubclasscheck__` or `isinstance` and `issubclass` needed to handle this using `types.resolve_bases`, `__origin__`, or something else.

It's unfortunate that `__origin__` cannot be considered to be part of the stable API and that no other suitable API exists. I don't want to add an external dependency only to handle this situation, so I guess I'll just use `__origin__` with Python 3.7+. Hopefully it isn't changed in 3.7 minor versions and hopefully a public API exists in 3.8.

----------

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

From report at bugs.python.org  Thu Sep  6 07:46:56 2018
From: report at bugs.python.org (Matej Cepl)
Date: Thu, 06 Sep 2018 11:46:56 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1536234416.53.0.56676864532.issue17239@psf.upfronthosting.co.za>


Matej Cepl <mcepl at cepl.eu> added the comment:

> I suggest to:
> 
> * close bpo-17318 as a duplicate of this issue (bpo-17239)
> * close bpo-24238
> * close this issue

+1 from me.

----------

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

From report at bugs.python.org  Thu Sep  6 08:00:26 2018
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Thu, 06 Sep 2018 12:00:26 +0000
Subject: [issue16487] Allow ssl certificates to be specified from memory
 rather than files.
In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za>
Message-ID: <1536235226.56.0.56676864532.issue16487@psf.upfronthosting.co.za>


Jan-Philip Gehrcke <jgehrcke at gmail.com> added the comment:

Thanks for the discussion.

Since I tried to join the efforts here in 2016 two years ago I was (and still am) enthusiastic, and willing to invest quite a bit of energy. Still, we have missed the 3.6 and 3.7 releases to change something about the fact that there is no simple way to load certificate data from memory rather than files.

I really appreciate the work that as been done on https://www.python.org/dev/peps/pep-0543/. It's a truly great effort. But I think the fact that we did not land a solution since 2012 is somewhat an indicator showing that building smaller chunks and showing the willingness to iterate on a solution would have led to a more tangible outcome, something that I could use right now when building Python applications (how great would that be?). Honestly, the small API changes that were discussed here for years and that I think I implemented do not seem problematic to me from a maintenance and deprecation perspective. Yes, PEP 543 proposes a more idealistic way of doing things. But I do not see how implementing PEP 543 would have been slowed down or negatively affected in any way by the last patch I proposed.

https://github.com/python/cpython/pull/5162 looks very big, and C is not as much my comfort zone as is Python. Still, please let me know if you would like me to contribute!

By the way, I would have _really_ liked to see the following feedback around the first time I submitted the patch:

> For example it's missing several GIL releases calls. The password callback doesn't look correct in some places.

I remember that this aspect of writing the patch consumed quite a bit of my time and I operated with care, knowing the risks. I very much would have appreciated specific feedback on this. To learn, and to actually address problems.

Jan-Philip

----------

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

From report at bugs.python.org  Thu Sep  6 08:18:56 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 06 Sep 2018 12:18:56 +0000
Subject: [issue32055] Reconsider comparison chaining for containment tests
In-Reply-To: <1510904597.47.0.213398074469.issue32055@psf.upfronthosting.co.za>
Message-ID: <1536236336.96.0.56676864532.issue32055@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Has this been discussed on python-dev? If so, what was the result?

----------
nosy: +taleinat

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

From report at bugs.python.org  Thu Sep  6 09:05:21 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Thu, 06 Sep 2018 13:05:21 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
Message-ID: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>


New submission from Naitree Zhu <naitreey at gmail.com>:

When using @skip decorator, `reason` argument is required. But one could easily overlook that and use it like so:

    class SomeTest(TestCase):

        @skip
        def test_method(self):
            # ...

The test actually passes when running with unittest, because it's equivalent to

    class SomeTest(TestCase):

        def test_method(self):
            # ...
        test_method = skip(test_method)

This gives the illusion that @skip decorator worked as expected.

I propose we should check the passed in `reason`, and raise error if it looks like a function/method, therefore prevent this erroneous usage.

In practice, this behavior has misled people using the decorator in the unintended way. For example: In this chapter of Test-Driven Development with Python (http://www.obeythetestinggoat.com/book/chapter_organising_test_files.html), the author used @skip decorator without `reason` argument.

----------
components: Library (Lib), Tests
messages: 324688
nosy: Naitree Zhu
priority: normal
severity: normal
status: open
title: [unittest] raise error if @skip is used with an argument that looks like a test method
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/issue34596>
_______________________________________

From report at bugs.python.org  Thu Sep  6 09:12:08 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 06 Sep 2018 13:12:08 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <20180906131202.GC27312@ando.pearwood.info>


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

Is there a use-case for reason to be anything but a string?

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

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

From report at bugs.python.org  Thu Sep  6 09:13:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 06 Sep 2018 13:13:28 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1536239608.6.0.56676864532.issue34542@psf.upfronthosting.co.za>


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


New changeset 2d3f2dc9f8376415a31a6de260ccbe6a86f2816d by Christian Heimes (Miss Islington (bot)) in branch '3.7':
bpo-34542: Update test certs and keys (GH-8997) (GH-9007)
https://github.com/python/cpython/commit/2d3f2dc9f8376415a31a6de260ccbe6a86f2816d


----------

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

From report at bugs.python.org  Thu Sep  6 09:56:56 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Thu, 06 Sep 2018 13:56:56 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536242216.78.0.56676864532.issue34596@psf.upfronthosting.co.za>


Naitree Zhu <naitreey at gmail.com> added the comment:

Well, I personally can not think of any. I think `reason` should normally just be string.

If that is ok, I'll be happy to submit a PR that restricts reason to be a string.

----------

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

From report at bugs.python.org  Thu Sep  6 10:25:26 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Sep 2018 14:25:26 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536243926.6.0.56676864532.issue34596@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

It could be interesting to enable uncalled `skip` by setting a default reason of "Unconditional skip" when the argument is a function.

Do note that decorating with an uncalled `skip` does actually work to skip the test currently, but the test is marked as success rather than skipped (see example pasted below).  For this reason, I don't think we should turn it into an error in maintenance releases, as anyone using this accidentally will suddenly have many failing tests.

$ cat test.py
from unittest import TestCase, skip


class Test(TestCase):

    def test_good(self):
        self.assertTrue(1.0)

    def test_bad(self):
        self.assertFalse(1.0)

    @skip
    def test_bad_skip(self):
        self.assertFalse(1.0)

    @skip('always skipped')
    def test_good_skip(self):
        self.assertFalse(1.0)

$ ./python.exe -m unittest test.py -v
test_bad (test.Test) ... FAIL
test_bad_skip (test.Test) ... ok
test_good (test.Test) ... ok
test_good_skip (test.Test) ... skipped 'always skipped'

======================================================================
FAIL: test_bad (test.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/.../test.py", line 10, in test_bad
    self.assertFalse(1.0)
AssertionError: 1.0 is not false

----------------------------------------------------------------------
Ran 4 tests in 0.002s

FAILED (failures=1, skipped=1)

----------
nosy: +zach.ware
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Sep  6 10:27:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 14:27:05 +0000
Subject: [issue30985] Set closing variable in asyncore at close
In-Reply-To: <1500661589.01.0.75637783455.issue30985@psf.upfronthosting.co.za>
Message-ID: <1536244025.37.0.56676864532.issue30985@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I reject the issue. It doesn't seem possible to set the closing attribute without breaking backward compatibility. See discussion:
https://github.com/python/cpython/pull/2804

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

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

From report at bugs.python.org  Thu Sep  6 10:29:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 14:29:10 +0000
Subject: [issue32310] Remove _Py_PyAtExit from Python.h
In-Reply-To: <1513196735.39.0.213398074469.issue32310@psf.upfronthosting.co.za>
Message-ID: <1536244150.46.0.56676864532.issue32310@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

It's unclear if this change is going to break anything. In case of doubt, I chose to reject the change.

Note: I'm working on a project to rework and cleanup the C API, see:
https://pythoncapi.readthedocs.io/
https://pythoncapi.readthedocs.io/split_include.html

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

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

From report at bugs.python.org  Thu Sep  6 10:42:24 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Sep 2018 14:42:24 +0000
Subject: [issue31371] Remove deprecated tkinter.tix module
In-Reply-To: <1504733600.21.0.0387108366765.issue31371@psf.upfronthosting.co.za>
Message-ID: <1536244944.34.0.56676864532.issue31371@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

We missed the boat for 3.7 anyway.

With the PEP 4 argument, I won't push any further for ripping Tix out completely before 2020, but if something happens to break building it on Windows before then my fix will be to remove it from the Windows build.

----------
resolution:  -> later
stage: needs patch -> resolved
status: open -> closed
title: Remove deprecated tkinter.tix module in 3.7 -> Remove deprecated tkinter.tix module
versions:  -Python 3.7

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

From report at bugs.python.org  Thu Sep  6 10:43:47 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Sep 2018 14:43:47 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
In-Reply-To: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>
Message-ID: <1536245027.74.0.56676864532.issue26208@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

pypy3 actually took over the terse exceptions, but without the conditions.  They'd also need error codes from libmpdec now.

>>>> huge = Decimal('9' * 99)
>>>> huge.quantize(Decimal('0.1'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/stefan/tmp/pypy3-v6.0.0-linux64/lib_pypy/_decimal.py", line 842, in quantize
    workctx._ctx, status_ptr)
  File "/home/stefan/tmp/pypy3-v6.0.0-linux64/lib_pypy/_decimal.py", line 1631, in __exit__
    self.context._add_status(status)
  File "/home/stefan/tmp/pypy3-v6.0.0-linux64/lib_pypy/_decimal.py", line 1263, in _add_status
    raise exception
decimal.InvalidOperation

----------

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

From report at bugs.python.org  Thu Sep  6 10:58:52 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Thu, 06 Sep 2018 14:58:52 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536245932.88.0.56676864532.issue34596@psf.upfronthosting.co.za>


Naitree Zhu <naitreey at gmail.com> added the comment:

What would be a good default reason? How about the function name?

    if isinstance(reason, types.FunctionType):
        reason = reason.__name__

For example,

    from unittest import TestCase, skip

    class Test(TestCase):

        @skip
        def test_bad_skip(self):
            self.assertFalse(1.0)

        @skip('always skipped')
        def test_good_skip(self):
            self.assertFalse(1.0)

$?python -m unittest -v test.py 
test_bad_skip (test.Test) ... skipped 'test_bad_skip'
test_good_skip (test.Test) ... skipped 'always skipped'

----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK (skipped=2)


But this wouldn't be very helpful if test method is a lambda (just saying...)

----------

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

From report at bugs.python.org  Thu Sep  6 10:59:08 2018
From: report at bugs.python.org (Zorg)
Date: Thu, 06 Sep 2018 14:59:08 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
Message-ID: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>


New submission from Zorg <zorgiepoo at gmail.com>:

If one wants to compile Python and embed it in their applications, or more generally, deploy the framework / libraries to older systems, then Python needs to check the existence of functions at runtime that are unavailable to Python's supported minimum OS.

For example, Python makes use of:
clock_gettime
getentropy

These functions are only available on macOS 10.12. Python currently states it supports 10.9. Checking for their existence at compile time isn't good enough; compiling Python on 10.13 and deploying back to 10.9 or 10.11 for example will not work, and cause a crash at runtime. One can make sure the functions are weakly linked and check they aren't NULL to get around this.

There may be more such functions Python is using; I haven't extensively searched for all usages.

Alternatively, Python could state that it does not properly support embedding (probably not desirable), or Python could bump the minimum supported OS requirements in its documentation.

Else one might be able to compile Python by turning off such features? But the user needs to know what those are, Python gives no warnings when MACOSX_DEPLOYMENT_TARGET/--mmacosx-version-min are low enough, and Python wouldn't be able to use those functions when they are actually available on newer systems.

----------
components: macOS
messages: 324698
nosy: Zorg, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python needs to check existence of functions at runtime for targeting older macOS platforms
type: crash
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep  6 11:16:07 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Sep 2018 15:16:07 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536246967.0.0.56676864532.issue34596@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

"Unconditionally" :)

----------

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

From report at bugs.python.org  Thu Sep  6 11:48:27 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Thu, 06 Sep 2018 15:48:27 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536248907.64.0.56676864532.issue34596@psf.upfronthosting.co.za>


Naitree Zhu <naitreey at gmail.com> added the comment:

Hi @zach.ware, Just to make sure I'm getting this right (first time contributing to cpython...)

Now I need to open 4 PRs at GitHub,

- 1 PR to master branch, with following changes: raise TypeError when `reason` is not a string. (Include unit test.)
- 3 PRs to 3.7, 3.6, and 2.7, with following changes: Setting `reason` to "Unconditionally" when `reason` is a function. (Include unit test.)

Looking good?

----------

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

From report at bugs.python.org  Thu Sep  6 11:49:54 2018
From: report at bugs.python.org (Tim Lesher)
Date: Thu, 06 Sep 2018 15:49:54 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536248994.33.0.56676864532.issue34590@psf.upfronthosting.co.za>


Change by Tim Lesher <tlesher at gmail.com>:


----------
nosy: +tlesher

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

From report at bugs.python.org  Thu Sep  6 11:53:43 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Sep 2018 15:53:43 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536249223.41.0.56676864532.issue34596@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I think we should make the same change on all branches (why would we fix it in maintenance branches just to break it in the next major release?), in which case it's just one PR to master and our backport bot (and/or the merging core dev) will take care of it from there.

----------

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

From report at bugs.python.org  Thu Sep  6 11:54:00 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 06 Sep 2018 15:54:00 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536249240.92.0.56676864532.issue34596@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord, rbcollins

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

From report at bugs.python.org  Thu Sep  6 12:09:03 2018
From: report at bugs.python.org (andy polandski)
Date: Thu, 06 Sep 2018 16:09:03 +0000
Subject: [issue34598] How to fix? Error in Kali linux python 2.7 - Collecting
 pip From cffi callback <function _verify_callback at 0x7f9b12e56050>:
 Traceback (most recent call last): File
 "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in wrapper
Message-ID: <1536250143.3.0.56676864532.issue34598@psf.upfronthosting.co.za>


New submission from andy polandski <peterlandski at gmail.com>:

root at kali:~# python get-pip.py
Collecting pip
>From cffi callback <function _verify_callback at 0x7f9b12e56050>:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in wrapper
    _lib.X509_up_ref(x509)
AttributeError: 'module' object has no attribute 'X509_up_ref'
  Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),)': /simple/pip/

----------
messages: 324702
nosy: andy polandski
priority: normal
severity: normal
status: open
title: How to fix? Error in Kali linux python 2.7 - Collecting pip From cffi callback <function _verify_callback at 0x7f9b12e56050>: Traceback (most recent call last):   File "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in wrapper
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  6 12:13:20 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Thu, 06 Sep 2018 16:13:20 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536250400.78.0.56676864532.issue34596@psf.upfronthosting.co.za>


Naitree Zhu <naitreey at gmail.com> added the comment:

Ok, I see. Thank you.

----------

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

From report at bugs.python.org  Thu Sep  6 12:41:30 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Sep 2018 16:41:30 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536252090.43.0.56676864532.issue34596@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  6 12:59:55 2018
From: report at bugs.python.org (Eric Wieser)
Date: Thu, 06 Sep 2018 16:59:55 +0000
Subject: [issue34305] inspect.getsourcefile and inspect.getcomments do not
 work with decorated functions
In-Reply-To: <1533108053.89.0.56676864532.issue34305@psf.upfronthosting.co.za>
Message-ID: <1536253195.76.0.56676864532.issue34305@psf.upfronthosting.co.za>


Eric Wieser <wieser.eric+pybug at gmail.com> added the comment:

Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.

----------

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

From report at bugs.python.org  Thu Sep  6 13:03:02 2018
From: report at bugs.python.org (Eric Wieser)
Date: Thu, 06 Sep 2018 17:03:02 +0000
Subject: [issue32782] ctypes: memoryview gives incorrect PEP3118 itemsize for
 array of length zero
In-Reply-To: <1517943201.04.0.467229070634.issue32782@psf.upfronthosting.co.za>
Message-ID: <1536253382.35.0.56676864532.issue32782@psf.upfronthosting.co.za>


Eric Wieser <wieser.eric+pybug at gmail.com> added the comment:

Pinging again, for lack of a clearer path forward

----------

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

From report at bugs.python.org  Thu Sep  6 13:14:45 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 06 Sep 2018 17:14:45 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536254085.71.0.56676864532.issue34597@psf.upfronthosting.co.za>


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

The primary Python.org installer supports 10.9 and later by way of being compiled on 10.9, and there is also an installer that supports 10.6. 

There currently is no promise that building on 10.13 results in code that works on earlier versions of macOS.

That said, I agree that building on later macOS releases and deploying to older ones is useful, and this is something that I used to do in the past (I currently have the good fortune to only need to deploy to macOS 10.13). 

It is possible to add runtime checks for APIs, that's something I've done in the past to for the same reason, and that code is still present (for example in posixmodule.c).

Is this something you can and want to work on?

----------

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

From report at bugs.python.org  Thu Sep  6 14:12:15 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 06 Sep 2018 18:12:15 +0000
Subject: [issue34599] improve performance of _Py_bytes_capitalize()
Message-ID: <1536257534.96.0.56676864532.issue34599@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

Currently _Py_bytes_capitalize() checks case before using conversion table, performance can be improved by using conversion table unconditionally. Benchmarks:

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "b = b'0'*10000000" "b.capitalize()"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 7.26 ms +- 0.03 ms
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 7.27 ms +- 0.04 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 7.26 ms +- 0.03 ms -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 7.27 ms +- 0.04 ms: 1.00x slower (+0%)
Not significant!

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "b = b'a'*10000000" "b.capitalize()"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 7.25 ms +- 0.03 ms
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 7.26 ms +- 0.03 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 7.25 ms +- 0.03 ms -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 7.26 ms +- 0.03 ms: 1.00x slower (+0%)

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "b = b'A'*10000000" "b.capitalize()"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 18.1 ms +- 0.0 ms
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 7.31 ms +- 0.13 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 18.1 ms +- 0.0 ms -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 7.31 ms +- 0.13 ms: 2.47x faster (-60%)

----------
components: Interpreter Core
messages: 324707
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: improve performance of _Py_bytes_capitalize()
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep  6 14:13:12 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 06 Sep 2018 18:13:12 +0000
Subject: [issue34599] improve performance of _Py_bytes_capitalize()
In-Reply-To: <1536257534.96.0.56676864532.issue34599@psf.upfronthosting.co.za>
Message-ID: <1536257592.3.0.56676864532.issue34599@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  6 14:38:14 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 06 Sep 2018 18:38:14 +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: <1536259094.36.0.56676864532.issue25750@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +8542

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

From report at bugs.python.org  Thu Sep  6 14:39:16 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Thu, 06 Sep 2018 18:39:16 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536259156.26.0.56676864532.issue34561@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

So it looks like we're working with a logarithmic measure of the "cost". 

I'm operating largely based on your description of Timsort in the link in msg324597, which the paper also refers to. But since the paper is sorting an array of Java ints (not Integers), I assume the performance comparisons of the code they timed is not really representative of Python equivalents. Probably galloping boosts are much larger in the Python case.

I haven't tried running the attached code yet, because I mostly carry a tablet with me now. The never-equal assert probably doesn't get any more obvious by running the code, though, anyway?-).

----------

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

From report at bugs.python.org  Thu Sep  6 14:43:41 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 Sep 2018 18:43:41 +0000
Subject: [issue34594] Some tests use hardcoded errno values
In-Reply-To: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>
Message-ID: <1536259421.98.0.56676864532.issue34594@psf.upfronthosting.co.za>


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


New changeset b03c2c51909e3b5b5966d86a2829b5ddf2d496aa by Benjamin Peterson (Zackery Spytz) in branch 'master':
closes bpo-34594: Don't hardcode errno values in the tests. (GH-9076)
https://github.com/python/cpython/commit/b03c2c51909e3b5b5966d86a2829b5ddf2d496aa


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Sep  6 15:02:30 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 06 Sep 2018 19:02:30 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536260550.56.0.56676864532.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

The notion of cost is that merging runs of lengths A and B has "cost" A+B, period.  Nothing to do with logarithms.  Merge runs of lengths 1 and 1000, and it has cost 1001.

They don't care about galloping, only about how the order in which merges are performed affect that notion of cost.  Example:  suppose we have runs of lengths 1, 2, and 3.  Merge 1 and 2 first for a cost of 1+2 = 3, and we're left with runs of length 3 and 3.  Merge those for a cost of 3+3 = 6, and add to the earlier cost of 3 for a total cost of 9.  But if 2 and 3 are merged first that has cost 5, then merging runs of length 1 and 5 has a cost of 6, added to the earlier 5 gives a total cost of 11.  So it's cheaper to merge 1 and 2 first.

Galloping has nothing to do with this measure, nor does the binary insertion sort portion of timsort.  And Java itself doesn't use timsort for sorting integers anyway (the overheads are too high when comparisons are dirt cheap).  They're trying to quantify the effects of their merge-ordering strategies, relative to timsort's merge-ordering strategy.

Which could have been done more clearly by ignoring Java's timsort implementation entirely and just changing the parts of their code that implement _their_ merge-ordering strategy.  timsort's strategy is hard to analyze, but is trivially easy to _implement_.  As is, they're inadvertently timing all sorts of stuff that's orthogonal to the merge-ordering strategy.

----------

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

From report at bugs.python.org  Thu Sep  6 15:17:38 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Thu, 06 Sep 2018 19:17:38 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536261458.44.0.56676864532.issue34590@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

Something... related, that may perhaps belong in a separate issue, but that I want to at least mention here because it would be solved if logging-in-libraries best practices were authoritatively documented and exemplified: it's just too consarn easy to "hold [the logging module] wrong" and wind up with "No handlers could be found for logger" log spam: https://www.google.ca/search?q=site:stackoverflow.com+"No+handlers+could+be+found+for+logger". Why should a Logger object need to have .basicConfig() called on it after retrieval (where "retrieval" means "getLogger call") and before use anyway? Why can't it just be ready for use (at least as ready for use as .basicConfig makes it) when passed from the logging module to the logging-using module like nearly any other object passed from the standard library to standard-library-using code?

(The documentation says "No handlers could be found for logger" spam only happens pre-3.2, but some of my users at least think they see it in later Pythons.)

----------

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

From report at bugs.python.org  Thu Sep  6 16:27:14 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Thu, 06 Sep 2018 20:27:14 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536265634.7.0.56676864532.issue34561@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

Sorry, I meant that the funny code in the "power" computation in powersort is a logarithmic measure. 

But I don't know where that came from. I just looked at Timsort and now figuring out how powersort is different.

----------

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

From report at bugs.python.org  Thu Sep  6 17:31:24 2018
From: report at bugs.python.org (Erik Janssens)
Date: Thu, 06 Sep 2018 21:31:24 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1536269484.18.0.56676864532.issue34217@psf.upfronthosting.co.za>


Change by Erik Janssens <erik.janssens at conceptive.be>:


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

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

From report at bugs.python.org  Thu Sep  6 17:49:21 2018
From: report at bugs.python.org (Erik Janssens)
Date: Thu, 06 Sep 2018 21:49:21 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1536270561.92.0.56676864532.issue34553@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

for what's it worth, I've observed similar crashes under these strange circumstances :

- the crashes don't appear in python 3.4, but they do in 3.5 (maybe due to switch in msvc runtime)

- the crashes do appear when run as script, the exact same commands in the repl work as expected

- the crashes behave the same when using ActiveQt/PyQt instead of pywin32, which suggests it's not a pywin32 issue

----------
nosy: +erikjanss

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

From report at bugs.python.org  Thu Sep  6 18:04:13 2018
From: report at bugs.python.org (pms.coder)
Date: Thu, 06 Sep 2018 22:04:13 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536271453.38.0.56676864532.issue34200@psf.upfronthosting.co.za>


pms.coder <pms.coder at yandex.com> added the comment:

I have the same issue on Debian 9:

== CPython 3.8.0a0 (heads/master:874809e, Sep 6 2018, 23:31:00) [GCC 6.3.0 20170516]
== Linux-4.9.0-6-amd64-x86_64-with-glibc2.17 little-endian
== cwd: /home/xxx/xxx/cpython/git/cpython/build/test_python_55266
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
Using random seed 1679661
Run tests in parallel using 6 child processes
0:00:00 load avg: 0.35 [1/1/1] test_pkg failed
test_1 (test.test_pkg.TestPkg) ... ok
test_2 (test.test_pkg.TestPkg) ... ok
test_3 (test.test_pkg.TestPkg) ... ok
test_4 (test.test_pkg.TestPkg) ... ERROR
test_5 (test.test_pkg.TestPkg) ... ok
test_6 (test.test_pkg.TestPkg) ... ok
test_7 (test.test_pkg.TestPkg) ... FAIL
test_8 (test.test_pkg.TestPkg) ... ok

======================================================================
ERROR: test_4 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/xxx/xxx/cpython/git/cpython/Lib/test/test_pkg.py", line 180, in test_4
    self.run_code(s)
  File "/home/xxx/xxx/cpython/git/cpython/Lib/test/test_pkg.py", line 69, in run_code
    exec(textwrap.dedent(code), globals(), {"self": self})
  File "<string>", line 2, in <module>
  File "/tmp/tmppheh3y0k/t4.py", line 1, in <module>
RuntimeError: Shouldnt load t4.py

======================================================================
FAIL: test_7 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/xxx/xxx/cpython/git/cpython/Lib/test/test_pkg.py", line 260, in test_7
    '__name__', '__package__', '__path__', '__spec__'])
AssertionError: Lists differ: ['__c[34 chars]__loader__', '__name__', '__package__', '__spec__'] != ['__c[34 chars]__loader__', '__name__', '__package__', '__path__', '__spec__']

First differing element 6:
'__spec__'
'__path__'

Second list contains 1 additional elements.
First extra element 7:
'__spec__'

  ['__cached__',
   '__doc__',
   '__file__',
   '__loader__',
   '__name__',
   '__package__',
+  '__path__',
   '__spec__']

----------------------------------------------------------------------
Ran 8 tests in 0.028s

FAILED (failures=1, errors=1)
test test_pkg failed

== Tests result: FAILURE ==

1 test failed:
    test_pkg

----------
nosy: +pms.coder

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

From report at bugs.python.org  Thu Sep  6 18:06:20 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Thu, 06 Sep 2018 22:06:20 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536271580.75.0.56676864532.issue34561@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

And by "looking at" Timsort, I mean reading your explanation. The motivation for merge ordering and so on was already quite clear from there. But that motivation does not imply that the stack has to be monotonous in run length, although memory considerations might.

----------

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

From report at bugs.python.org  Thu Sep  6 18:27:09 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 06 Sep 2018 22:27:09 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1536272829.61.0.56676864532.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

No, there's no requirement that run lengths on the stack be ordered in any way by magnitude.  That's simply one rule timsort uses, as well as 2-merge and various other schemes discussed in papers.  powersort has no such rule, and that's fine.

Regardless, rules must be such that the max stack size is at worst logarithmic in the number of array elements.  It's also nice if it's obvious that a sequence of equal-length runs will lead to perfectly balanced merges, which is "obvious enough" with the timsort and 2-merge rules.  It also happens to be true of the powersort rules, but harder to see from staring at code because it's hard to compute "node powers" in one's head.

----------

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

From report at bugs.python.org  Thu Sep  6 18:54:53 2018
From: report at bugs.python.org (Ross Burton)
Date: Thu, 06 Sep 2018 22:54:53 +0000
Subject: [issue34585] Don't use AC_RUN_IFELSE to determine float endian
In-Reply-To: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>
Message-ID: <1536274493.22.0.56676864532.issue34585@psf.upfronthosting.co.za>


Change by Ross Burton <ross at burtonini.com>:


----------
pull_requests: +8543
stage:  -> patch review

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

From report at bugs.python.org  Thu Sep  6 23:33:00 2018
From: report at bugs.python.org (wim glenn)
Date: Fri, 07 Sep 2018 03:33:00 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536291180.33.0.56676864532.issue28617@psf.upfronthosting.co.za>


Change by wim glenn <wim.glenn at gmail.com>:


----------
pull_requests: +8545
stage: commit review -> patch review

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

From report at bugs.python.org  Fri Sep  7 00:54:54 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Sep 2018 04:54:54 +0000
Subject: [issue34599] improve performance of _Py_bytes_capitalize()
In-Reply-To: <1536257534.96.0.56676864532.issue34599@psf.upfronthosting.co.za>
Message-ID: <1536296094.61.0.56676864532.issue34599@psf.upfronthosting.co.za>


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


New changeset 593bb30e82eded7f2ec02f7d1aa49742e6962113 by Benjamin Peterson (Sergey Fedoseev) in branch 'master':
closes bpo-34599: Improve performance of _Py_bytes_capitalize(). (GH-9083)
https://github.com/python/cpython/commit/593bb30e82eded7f2ec02f7d1aa49742e6962113


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Sep  7 00:57:35 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Fri, 07 Sep 2018 04:57:35 +0000
Subject: [issue34276] urllib.parse doesn't round-trip file URI's with multiple
 leading slashes
In-Reply-To: <1532925543.25.0.56676864532.issue34276@psf.upfronthosting.co.za>
Message-ID: <1536296255.49.0.56676864532.issue34276@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

file URI scheme is covered by RFC8089, specifically https://tools.ietf.org/html/rfc8089#appendix-E.3.2.

----------
nosy: +v2m

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

From report at bugs.python.org  Fri Sep  7 01:37:01 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 07 Sep 2018 05:37:01 +0000
Subject: [issue34585] Don't use AC_RUN_IFELSE to determine float endian
In-Reply-To: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>
Message-ID: <1536298621.97.0.56676864532.issue34585@psf.upfronthosting.co.za>


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


----------
nosy: +yan12125

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

From report at bugs.python.org  Fri Sep  7 02:10:16 2018
From: report at bugs.python.org (Martin Hosken)
Date: Fri, 07 Sep 2018 06:10:16 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
Message-ID: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>


New submission from Martin Hosken <martin_hosken at sil.org>:

This is a regression from python2 by being forced to use cElementTree.

I have code that uses iterparse to process an XML file, but I also want to process comments and so I have a comment handling function called by the parser during iterparse. Under python3 I can find no way to achieve the same thing:

```
parser = et.XMLParser(target=et.TreeBuilder())
parser.parser.CommentHandler = myCommentHandler
for event, elem in et.iterparse(fh, parser=parser):
    ...
```

Somewhat ugly but works in python2, but I can find no way to set a comment handler on the parser in python3.


1. There is no way(?) to get to xml.etree.ElementTree.XMLParser since the C implementation completely masks the python versions.
2. It is possible to create a subclass of TreeBuilder to add a comment method. But the C version XMLParser requires that its TreeBuilder not be a subclass, when used in iterparse.

The only solution I found was to copy the XMLParser code out of ElementTree into a private module and use that pure python implementation.

Suggested solutions:
1. Allow access to all the python implementations in ElementTree and not just Element.
2. Allow a comments method to be passed to the XMLParser on creation.

Thank you.

----------
components: XML
messages: 324719
nosy: Martin Hosken
priority: normal
severity: normal
status: open
title: python3 regression ElementTree.iterparse() unable to capture comments
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  7 02:35:02 2018
From: report at bugs.python.org (David Lin)
Date: Fri, 07 Sep 2018 06:35:02 +0000
Subject: [issue34601] Typo: "which would rather raise MemoryError than give
 up", than or then?
Message-ID: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>


New submission from David Lin <david.dl.lin at nokia-sbell.com>:

https://docs.python.org/3/library/exceptions.html

exception OverflowError
Raised when the result of an arithmetic operation is too large to be represented. This cannot occur for integers (which would rather raise MemoryError than give up). However, for historical reasons, OverflowError is sometimes raised for integers that are outside a required range. Because of the lack of standardization of floating point exception handling in C, most floating point operations are not checked.

In sentence: "which would rather raise MemoryError than give up", should we use "then" instead of "than"?

Thanks,
David Lin

----------
assignee: docs at python
components: Documentation
messages: 324720
nosy: davidlin, docs at python
priority: normal
severity: normal
status: open
title: Typo: "which would rather raise MemoryError than give up", than or then?
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 03:05:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 07:05:40 +0000
Subject: [issue34599] improve performance of _Py_bytes_capitalize()
In-Reply-To: <1536257534.96.0.56676864532.issue34599@psf.upfronthosting.co.za>
Message-ID: <1536303940.71.0.56676864532.issue34599@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Nice optimization Sergey Fedoseev, thanks!

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

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

From report at bugs.python.org  Fri Sep  7 03:37:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 07:37:05 +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: <1536305825.84.0.56676864532.issue25750@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8f735485acf2e35a75d2fa019feb8f905598c4e5 by Victor Stinner (jdemeyer) in branch 'master':
bpo-25750: fix refcounts in type_getattro() (GH-6118)
https://github.com/python/cpython/commit/8f735485acf2e35a75d2fa019feb8f905598c4e5


----------

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

From report at bugs.python.org  Fri Sep  7 03:37:19 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 07:37:19 +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: <1536305839.61.0.56676864532.issue25750@psf.upfronthosting.co.za>


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


----------
pull_requests: +8546

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

From report at bugs.python.org  Fri Sep  7 03:37:28 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 07:37:28 +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: <1536305848.01.0.56676864532.issue25750@psf.upfronthosting.co.za>


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


----------
pull_requests: +8547

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

From report at bugs.python.org  Fri Sep  7 03:37:36 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 07:37:36 +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: <1536305856.8.0.56676864532.issue25750@psf.upfronthosting.co.za>


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


----------
pull_requests: +8548

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

From report at bugs.python.org  Fri Sep  7 03:50:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 07:50:44 +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: <1536306644.05.0.56676864532.issue25750@psf.upfronthosting.co.za>


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


New changeset f862f3abaed59b83763707ae529f0fe487961ba9 by Miss Islington (bot) in branch '3.7':
bpo-25750: fix refcounts in type_getattro() (GH-6118)
https://github.com/python/cpython/commit/f862f3abaed59b83763707ae529f0fe487961ba9


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

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

From report at bugs.python.org  Fri Sep  7 03:56:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 07:56:06 +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: <1536306966.51.0.56676864532.issue25750@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8549

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

From report at bugs.python.org  Fri Sep  7 03:57:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 07:57:48 +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: <1536307068.14.0.56676864532.issue25750@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 3ee07432f2e607cc6e7e6ea2d3695b672ceb1cea by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-25750: fix refcounts in type_getattro() (GH-6118) (GH-9088)
https://github.com/python/cpython/commit/3ee07432f2e607cc6e7e6ea2d3695b672ceb1cea


----------

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

From report at bugs.python.org  Fri Sep  7 03:58:28 2018
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 07 Sep 2018 07:58:28 +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: <1536307108.71.0.56676864532.issue25750@psf.upfronthosting.co.za>


Change by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

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

From report at bugs.python.org  Fri Sep  7 04:00:45 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Sep 2018 08:00:45 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <1536307245.44.0.56676864532.issue34586@psf.upfronthosting.co.za>


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

> I would argue that all of the examples would benefit from error
> checking done along the lines of the snippet above.

ISTM that this is the wrong stage to perform validation of allowable values.  That should occur upstream when the underlying mappings are first created.  At that earlier stage it possible to give a more timely response to erroneous input and there is access to more information (such as the line and row number of an error in a configuration file).  

It doesn't make sense to me to defer value validation downstream after a ChainMap instance has been formed and after a successful lookup has occurred. That just complicates the task of tracing back to the root cause.

> Maybe the method could be called ChainMap.search?

That would be better than get_where().

----------

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

From report at bugs.python.org  Fri Sep  7 04:04:41 2018
From: report at bugs.python.org (pms.coder)
Date: Fri, 07 Sep 2018 08:04:41 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536307481.07.0.56676864532.issue34590@psf.upfronthosting.co.za>


pms.coder <pms.coder at yandex.com> added the comment:

I would be happy to see such HOWTO, so we could relay on actual documentation instead of the "Internet".

I think the best approach would be to get those 10-20 questions you ( Nathaniel Manista) just asked and post them to python-dev mailing list, so senior developers/committers could answer them. 

Then we could establish the "gold standard" for logging and write about it in the HOWTO.

----------
nosy: +pms.coder

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

From report at bugs.python.org  Fri Sep  7 04:13:22 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Sep 2018 08:13:22 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536308002.5.0.56676864532.issue34590@psf.upfronthosting.co.za>


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

> Then we could establish the "gold standard" for logging and write 
> about it in the HOWTO.

There really isn't a gold standard.  There are many widely varied logging practices, each adapted to the needs of the application.  The module is complicated primarily because there are so many legitimate techniques and reasons for using those techniques.

> (The documentation says "No handlers could be found for logger" 
> spam only happens pre-3.2, but some of my users at least think
> they see it in later Pythons.)

If you find an actual error in the docs, please make a specific report so that it can be confirmed and fixed.

----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  7 04:15:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 08:15:42 +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: <1536308142.92.0.56676864532.issue25750@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset bf2bd8f8a1d88de60c114de957f50fe2433e3937 by Victor Stinner in branch '2.7':
bpo-25750: fix refcounts in type_getattro() (GH-6118) (GH-9091)
https://github.com/python/cpython/commit/bf2bd8f8a1d88de60c114de957f50fe2433e3937


----------

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

From report at bugs.python.org  Fri Sep  7 04:16:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 08:16:51 +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: <1536308211.68.0.56676864532.issue25750@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug has been fixed in 2.7, 3.6, 3.7 and master branches. Thanks Jeroen Demeyer for your tenacity and hard work :-)

Let's see what we do with the unit test: PR 9084.

----------

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

From report at bugs.python.org  Fri Sep  7 04:55:35 2018
From: report at bugs.python.org (Zahari Dim)
Date: Fri, 07 Sep 2018 08:55:35 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536307245.44.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <CANx7HSYuJr3q06RevZyve+J5QcTefh35Ans2KUuaB54ALEq8MA@mail.gmail.com>


Zahari Dim <zaharid at gmail.com> added the comment:

> ISTM that this is the wrong stage to perform validation of allowable values.  That should occur upstream when the underlying mappings are first created.  At that earlier stage it possible to give a more timely response to erroneous input and there is access to more information (such as the line and row number of an error in a configuration file).
>
> It doesn't make sense to me to defer value validation downstream after a ChainMap instance has been formed and after a successful lookup has occurred. That just complicates the task of tracing back to the root cause.

This is certainly the case in the situation where the validation only
depends on the value of the corresponding configuration entry, as it
admittedly does in the example above. However the example was
oversimplified insofar non trivial validation depends on the whole
ensemble configuration settings. For example taking the example
described at the top of
<http://rahmonov.me/posts/python-chainmap/>
I think it would be useful to have an error message of the form:
f"User '{db_username}', defined in {configsetttings[user_index]} is
not found in database '{database}', defined in
{configsettings[database_index]}'

>
> > Maybe the method could be called ChainMap.search?
>
> That would be better than get_where().
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34586>
> _______________________________________

----------

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

From report at bugs.python.org  Fri Sep  7 05:30:37 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 07 Sep 2018 09:30:37 +0000
Subject: [issue34594] Some tests use hardcoded errno values
In-Reply-To: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>
Message-ID: <1536312637.32.0.56676864532.issue34594@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8550

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

From report at bugs.python.org  Fri Sep  7 05:36:15 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 07 Sep 2018 09:36:15 +0000
Subject: [issue34594] Some tests use hardcoded errno values
In-Reply-To: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>
Message-ID: <1536312975.91.0.56676864532.issue34594@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8551

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

From report at bugs.python.org  Fri Sep  7 06:34:46 2018
From: report at bugs.python.org (marche147)
Date: Fri, 07 Sep 2018 10:34:46 +0000
Subject: [issue34602] python3 resource.setrlimit strange behaviour under macOS
Message-ID: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>


New submission from marche147 <bitmarche at gmail.com>:

Consider the following code:

```
import resource
s, h = resource.getrlimit(resource.RLIMIT_STACK)
resource.setrlimit(resource.RLIMIT_STACK, (h, h))
```

Running this under macOS with python 3.6.5 gives the following exception:

```
bash-3.2$ uname -a
Darwin arch-osx 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
bash-3.2$ cat test.py
import resource
s, h = resource.getrlimit(resource.RLIMIT_STACK)
resource.setrlimit(resource.RLIMIT_STACK, (h, h))
bash-3.2$ python3 test.py
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    resource.setrlimit(resource.RLIMIT_STACK, (h, h))
ValueError: current limit exceeds maximum limit
```

Nevertheless, when using python 2.7.10 under the same environment, this code works perfectly without exceptions being thrown. Additionally, neither of these operations fail under the same circumstances :

```
bash-3.2$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/resource.h>

int main() {
  struct rlimit rl;
  if(getrlimit(RLIMIT_STACK, &rl) < 0) {
    perror("getrlimit");
    exit(1);
  }

  rl.rlim_cur = rl.rlim_max;
  if(setrlimit(RLIMIT_STACK, &rl) < 0) {
    perror("setrlimit");
    exit(1);
  }
  return 0;
}
bash-3.2$ gcc -o test test.c
bash-3.2$ ./test
```

```
bash-3.2$ ulimit -s -H
65532
bash-3.2$ ulimit -s
8192
bash-3.2$ ulimit -s 65532
bash-3.2$ ulimit -s
65532
```

I have also tried to run the above-mentioned python script on linux, also it does not generate exceptions both on python2 (2.7.10) & python3 (3.6.5).

----------
components: Library (Lib)
messages: 324731
nosy: marche147
priority: normal
severity: normal
status: open
title: python3 resource.setrlimit strange behaviour under macOS
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  7 07:15:17 2018
From: report at bugs.python.org (MatteoL)
Date: Fri, 07 Sep 2018 11:15:17 +0000
Subject: [issue34603] ctypes On Windows: error calling C function that returns
 a struc containing 3 bools
Message-ID: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>


New submission from MatteoL <mlovato at gmail.com>:

Marshalling the following C structure with ctypes in Windows (compiled with VS2015) is not working correctly.
As you can see, in the simple demo program I attached, the integer I pass as a parameter gets somehow corrupted. I use cdecl calling convention.

The corruption happens only if the returned structure contains 3 booleans, if I add a fourth bool to the structure than I get expected results.

In linux (compiling with Gcc) the same code (with 3 booleans) work as expected.


typedef uint64_t CustomHandle;

typedef struct
{
	bool first;
	bool second;
	bool third;
} Flags;

CustomHandle GetHandle();
Flags GetFlags(CustomHandle handle);


As already mention I attached all the files to reproduce the issue with the related cmake file

----------
components: ctypes
files: MarshallingTest.zip
messages: 324732
nosy: mattneri
priority: normal
severity: normal
status: open
title: ctypes On Windows: error calling C function that returns a struc containing 3 bools
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47789/MarshallingTest.zip

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

From report at bugs.python.org  Fri Sep  7 07:25:52 2018
From: report at bugs.python.org (MatteoL)
Date: Fri, 07 Sep 2018 11:25:52 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1536319552.32.0.56676864532.issue34603@psf.upfronthosting.co.za>


Change by MatteoL <mlovato at gmail.com>:


----------
title: ctypes On Windows: error calling C function that returns a struc containing 3 bools -> ctypes on Windows: error calling C function that returns a struct containing 3 bools

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

From report at bugs.python.org  Fri Sep  7 08:06:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 12:06:24 +0000
Subject: [issue33625] Release GIL for grp.getgr{nam, gid} and pwd.getpw{nam,
 uid}
In-Reply-To: <1527105781.7.0.682650639539.issue33625@psf.upfronthosting.co.za>
Message-ID: <1536321984.03.0.56676864532.issue33625@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 23e65b25557f957af840cf8fe68e80659ce28629 by Victor Stinner (William Grzybowski) in branch 'master':
bpo-33625: Release GIL for grp.getgr{nam,gid} and pwd.getpw{nam,uid} (GH-7081)
https://github.com/python/cpython/commit/23e65b25557f957af840cf8fe68e80659ce28629


----------

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

From report at bugs.python.org  Fri Sep  7 08:16:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 12:16:13 +0000
Subject: [issue33625] Release GIL for grp.getgr{nam, gid} and pwd.getpw{nam,
 uid}
In-Reply-To: <1527105781.7.0.682650639539.issue33625@psf.upfronthosting.co.za>
Message-ID: <1536322573.13.0.56676864532.issue33625@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

It has been decided to not touch pwd.getpwall() nor grp.getgrall(): https://github.com/python/cpython/pull/7081

----------

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

From report at bugs.python.org  Fri Sep  7 08:17:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 12:17:24 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536322644.67.0.56676864532.issue34563@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 23f427a0fdb888212136cf8745a9f5f832a3f374 by Victor Stinner (Alexander Buchkovsky) in branch '3.6':
[3.6] bpo-34563: Fix for invalid assert on big output of multiprocessing.Process (GH-9027) (GH-9069)
https://github.com/python/cpython/commit/23f427a0fdb888212136cf8745a9f5f832a3f374


----------

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

From report at bugs.python.org  Fri Sep  7 08:23:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 12:23:22 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536323002.95.0.56676864532.issue34563@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Alexander Buchkovsky for the fix: it has been merged into 3.6, 3.7 and master branches. Thanks Oleksandr Buchkovskyi for the bug report!

--

I looked at the Python 2.7 code and it doesn't look to be impacted by this bug.

Modules/_multiprocessing/pipe_connection.c uses ReadFile() and PeekNamedPipe(), but the result type of the two C functions using it is not a PyObject* and conn_recv_string() looks good to me. Moreover, the type of the buflength parameter of conn_recv_string() is size_t, so there is no signed issue.

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

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

From report at bugs.python.org  Fri Sep  7 08:24:24 2018
From: report at bugs.python.org (Thrlwiti)
Date: Fri, 07 Sep 2018 12:24:24 +0000
Subject: [issue22543] -W option cannot use non-standard categories
In-Reply-To: <1412285520.72.0.615712160291.issue22543@psf.upfronthosting.co.za>
Message-ID: <1536323064.86.0.56676864532.issue22543@psf.upfronthosting.co.za>


Change by Thrlwiti <electronnn at gmail.com>:


----------
nosy: +THRlWiTi

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

From report at bugs.python.org  Fri Sep  7 08:43:06 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 07 Sep 2018 12:43:06 +0000
Subject: [issue34602] python3 resource.setrlimit strange behaviour under macOS
In-Reply-To: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>
Message-ID: <1536324186.88.0.56676864532.issue34602@psf.upfronthosting.co.za>


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

I get the same error, also with python3.7. Both for homebrew and a python.org installer.

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren
versions: +Python 3.7

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

From report at bugs.python.org  Fri Sep  7 09:14:55 2018
From: report at bugs.python.org (William Grzybowski)
Date: Fri, 07 Sep 2018 13:14:55 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
Message-ID: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>


New submission from William Grzybowski <william88 at gmail.com>:

Issue was spotted by @vstinner while reviewing https://github.com/python/cpython/pull/7081

pwd.getpwnam and grp.getgrnam are susceptible to mojibake as they are using encoded bytes instead of unicode in the error message.

----------
components: Extension Modules
messages: 324738
nosy: wg
priority: normal
severity: normal
status: open
title: Possible mojibake in pwd.getpwnam and grp.getgrnam
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/issue34604>
_______________________________________

From report at bugs.python.org  Fri Sep  7 09:24:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 13:24:23 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536326663.88.0.56676864532.issue34604@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner
versions: +Python 2.7 -Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Sep  7 09:34:48 2018
From: report at bugs.python.org (William Grzybowski)
Date: Fri, 07 Sep 2018 13:34:48 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536327288.94.0.56676864532.issue34604@psf.upfronthosting.co.za>


Change by William Grzybowski <william88 at gmail.com>:


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

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

From report at bugs.python.org  Fri Sep  7 09:51:48 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 07 Sep 2018 13:51:48 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1536328308.55.0.56676864532.issue34587@psf.upfronthosting.co.za>


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


----------
nosy: +yan12125

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

From report at bugs.python.org  Fri Sep  7 09:51:57 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 07 Sep 2018 13:51:57 +0000
Subject: [issue34354] Memory leak on _testCongestion
In-Reply-To: <1533705661.31.0.56676864532.issue34354@psf.upfronthosting.co.za>
Message-ID: <1536328317.89.0.56676864532.issue34354@psf.upfronthosting.co.za>


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


----------
nosy: +yan12125

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

From report at bugs.python.org  Fri Sep  7 10:22:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:22:00 +0000
Subject: [issue34605] Avoid master/slave terminology
Message-ID: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

For more context, see:

* https://github.com/antirez/redis/issues/3185
* https://www.drupal.org/node/2275877
* https://issues.apache.org/jira/browse/COUCHDB-2248
* https://github.com/django/django/pull/2692

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
messages: 324739
nosy: Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Avoid master/slave terminology
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep  7 10:26:28 2018
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 07 Sep 2018 14:26:28 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536330388.2.0.56676864532.issue34605@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Do you have examples of where this occurs? 

>From https://github.com/python/cpython/search?p=1&q=master+slave&unscoped_q=master+slave I really only found the openpty function, and the man pages/argument names there already use this terminology so it wouldn't make much sense to change it there.

----------
nosy: +ammar2

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

From report at bugs.python.org  Fri Sep  7 10:32:23 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 07 Sep 2018 14:32:23 +0000
Subject: [issue34601] Typo: "which would rather raise MemoryError than give
 up", than or then?
In-Reply-To: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>
Message-ID: <1536330743.04.0.56676864532.issue34601@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

"than" is correct; "giving up" in this context would mean "not even trying to allocate the memory and just preemptively raising OverflowError, like non-integer numeric types with limited ranges". Rather than giving up that way, it chooses to try to allocate the huge integer and raises a MemoryError only if that fails.

----------
nosy: +josh.r

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

From report at bugs.python.org  Fri Sep  7 10:35:52 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Sep 2018 14:35:52 +0000
Subject: [issue34601] Typo: "which would rather raise MemoryError than give
 up", than or then?
In-Reply-To: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>
Message-ID: <1536330952.94.0.56676864532.issue34601@psf.upfronthosting.co.za>


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

See https://www.collinsdictionary.com/dictionary/english/would-rather for an example:

> I have no information one way or the other, but I would rather he do it
> than not do it.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Sep  7 10:41:59 2018
From: report at bugs.python.org (Kyle Altendorf)
Date: Fri, 07 Sep 2018 14:41:59 +0000
Subject: [issue34606] Unable to read zip file with extra
Message-ID: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>


New submission from Kyle Altendorf <sda at fstab.net>:

This was first found over in Twisted tests.  We probably aren't too terribly worried about it but I wanted to report here anyways.

https://twistedmatrix.com/trac/ticket/9525

Both 3.6 and 3.7 write the same file (sha at the end) based on the script in the first snippet.  3.6 can read both files, 3.7 can't read either.


----
    altendky at lt:~/twisted$ cat ../z.py
    import sys
    import zipfile

    print(sys.version)

    fn = sys.argv[1]
    print(fn)

    with zipfile.ZipFile(fn, 'w') as zf:
        zi = zipfile.ZipInfo("0")
        zi.extra = b"hello, extra"
        zf.writestr(zi, b"the real data")

    zipfile.ZipFile(fn)

----
    altendky at lt:~/twisted$ venv36/bin/python ../z.py 36.zip
    3.6.6 (default, Jul 24 2018, 16:23:12)
    [GCC 6.3.0 20170516]
    36.zip

----
    altendky at lt:~/twisted$ venv37/bin/python ../z.py 37.zip
    3.7.0 (default, Jul  7 2018, 15:49:24)
    [GCC 6.3.0 20170516]
    37.zip
    Traceback (most recent call last):
      File "../z.py", line 14, in <module>
        zipfile.ZipFile(fn)
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1200, in __init__
        self._RealGetContents()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1323, in _RealGetContents
        x._decodeExtra()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 440, in _decodeExtra
        raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
    zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)

----
    altendky at lt:~/twisted$ cat ../z.py
    import sys
    import zipfile

    print(sys.version)

    fn = sys.argv[1]
    print(fn)

    #with zipfile.ZipFile(fn, 'w') as zf:
    #    zi = zipfile.ZipInfo("0")
    #    zi.extra = b"hello, extra"
    #    zf.writestr(zi, b"the real data")

    zipfile.ZipFile(fn)

----
    altendky at lt:~/twisted$ venv36/bin/python ../z.py 37.zip
    3.6.6 (default, Jul 24 2018, 16:23:12)
    [GCC 6.3.0 20170516]
    37.zip

----
    altendky at lt:~/twisted$ venv37/bin/python ../z.py 36.zip
    3.7.0 (default, Jul  7 2018, 15:49:24)
    [GCC 6.3.0 20170516]
    36.zip
    Traceback (most recent call last):
      File "../z.py", line 14, in <module>
        zipfile.ZipFile(fn)
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1200, in __init__
        self._RealGetContents()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1323, in _RealGetContents
        x._decodeExtra()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 440, in _decodeExtra
        raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
    zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)

----
    altendky at lt:~/twisted$ sha256sum 36.zip
    0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6  36.zip

----
    altendky at lt:~/twisted$ sha256sum 37.zip
    0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6  37.zip

----------
components: Library (Lib)
messages: 324743
nosy: altendky
priority: normal
severity: normal
status: open
title: Unable to read zip file with extra
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 10:43:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:43:19 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536331399.21.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm working on patches to change that.

----------

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

From report at bugs.python.org  Fri Sep  7 10:43:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:43:31 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536331411.86.0.56676864532.issue34605@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Fri Sep  7 10:44:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:44:46 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536331486.72.0.56676864532.issue34605@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8554

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

From report at bugs.python.org  Fri Sep  7 10:47:03 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Sep 2018 14:47:03 +0000
Subject: [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536331623.11.0.56676864532.issue34590@psf.upfronthosting.co.za>


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

> Should I make use of a single logger object in my library, multiple loggers
> in a tree, or multiple unrelated loggers? Since I have just one public module,
> I'm tempted to say that I should just use one logger object.

Yes. The advanced logging tutorial (part of the HOWTO) states:

"A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

This means that logger names track the package/module hierarchy, and it?s intuitively obvious where events are logged just from the logger name."

This seems clear enough to me. Did you look at the whole of the HOWTO? If not, I'd advise you to take the time

> (The documentation says "No handlers could be found for logger" 
> spam only happens pre-3.2, but some of my users at least think
> they see it in later Pythons.)

In 3.2, the change was made to introduce a "handler of last resort" instead of the "no handlers could be found" message, which is only printed if logging.lastResort is set to None or other "false" value (by default, it's set to a console handler at WARNING level emitting to sys.stderr). If you can give specifics of a later Python version where this happens (precise Python version, OS etc.) then we can address it.

Practices vary widely because use cases for logging are widely varied. A simple one-off script has different needs from a product with a long shelf-life, a command-line application has different needs from a long-running server application, a single-author application has different needs from one which is put together from lots of different dependencies by different authors, etc.

> Why should a Logger object need to have .basicConfig() called on
> it after retrieval (where "retrieval" means "getLogger call") and
> before use anyway?

It doesn't. If you want output, you need handlers. The basicConfig() API is just one way of attaching handlers to loggers for simple use cases. The question of handlers is also no concern of a library author, other than the NullHandler part, as the application is where logging should be configured (as mentioned in the "Configuring Logging for a Library" section).

> Then we could establish the "gold standard" for logging and write
> about it in the HOWTO.

There's no one size fits all, I'm afraid, because the package is designed to cover a wide range of use cases, not just the simplest ones. While there is (IMO) comprehensive documentation, specific proposals for improvements will be looked at constructively.

----------

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

From report at bugs.python.org  Fri Sep  7 10:51:17 2018
From: report at bugs.python.org (Zorg)
Date: Fri, 07 Sep 2018 14:51:17 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536331877.13.0.56676864532.issue34597@psf.upfronthosting.co.za>


Zorg <zorgiepoo at gmail.com> added the comment:

The minimum OS target (which looks like 10.13) should ideally be well defined and tested using the latest SDK, rather than there being "no promises". Or at least it should be documented that this isn't currently supported, or how to disable specific features and which ones to disable. I downloaded the source tarball from https://www.python.org/downloads/release/python-370/

Python then isn't viable currently for embedding inside applications (https://docs.python.org/3/extending/embedding.html). 3rd party app developers on macOS typically have a policy at least supporting back to N-1 or N-2'th OS, and in many cases it shouldn't be their dependencies that drive this. 

The other two functions require 10.13:
futimens
utimensat

Fortunately the -Wunguarded-availability warning is enabled which spits out warnings on which functions aren't available when targeting a min OS (MACOSX_DEPLOYMENT_TARGET)

Can't say I can contribute anything here unfortunately :(. I had to do something though, so I hacked the configure scripts and pyconfig.h to make sure the clock_* and the above functions I mentioned above weren't being used. getentropy was easy to fix more properly because it already has a fallback at runtime in case it's not working, so it was just an additional NULL check. Looks like the functions are weakly referenced when building to an older OS target.

A bad step in future direction would be to continue making "no promises" and start using functionality only available on 10.14, 10.15, etc without fallback.

----------

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

From report at bugs.python.org  Fri Sep  7 10:57:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:57:23 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332243.33.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

IMHO it's ok to keep the "master" term for:

* Git "master" branch
* "webmaster"
* "postmaster"

To find all impacted files, I used the commend:

git grep -i -E 'master|slave'|grep -v -E 'webmaster|postmaster|/blob/master/'

----------

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

From report at bugs.python.org  Fri Sep  7 10:58:40 2018
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 07 Sep 2018 14:58:40 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332320.26.0.56676864532.issue34605@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The libregrtest change looks good but I disagree on the pty/openpty changes. If you look at all the current Linux man pages and documentation, they follow the master/slave terminology. Generally, Python documentation for underlying os functions like fork, stat etc are kept short because the OS documentation is the ultimate resource for them. 

This change causes a deviation from the existing standard and will only serve to make things more confusing, I would suggest deferring it until the actual OS documentation reflects this change as well.

----------

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

From report at bugs.python.org  Fri Sep  7 10:59:08 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 14:59:08 +0000
Subject: [issue34513] test_multiprocessing_spawn fails on x86 Windows7 3.7
 buildbot
In-Reply-To: <1535330423.47.0.56676864532.issue34513@psf.upfronthosting.co.za>
Message-ID: <1536332348.29.0.56676864532.issue34513@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

New failure on x86 Windows7 3.6 buildbot:

https://buildbot.python.org/all/#/builders/90/builds/519/steps/3/logs/stdio

----------

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

From report at bugs.python.org  Fri Sep  7 10:59:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:59:52 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332392.01.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The doctest module has doctest.master symbol:
---
# For backward compatibility, a global instance of a DocTestRunner
# class, updated by testmod.
master = None
---

I'm not sure about changing this one. Here there is no slave, so it's less confusing.

But more generally, maybe it's time to remove this deprecated variable only kept for backward compatibility?

----------

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

From report at bugs.python.org  Fri Sep  7 11:00:13 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 15:00:13 +0000
Subject: [issue34513] test_multiprocessing_spawn fails on x86 Windows7 3.7
 buildbot
In-Reply-To: <1535330423.47.0.56676864532.issue34513@psf.upfronthosting.co.za>
Message-ID: <1536332413.72.0.56676864532.issue34513@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

New failure on x86 Windows7 3.x: https://buildbot.python.org/all/#/builders/58/builds/1295/steps/3/logs/stdio

test_no_import_lock_contention (test.test_multiprocessing_spawn.WithProcessesTestQueue) ... ok
Timeout (0:15:00)!
Thread 0x00000f10 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 296 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\queues.py", line 224 in _feed
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 865 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 917 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 885 in _bootstrap
Thread 0x00000ea0 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\queues.py", line 82 in put
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 163 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 173 in handle
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 738 in assertRaises
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 862 in test_put
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 610 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 658 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1900 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1990 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 179 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\__main__.py", line 2 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\spawn.py", line 117, in spawn_main
    exitcode = _main(fd)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\spawn.py", line 127, in _main
    self = reduction.pickle.load(from_parent)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\connection.py", line 951, in rebuild_pipe_connection
    handle = dh.detach()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\reduction.py", line 133, in detach
    self._access, False, _winapi.DUPLICATE_CLOSE_SOURCE)
PermissionError: [WinError 5] Access is denied
program finished with exit code 1

----------

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

From report at bugs.python.org  Fri Sep  7 11:00:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:00:49 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332449.34.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Tkinter and IDLE are full of "master" variables:

   master: parent for widgets.

It seems to be a keep concept of Tkinter windows.

----------

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

From report at bugs.python.org  Fri Sep  7 11:02:01 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 15:02:01 +0000
Subject: [issue34607] test_multiprocessing_forkserver is altering the
 environment on AMD64 FreeBSD 10.x Shared 3.7
Message-ID: <1536332520.99.0.56676864532.issue34607@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_multiprocessing_forkserver is altering the environment on AMD64 FreeBSD 10.x Shared 3.7:

https://buildbot.python.org/all/#/builders/124/builds/545/steps/4/logs/stdio

== Tests result: ENV CHANGED ==
393 tests OK.
10 slowest tests:
- test_tools: 8 min 56 sec
- test_tokenize: 5 min 47 sec
- test_multiprocessing_spawn: 5 min 42 sec
- test_multiprocessing_forkserver: 4 min 29 sec
- test_lib2to3: 4 min 3 sec
- test_multiprocessing_fork: 3 min 46 sec
- test_concurrent_futures: 3 min 43 sec
- test_asyncio: 2 min 36 sec
- test_compile: 1 min 49 sec
- test_io: 1 min 45 sec
1 test altered the execution environment:
    test_multiprocessing_forkserver
22 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_idle test_ioctl
    test_msilib test_ossaudiodev test_smtpnet test_spwd test_ssl
    test_startfile test_tcl test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_turtle test_winconsoleio test_winreg
    test_winsound test_zipfile64
Total duration: 20 min 58 sec
Tests result: ENV CHANGED
*** Error code 3
Stop.
make: stopped in /usr/home/buildbot/python/3.7.koobs-freebsd10/build
program finished with exit code 1
elapsedTime=1260.965772

----------
components: Tests
messages: 324753
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_multiprocessing_forkserver is altering the environment on AMD64 FreeBSD 10.x Shared 3.7
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 11:04:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:04:06 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332646.59.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

nntplib.NNTP() has a slave() method, but this method sends a "SLAVE" command to the NNTP server. Changing that would require to modify the NNTP protocol, that's out of the scope of this issue...

RFC 977 "Network News Transfer Protocol" (NNTP)
Section 3.12: The SLAVE command
https://tools.ietf.org/html/rfc977

----------

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

From report at bugs.python.org  Fri Sep  7 11:06:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:06:26 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332786.42.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

In the C API, PyMemoryViewObject has a mbuf.master attribute, Include/memoryview.h:

---
typedef struct {
    PyObject_HEAD
    int flags;          /* state flags */
    Py_ssize_t exports; /* number of direct memoryview exports */
    Py_buffer master; /* snapshot buffer obtained from the original exporter */
} _PyManagedBufferObject;


/* memoryview state flags */
#define _Py_MEMORYVIEW_RELEASED    0x001  /* access to master buffer blocked */
#define _Py_MEMORYVIEW_C           0x002  /* C-contiguous layout */
#define _Py_MEMORYVIEW_FORTRAN     0x004  /* Fortran contiguous layout */
#define _Py_MEMORYVIEW_SCALAR      0x008  /* scalar: ndim = 0 */
#define _Py_MEMORYVIEW_PIL         0x010  /* PIL-style layout */

typedef struct {
    PyObject_VAR_HEAD
    _PyManagedBufferObject *mbuf; /* managed buffer */
    Py_hash_t hash;               /* hash value for read-only views */
    int flags;                    /* state flags */
    Py_ssize_t exports;           /* number of buffer re-exports */
    Py_buffer view;               /* private copy of the exporter's view */
    PyObject *weakreflist;
    Py_ssize_t ob_array[1];       /* shape, strides, suboffsets */
} PyMemoryViewObject;
---

----------

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

From report at bugs.python.org  Fri Sep  7 11:10:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:10:10 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333010.52.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

sqlite3.dump._iterdump() access to the "sqlite_master" table.... Hum, I don't think that Python chose the name of this table. This issue should be addressed in SQLite, not in Python.

----------

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

From report at bugs.python.org  Fri Sep  7 11:11:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:11:33 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333093.61.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

nis module contains the error message: NisError("No NIS master found for any map"), but libnis has a yp_master() function, it's no like Python picked this name. I suggest to keep "master" here to keep Python consistent with libnis. And "NIP master" gives the context of the "master" term.

----------

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

From report at bugs.python.org  Fri Sep  7 11:13:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Sep 2018 15:13:51 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333231.5.0.56676864532.issue34605@psf.upfronthosting.co.za>


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


----------
components:  -asyncio
nosy:  -yselivanov

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

From report at bugs.python.org  Fri Sep  7 11:16:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:16:18 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333378.05.0.56676864532.issue34605@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8555

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

From report at bugs.python.org  Fri Sep  7 11:16:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:16:38 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333398.19.0.56676864532.issue34605@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, ctypes, email, macOS

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

From report at bugs.python.org  Fri Sep  7 11:17:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:17:17 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333437.33.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

(Oops, I didn't want to put so many people in the nosy list, sorry about the spam.)

----------
nosy:  -Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, zach.ware

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

From report at bugs.python.org  Fri Sep  7 11:17:59 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:17:59 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333479.41.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, with these 3 PRs, I should have replaced most usages of master and slave terms.

----------

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

From report at bugs.python.org  Fri Sep  7 11:20:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:20:45 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333645.31.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 012f5b968a738b15ae9b40c499a1c0778b0615a9 by Victor Stinner in branch 'master':
bpo-34605, libregrtest: Rename --slaveargs to --worker-args (GH-9099)
https://github.com/python/cpython/commit/012f5b968a738b15ae9b40c499a1c0778b0615a9


----------

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

From report at bugs.python.org  Fri Sep  7 11:21:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:21:25 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333685.27.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> bpo-34605, libregrtest: Rename --slaveargs to --worker-args (GH-9099)

I don't think that this change should be backported to 3.7 and older, since it *might* break the backward compatibility.

----------

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

From report at bugs.python.org  Fri Sep  7 11:23:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 07 Sep 2018 15:23:07 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333787.11.0.56676864532.issue34605@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Just want to add that it's a constant source of problem with respect to Redis and antirez wrote a detailed blog post about it yesterday : http://antirez.com/news/122 . It causes a lot of energy and emotional drain when issues like this get to twitter and top pages of HN : https://twitter.com/antirez/status/1037809132303208455

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Sep  7 11:30:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:30:36 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536334236.94.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5e922658fb55734bf8b4c6246033ea93af172ff7 by Victor Stinner in branch 'master':
bpo-34605: Avoid master/slave terms (GH-9101)
https://github.com/python/cpython/commit/5e922658fb55734bf8b4c6246033ea93af172ff7


----------

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

From report at bugs.python.org  Fri Sep  7 11:33:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 07 Sep 2018 15:33:06 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536334386.51.0.56676864532.issue34606@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Sep  7 11:37:51 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Fri, 07 Sep 2018 15:37:51 +0000
Subject: [issue34563] invalid assert on big output of multiprocessing.Process
In-Reply-To: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>
Message-ID: <1536334671.84.0.56676864532.issue34563@psf.upfronthosting.co.za>


Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com> added the comment:

thank you for all the help in merging this fix!

----------

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

From report at bugs.python.org  Fri Sep  7 11:38:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:38:35 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536334715.37.0.56676864532.issue34605@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8556

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

From report at bugs.python.org  Fri Sep  7 11:44:27 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 15:44:27 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1536335067.7.0.56676864532.issue20104@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 254a4663d8c5970ae2928185c50ebaa6c7e62c80 by Pablo Galindo in branch 'master':
bpo-20104: Add flag capabilities to posix_spawn (GH-6693)
https://github.com/python/cpython/commit/254a4663d8c5970ae2928185c50ebaa6c7e62c80


----------

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

From report at bugs.python.org  Fri Sep  7 11:47:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 07 Sep 2018 15:47:56 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536335276.93.0.56676864532.issue34606@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It's also reproducible on master. git blame tells me this is introduced with feccdb2a249a71be330765be77dee57121866779 (https://bugs.python.org/issue29774)

?  cpython git:(master)
commit feccdb2a249a71be330765be77dee57121866779
Author: Serhiy Storchaka <storchaka at gmail.com>
Date:   Thu Mar 9 18:34:03 2017 +0200

    bpo-29774: Improve error reporting for corrupted extra field in ZIP file. (#583)

diff --git a/Lib/zipfile.py b/Lib/zipfile.py
index b5c16dbc12..8a19ca246b 100644
--- a/Lib/zipfile.py
+++ b/Lib/zipfile.py
@@ -438,7 +438,9 @@ class ZipInfo (object):
         unpack = struct.unpack
         while len(extra) >= 4:
             tp, ln = unpack('<HH', extra[:4])
-            if tp == 1:
+            if ln+4 > len(extra):
+                raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
+            if tp == 0x0001:
                 if ln >= 24:
                     counts = unpack('<QQQ', extra[4:28])
                 elif ln == 16:

# Master branch

?  cpython git:(master) ./python.exe
Python 3.8.0a0 (heads/master:874809ea38, Sep  7 2018, 21:03:18)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
?  cpython git:(master) ./python.exe ../backups/bpo34606.py 36.zip
3.8.0a0 (heads/master:874809ea38, Sep  7 2018, 21:03:18)
[Clang 7.0.2 (clang-700.1.81)]
36.zip
Traceback (most recent call last):
  File "../backups/bpo34606.py", line 14, in <module>
    zipfile.ZipFile(fn)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/zipfile.py", line 1204, in __init__
    self._RealGetContents()
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/zipfile.py", line 1327, in _RealGetContents
    x._decodeExtra()
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/zipfile.py", line 440, in _decodeExtra
    raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)
?  cpython git:(master) ? rm 36.zip

# checkout feccdb2a249a71be330765be77dee57121866779

?  cpython git:(master) git checkout feccdb2a249a71be330765be77dee57121866779 Lib/zipfile.py
?  cpython git:(master) ? ./python.exe ../backups/bpo34606.py 36.zip
3.8.0a0 (heads/master:874809ea38, Sep  7 2018, 21:03:18)
[Clang 7.0.2 (clang-700.1.81)]
36.zip
Traceback (most recent call last):
  File "../backups/bpo34606.py", line 14, in <module>
    zipfile.ZipFile(fn)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/zipfile.py", line 1105, in __init__
    self._RealGetContents()
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/zipfile.py", line 1230, in _RealGetContents
    x._decodeExtra()
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/zipfile.py", line 442, in _decodeExtra
    raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)
?  cpython git:(master) ? rm 36.zip

# checkout feccdb2a249a71be330765be77dee57121866779~1

?  cpython git:(master) ? git checkout feccdb2a249a71be330765be77dee57121866779~1 Lib/zipfile.py
?  cpython git:(master) ? ./python.exe ../backups/bpo34606.py 36.zip
3.8.0a0 (heads/master:874809ea38, Sep  7 2018, 21:03:18)
[Clang 7.0.2 (clang-700.1.81)]
36.zip
?  cpython git:(master) ? gsha256sum 36.zip
0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6  36.zip


Hope this helps. 

I am adding Serhiy who might have a better explanation. @Serhiy Feel free to unassign yourself if this is irrelevant.

Thanks

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

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

From report at bugs.python.org  Fri Sep  7 12:01:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 16:01:04 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536336064.34.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 886483e2b9bbabf60ab769683269b873381dd5ee by Victor Stinner in branch 'master':
bpo-34595: Add %T format to PyUnicode_FromFormatV() (GH-9080)
https://github.com/python/cpython/commit/886483e2b9bbabf60ab769683269b873381dd5ee


----------

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

From report at bugs.python.org  Fri Sep  7 12:12:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 16:12:12 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536336732.1.0.56676864532.issue34595@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8557

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

From report at bugs.python.org  Fri Sep  7 12:13:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 16:13:14 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536336794.49.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7e610bcdf128f61b925654e4fa80fbac83537d0e by Victor Stinner in branch 'master':
bpo-34605: childs => children (GH-9102)
https://github.com/python/cpython/commit/7e610bcdf128f61b925654e4fa80fbac83537d0e


----------

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

From report at bugs.python.org  Fri Sep  7 12:17:13 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Sep 2018 16:17:13 +0000
Subject: [issue34594] Some tests use hardcoded errno values
In-Reply-To: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>
Message-ID: <1536337033.08.0.56676864532.issue34594@psf.upfronthosting.co.za>


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


New changeset 9eeecfd5d03cfd6d5cef71de31eed7f65f0e658b by Benjamin Peterson (Zackery Spytz) in branch '3.6':
[3.6] bpo-34594: Don't hardcode errno values in the tests. (GH-9096)
https://github.com/python/cpython/commit/9eeecfd5d03cfd6d5cef71de31eed7f65f0e658b


----------

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

From report at bugs.python.org  Fri Sep  7 12:17:36 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Sep 2018 16:17:36 +0000
Subject: [issue34594] Some tests use hardcoded errno values
In-Reply-To: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>
Message-ID: <1536337056.32.0.56676864532.issue34594@psf.upfronthosting.co.za>


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


New changeset 18d7dff1bb6f5ca7060b0b2e2a2e74493619178f by Benjamin Peterson (Zackery Spytz) in branch '3.7':
[3.7] bpo-34594: Don't hardcode errno values in the tests. (GH-9094)
https://github.com/python/cpython/commit/18d7dff1bb6f5ca7060b0b2e2a2e74493619178f


----------

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

From report at bugs.python.org  Fri Sep  7 12:30:04 2018
From: report at bugs.python.org (Bryan)
Date: Fri, 07 Sep 2018 16:30:04 +0000
Subject: [issue34608] gc.get_referrers behavior change 3.6 to 3.7
Message-ID: <1536337804.03.0.56676864532.issue34608@psf.upfronthosting.co.za>


New submission from Bryan <bryanv at ftml.net>:

When called on a local object inside a function, gc.get_referrers no longer returns a Frame as one of the references. I could not find anything in the release notes or changeling that indicated that this is an intentional change. 

The following script generates different output when run on Python 3.6 vs Python 3.7 (on linux, OSX, or Windows):

```
# referrers.py
import gc, sys

class FakeMod(object): pass

extra = []

def test():
    mod = FakeMod()
    extra.append(mod)
    referrers = gc.get_referrers(mod)
    print(".".join(str(x) for x in sys.version_info[:3]), ":", len(referrers), referrers)

test()
```

Output:

~ master*
(py37) ? python test.py
3.7.0 : 1 [[<__main__.FakeMod object at 0x10b65e320>]]

~ master*
(base) ? python test.py
3.6.6 : 2 [[<__main__.FakeMod object at 0x106f3ea90>], <frame object at 0x10684b648>]

----------
components: Library (Lib)
messages: 324771
nosy: bryevdv
priority: normal
severity: normal
status: open
title: gc.get_referrers behavior change 3.6 to 3.7
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 13:10:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 17:10:43 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536340243.89.0.56676864532.issue34604@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 28658485a54ad5f9df52ecc12d9046269f1654ec by Victor Stinner (William Grzybowski) in branch 'master':
bpo-34604: Fix possible mojibake in pwd.getpwnam() and grp.getgrnam() (GH-9098)
https://github.com/python/cpython/commit/28658485a54ad5f9df52ecc12d9046269f1654ec


----------

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

From report at bugs.python.org  Fri Sep  7 13:18:01 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 07 Sep 2018 17:18:01 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536340681.95.0.56676864532.issue34605@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I'm a little surprised by this.  It's not like slavery was acceptable when these computer science terms were coined and it's only comparatively recently that they've gone out of fashion.  On the other hand, there are some areas in computer software where "master" and "slave" are the exact technical terms (e.g. IDE), and avoiding them would lead to confusion.

Of the four citations you reference, one of them is a PR for Django, and three of them say "see the Django PR".  The Django PR is an unreadable infinitely-long page of miserable arguing.  So the context doesn't help much.

Have there been any actual complaints?  Or is this an attempt to solve a problem that doesn't really exist?

----------
nosy: +larry

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

From report at bugs.python.org  Fri Sep  7 13:20:49 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 07 Sep 2018 17:20:49 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536340849.23.0.56676864532.issue34605@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

As a counter-example: A quick grep finds 555 occurrences of the word "kill" in CPython master.  Everybody knows killing is bad and using the term might upset certain people.  Yet I would not support expunging the word "kill" from Python.

----------

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

From report at bugs.python.org  Fri Sep  7 13:22:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 17:22:31 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536340951.32.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Have there been any actual complaints?

Yes, but sadly they are private.

----------

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

From report at bugs.python.org  Fri Sep  7 13:25:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 17:25:06 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536341106.63.0.56676864532.issue34605@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> The Django PR is an unreadable infinitely-long page of miserable arguing.  So the context doesn't help much.

In short, some people associate the words "master" and "slave" to slavery. To enhance the diversity in the Python community, I suggest to try to avoid these terms whenever possible. As I wrote in previous comments, it seems like we have to keep them in a few places.

----------

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

From report at bugs.python.org  Fri Sep  7 13:45:26 2018
From: report at bugs.python.org (William Grzybowski)
Date: Fri, 07 Sep 2018 17:45:26 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536342326.77.0.56676864532.issue34604@psf.upfronthosting.co.za>


Change by William Grzybowski <william88 at gmail.com>:


----------
pull_requests: +8558

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

From report at bugs.python.org  Fri Sep  7 13:46:08 2018
From: report at bugs.python.org (William Grzybowski)
Date: Fri, 07 Sep 2018 17:46:08 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536342368.08.0.56676864532.issue34604@psf.upfronthosting.co.za>


Change by William Grzybowski <william88 at gmail.com>:


----------
pull_requests: +8559

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

From report at bugs.python.org  Fri Sep  7 13:50:43 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 07 Sep 2018 17:50:43 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536342643.53.0.56676864532.issue34605@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

> > Have there been any actual complaints?
> Yes, but sadly they are private.

I'm not super-excited by the idea that Python has to change its behavior based on secret comments.  Python has traditionally had a very open governance model where all discussions happen in public.

While I understand the need to preserve the privacy of victims, is there some way we can bring the decision-making process out into the open?  As far as I can tell, the entire process so far has been "Victor concludes that these terms are bad, and creates and merges several PRs an hour or two later with zero discussion".

Perhaps the complaints could be edited to anonymize them, and then we could see them?  Or must Python change its governance model because of diversity concerns?

----------

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

From report at bugs.python.org  Fri Sep  7 14:19:50 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 07 Sep 2018 18:19:50 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536344390.16.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

Not all uses of the word "master" are associated with slavery, e.g. "master craftsman", "master copy", "master file table".

I think it's best to avoid use of master/slave where practicable, but other uses of "master" are not necessarily a problem.

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

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

From report at bugs.python.org  Fri Sep  7 14:30:27 2018
From: report at bugs.python.org (piscvau@yahoo.fr)
Date: Fri, 07 Sep 2018 18:30:27 +0000
Subject: [issue34609] Idle Unitest
Message-ID: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>


New submission from piscvau at yahoo.fr <piscvau at yahoo.fr>:

Idle is unable to import unittest. and raises an attributeError.
Output of the Python shell Idle is included in the file bug idle.

several files raise this exception
on of them is included in this report
the Trace for Idle is as follows :
Python 3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0] on linux
Type "copyright", "credits" or "license()" for more information.
>>> 
[DEBUG ON]
>>> 
 RESTART: /home/odile/Documents/dev_logiciels/pyhton/openclassrooms/labyrinthe/roboc2/test/test_carte.py 
Traceback (most recent call last):
  File "/home/odile/Documents/dev_logiciels/pyhton/openclassrooms/labyrinthe/roboc2/test/test_carte.py", line 5, in <module>
    import unittest
  File "<frozen importlib._bootstrap>", line 968, in _find_and_load
  File "<frozen importlib._bootstrap>", line 148, in __enter__
  File "<frozen importlib._bootstrap>", line 174, in _get_module_lock
  File "<frozen importlib._bootstrap>", line 59, in __init__
  File "<frozen importlib._bootstrap>", line 59, in __init__
  File "/usr/lib/python3.6/bdb.py", line 51, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/lib/python3.6/bdb.py", line 69, in dispatch_line
    self.user_line(frame)
  File "/usr/lib/python3.6/idlelib/debugger.py", line 24, in user_line
    self.gui.interaction(message, frame)
AttributeError: '_ModuleLock' object has no attribute 'name'
[DEBUG ON]

Idle version is 3.6.5

----------
assignee: terry.reedy
components: IDLE
files: test_main.py
messages: 324779
nosy: piscvau at yahoo.fr, terry.reedy
priority: normal
severity: normal
status: open
title: Idle Unitest
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47790/test_main.py

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

From report at bugs.python.org  Fri Sep  7 14:32:13 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 18:32:13 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536345133.19.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

To me, there is nothing wrong with the word 'master', as such.  I mastered Python to become a master of Python.  Purging Python of 'master' seems ill-conceived.  The word 'slave' is different matter to me.

In tk and tkinter, the 'parent' and 'master' of a widget may be different widgets, but I cannot remember the functional difference, nor whether the terms are used consistently.

Like Larry, I object to action based on hidden evidence.

----------
nosy: +terry.reedy -mrabarnett

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

From report at bugs.python.org  Fri Sep  7 14:33:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 18:33:02 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1536345182.63.0.56676864532.issue34546@psf.upfronthosting.co.za>


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

What is the reason of using such weak encryption? It looks to me that creating a non-encrypted ZIP file and encrypting it with third-party tools is the right way if you need an encryption.

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

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

From report at bugs.python.org  Fri Sep  7 14:36:55 2018
From: report at bugs.python.org (Chris Warrick)
Date: Fri, 07 Sep 2018 18:36:55 +0000
Subject: [issue23057] [Windows] asyncio: support signal handlers on Windows
 (feature request)
In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za>
Message-ID: <1536345415.24.0.56676864532.issue23057@psf.upfronthosting.co.za>


Change by Chris Warrick <kwpolska at gmail.com>:


----------
nosy: +Kwpolska

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

From report at bugs.python.org  Fri Sep  7 14:38:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 18:38:08 +0000
Subject: [issue34573] Simplify __reduce__() of set and dict iterators.
In-Reply-To: <1536034432.71.0.56676864532.issue34573@psf.upfronthosting.co.za>
Message-ID: <1536345488.64.0.56676864532.issue34573@psf.upfronthosting.co.za>


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

Perhaps the bug was specific to OrderedDict itrerators. I'll try to write additional tests, and after that I'll merge PR 9050.

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

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

From report at bugs.python.org  Fri Sep  7 14:44:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 18:44:08 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536345848.07.0.56676864532.issue33083@psf.upfronthosting.co.za>


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

Since this is potentially breaking change, please add a What's New entry for it.

----------

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

From report at bugs.python.org  Fri Sep  7 14:46:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 18:46:44 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536346004.2.0.56676864532.issue26544@psf.upfronthosting.co.za>


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

Thank you for merging PRs Victor, but seems you have merged wrong PR for 2.7.

----------

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

From report at bugs.python.org  Fri Sep  7 15:02:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 19:02:32 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1536346952.85.0.56676864532.issue34486@psf.upfronthosting.co.za>


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

This looks similar to to problems with the "with" statement: see issue29988 and issue34067. Except that there is no a "with" statement, and resolving that issues will not solve this issue.

----------

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

From report at bugs.python.org  Fri Sep  7 15:07:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 19:07:18 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536347238.95.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

Having said that, there are situations where words are used confusingly or inappropriately, and better choices are available.  (I am sometimes confused, for instance, by the use of 'client' and 'server'.)  In such situations, change can be justified without reference to private complaints.

----------

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

From report at bugs.python.org  Fri Sep  7 15:14:37 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Sep 2018 19:14:37 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1536347677.34.0.56676864532.issue34546@psf.upfronthosting.co.za>


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

-1 from me, too.

Serhiy already made a valid point and suggested a better alternative.

----------

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

From report at bugs.python.org  Fri Sep  7 15:41:50 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 19:41:50 +0000
Subject: [issue34609] Idle Unitest
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1536349310.94.0.56676864532.issue34609@psf.upfronthosting.co.za>


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

I cannot confirm this.  I tested 3.6.6 on Windows 10 with tem3.py containing

import unittest
print unittest

I ran this twice, without and with debug on.  The output:

======================== RESTART: F:\Python\a\tem3.py ========================
<module 'unittest' from 'C:\\Programs\\Python36\\lib\\unittest\\__init__.py'>
>>> 
[DEBUG ON]
>>> 
======================== RESTART: F:\Python\a\tem3.py ========================
<module 'unittest' from 'C:\\Programs\\Python36\\lib\\unittest\\__init__.py'>
[DEBUG ON]
>>>

On the second run, I hit the [Go] button on Debug Control.  The minimal program above needs to be tested with 3.6.6 or 3.7.0 on Linux.

----------
nosy: +cheryl.sabella, taleinat

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

From report at bugs.python.org  Fri Sep  7 16:02:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 20:02:24 +0000
Subject: [issue32055] Reconsider comparison chaining for containment tests
In-Reply-To: <1510904597.47.0.213398074469.issue32055@psf.upfronthosting.co.za>
Message-ID: <1536350544.86.0.56676864532.issue32055@psf.upfronthosting.co.za>


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

This had not been discussed.

----------

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

From report at bugs.python.org  Fri Sep  7 16:18:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 20:18:16 +0000
Subject: [issue33625] Release GIL for grp.getgr{nam, gid} and pwd.getpw{nam,
 uid}
In-Reply-To: <1527105781.7.0.682650639539.issue33625@psf.upfronthosting.co.za>
Message-ID: <1536351496.22.0.56676864532.issue33625@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.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/issue33625>
_______________________________________

From report at bugs.python.org  Fri Sep  7 16:33:34 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 20:33:34 +0000
Subject: [issue34564] Tutorial Section 2.1 Windows Installation Path Correction
In-Reply-To: <1535912620.22.0.56676864532.issue34564@psf.upfronthosting.co.za>
Message-ID: <1536352414.1.0.56676864532.issue34564@psf.upfronthosting.co.za>


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


----------
components: +Installation, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Fri Sep  7 16:40:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 20:40:31 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536352831.66.0.56676864532.issue34606@psf.upfronthosting.co.za>


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

The value of the extra attribute is not an arbitrary bytes object. It is a sequence of blocks in the following format: 16-bit identifier followed by 16-bit size of the block followed by the specified amount of bytes. Your example creates invalid ZIP file.

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

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

From report at bugs.python.org  Fri Sep  7 16:57:12 2018
From: report at bugs.python.org (Kyle Altendorf)
Date: Fri, 07 Sep 2018 20:57:12 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536353832.85.0.56676864532.issue34606@psf.upfronthosting.co.za>


Kyle Altendorf <sda at fstab.net> added the comment:

Turns out the docs do document this.  My apologies.

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

   4.3.11  Archive extra data record: 

        archive extra data signature    4 bytes  (0x08064b50)
        extra field length              4 bytes
        extra field data                (variable size)

Aside from the discrepancy between 16-bits and 4 bytes, it seems like something should happen, even if it's something other than 'fixing' the code to handle the malformed data.  Isn't it a bug for zipfile to create a non-compliant file?  Shouldn't it either check or provide an interface by which a compliant file could sensibly be created?  It doesn't seem great to just expect users to rewrite this each time they call.

(42).to_bytes(4, 'little') + len(data).to_bytes(4, 'little') + data

or, should it be 'big'?  and would it be (len(data) + 4 + 4)?

----------

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

From report at bugs.python.org  Fri Sep  7 17:03:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 21:03:50 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536354230.78.0.56676864532.issue34595@psf.upfronthosting.co.za>


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

IIRC there is similar issue or a discussion on one of mailing lists. But the idea about adding this feature on Python side too was considered. It would be better to find this discussion before pushing this change.

In some cases we have the type itself, not an instance. So it makes sense to make %T an equivalent of arg->tp_name instead of Py_TYPE(arg)->tp_name.

On Python side, you need to output either short name obj.__class__.__name__ or full qualified name obj.__class__.__module__ + '.' + obj.__class__.__qualname__ with exception that the module name should be omitted if it is 'builtins'.

    obj.__class__.__qualname__ if obj.__class__.__module__ == 'builtins' else f'{obj.__class__.__module__}.{obj.__class__.__qualname__}'

The case of the module name '__main__' can be handled specially too.
Obviously it is desirable to have a more handy way of writing such expression.

On C side, the problem is that tp_name means different, depending of the kind of the type. In some cases it is a short name, in other cases it is a full qualified name. It is not easy to write a code that produces the same output in Python and C. I have added a helper _PyType_Name() that helps to solve a part of these issues. If you want to output a short name (just cls.__name__ in Python), use _PyType_Name(cls) instead of cls->tp_name. But this doesn't help for the case when you need to output a full qualified name.

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

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

From report at bugs.python.org  Fri Sep  7 17:09:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 21:09:50 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536354590.23.0.56676864532.issue33083@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I reopen the issue since Serhiy requested a NEWS entry.

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

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

From report at bugs.python.org  Fri Sep  7 17:11:41 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 07 Sep 2018 21:11:41 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536354701.7.0.56676864532.issue30977@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8560

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

From report at bugs.python.org  Fri Sep  7 17:12:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 21:12:48 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536354768.9.0.56676864532.issue26544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Thank you for merging PRs Victor, but seems you have merged wrong PR for 2.7.

Oh. I didn't notice that there were two PRs for 2.7. Do you want to rebase your PR 9062 on 2.7, or revert the commit that I merged? It's up to you ;-)

I reopen the issue.

It seems like PR 8971 is also open.

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

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

From report at bugs.python.org  Fri Sep  7 17:15:06 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 07 Sep 2018 21:15:06 +0000
Subject: [issue28307] Accelerate 'string' % (value,
 ...) by using formatted string literals
In-Reply-To: <1475138996.48.0.897803092987.issue28307@psf.upfronthosting.co.za>
Message-ID: <1536354906.31.0.56676864532.issue28307@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I'm +1 on this optimization.

----------
nosy: +taleinat

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

From report at bugs.python.org  Fri Sep  7 17:18:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 21:18:32 +0000
Subject: [issue33625] Release GIL for grp.getgr{nam, gid} and pwd.getpw{nam,
 uid}
In-Reply-To: <1527105781.7.0.682650639539.issue33625@psf.upfronthosting.co.za>
Message-ID: <1536355112.5.0.56676864532.issue33625@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I was waiting for the encoding fix to close this issue, but bpo-34604 has been created.

----------

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

From report at bugs.python.org  Fri Sep  7 17:21:22 2018
From: report at bugs.python.org (Kyle Altendorf)
Date: Fri, 07 Sep 2018 21:21:22 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536355282.93.0.56676864532.issue34606@psf.upfronthosting.co.za>


Kyle Altendorf <sda at fstab.net> added the comment:

Python 3.7 works with 2-byte elements, I managed to find the wrong section in the doc-linked docs.

4.5 Extensible data fields
    --------------------------
    
       4.5.1 In order to allow different programs and different types
       of information to be stored in the 'extra' field in .ZIP
       files, the following structure MUST be used for all
       programs storing data in this field:
    
           header1+data1 + header2+data2 . . .
    
       Each header should consist of:
    
           Header ID - 2 bytes
           Data Size - 2 bytes
    
       Note: all fields stored in Intel low-byte/high-byte order.


And the test showing it working.

----
    import sys
    import zipfile
    
    print(sys.version)
    
    fn = sys.argv[1]
    print(fn)
    
    options = {
        'endianness': ('little', 'big'),
        'header_element_bytes': (2, 4),
        'additional_size': (0, 4, 4 + 4),
    }
    
    for endianness in options['endianness']:
        for additional_size in options['additional_size']:
            for header_element_bytes in options['header_element_bytes']:
                print('\n\n --- trying endianness: {}, additional_size: {}, header_element_bytes: {}'.format(endianness, additional_size, header_element_bytes))
                with zipfile.ZipFile(fn, 'w') as zf:
                    zi = zipfile.ZipInfo("0")
                    extra_data = b"hello, extra, and some more just to make it longer and such so yeah"
                    zi.extra = (
                        (42).to_bytes(header_element_bytes, endianness)
                        + (len(extra_data) + additional_size).to_bytes(header_element_bytes, endianness)
                        + extra_data
                    )
                    zf.writestr(zi, b"the real data")
    
                try:
                    zipfile.ZipFile(fn)
                except Exception as e:
                    print(e)
                else:
                    print('success')

----
    altendky at lt:~/twisted$ python3.7 ../z.py 37.py
    3.7.0 (default, Jul  7 2018, 15:49:24)
    [GCC 6.3.0 20170516]
    37.py
    
    
     --- trying endianness: little, additional_size: 0, header_element_bytes: 2
    success
    
    
     --- trying endianness: little, additional_size: 0, header_element_bytes: 4
    Corrupt extra field 6568 (size=27756)
    
    
     --- trying endianness: little, additional_size: 4, header_element_bytes: 2
    Corrupt extra field 002a (size=71)
    
    
     --- trying endianness: little, additional_size: 4, header_element_bytes: 4
    Corrupt extra field 6568 (size=27756)
    
    
     --- trying endianness: little, additional_size: 8, header_element_bytes: 2
    Corrupt extra field 002a (size=75)
    
    
     --- trying endianness: little, additional_size: 8, header_element_bytes: 4
    Corrupt extra field 6568 (size=27756)
    
    
     --- trying endianness: big, additional_size: 0, header_element_bytes: 2
    Corrupt extra field 2a00 (size=17152)
    
    
     --- trying endianness: big, additional_size: 0, header_element_bytes: 4
    Corrupt extra field 0000 (size=10752)
    
    
     --- trying endianness: big, additional_size: 4, header_element_bytes: 2
    Corrupt extra field 2a00 (size=18176)
    
    
     --- trying endianness: big, additional_size: 4, header_element_bytes: 4
    Corrupt extra field 0000 (size=10752)
    
    
     --- trying endianness: big, additional_size: 8, header_element_bytes: 2
    Corrupt extra field 2a00 (size=19200)
    
    
     --- trying endianness: big, additional_size: 8, header_element_bytes: 4
    Corrupt extra field 0000 (size=10752)

----------

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

From report at bugs.python.org  Fri Sep  7 17:34:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 21:34:17 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1536356057.27.0.56676864532.issue34546@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep  7 17:38:02 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 07 Sep 2018 21:38:02 +0000
Subject: [issue34609] Idle Unitest
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1536356282.98.0.56676864532.issue34609@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Testing similarly to Terry, this doesn't reproduce with a recent build of master branch (3.8) on Ubuntu 16.04.

I'll be able to try a build of older versions with IDLE only in a few days.

----------

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

From report at bugs.python.org  Fri Sep  7 17:39:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 21:39:40 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536356380.56.0.56676864532.issue34606@psf.upfronthosting.co.za>


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

Right, the correct section is 4.5. All integers in ZIP files are unsigned and in the little endian format.

----------

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

From report at bugs.python.org  Fri Sep  7 17:42:31 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Fri, 07 Sep 2018 21:42:31 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536356551.04.0.56676864532.issue34606@psf.upfronthosting.co.za>


Change by Vladimir Matveev <desco.by at gmail.com>:


----------
pull_requests: +8561

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

From report at bugs.python.org  Fri Sep  7 17:42:46 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 21:42:46 +0000
Subject: [issue25514] Improve IDLE's "subprocess didn't make connection"
 message
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1536356566.77.0.56676864532.issue25514@psf.upfronthosting.co.za>


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

Module shadowing can affect either the gui process or the run process.  #34584 was the latter: debug_obj imports rpc imports socket imports selectors imports math, which was shadowed.

Pyshell starts run.  If run starts OK but cannot connect to pyshell, it displays a 'subprocess cannot connect' message, which now refers to the new doc section, and exits.  If pyshell does does get a connection, it currently displays

    "Subprocess Startup Error",
    "IDLE's subprocess didn't make connection.  Either IDLE can't "
    "start a subprocess or personal firewall software is blocking "
    "the connection.",

This also needs revision, with a reference to the doc section.  And add 'math.py' to shadowed modules.

----------

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

From report at bugs.python.org  Fri Sep  7 17:45:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 21:45:00 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536356700.38.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> In some cases we have the type itself, not an instance. So it makes sense to make %T an equivalent of arg->tp_name instead of Py_TYPE(arg)->tp_name.

"arg->tp_name" is rare in the code base, whereas "Py_TYPE(arg)->tp_name" is a very common pattern.

I'm not sure that a formatter is needed for "arg->tp_name", you can already use "%s" with "arg->tp_name", no?

My intent was to make the C code less verbose, respect the PEP 399, but also indirectly avoid the implicit borrowed reference of Py_TYPE() :-)
https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references


> On Python side, you need to output either short name obj.__class__.__name__ or full qualified name obj.__class__.__module__ + '.' + obj.__class__.__qualname__ with exception that the module name should be omitted if it is 'builtins'.

Sometimes, the qualified name would be more appropriate, but it's sometimes tricky to decide if the short name, qualified name or fully qualified name is the "right" name... So I chose to restrict this issue to the most common case, Py_TYPE(arg)->tp_name :-)

Ah, and changing strings is a risk of breaking the backward compatibility. For example, cause issue with pickle. So it should be discussed on a case by case basis.

Moreover, if you want to change a string, the Python code should be updated as well. I suggest to open a new issue to discuss that.

Don't get me wrong, I'm interested to do these changes, but it's a wider project :-)


> obj.__class__.__qualname__ if obj.__class__.__module__ == 'builtins' else f'{obj.__class__.__module__}.{obj.__class__.__qualname__}'
>
> The case of the module name '__main__' can be handled specially too.
> Obviously it is desirable to have a more handy way of writing such expression.

To be honest, I also considered to proposed a second formatter to do something like that :-) But as you explained, I'm not sure which name is the good name: qualified or fully qualified (with module name)?

First of all, would it help to have a *function* to get these names? Maybe we could first use such functions before discussing adding a new formatter in PyUnicode_FromFormat()?

----------

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

From report at bugs.python.org  Fri Sep  7 17:49:34 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 21:49:34 +0000
Subject: [issue34584] IDLE 3.7.0 on Mac cannot open subprocess
In-Reply-To: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>
Message-ID: <1536356974.92.0.56676864532.issue34584@psf.upfronthosting.co.za>


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

idlelib/run.py imports math through about 3 intermediaries.  Hence it failed, and pyshell displayed the message in the .png.  Both modules can raise failure messages.  In #25514, the run.py message was revised to point to a new section of the doc: "Startup failure".  The second paragraph is

"A common cause of failure is a user-written file with the same name as a standard library module, such as random.py and tkinter.py. When such a file is located in the same directory as a file that is about to be run, IDLE cannot import the stdlib file.  The current fix is to rename the user file."

This is what Joseph should have seen.  I added a note to the issue to also fix the pyshell message to point to this section.

A better but harder fix would be to temporarily remove the user directory from sys.path so that user files cannot stop run's startup.

----------
nosy: +terry.reedy
status: pending -> open
title: subprocess -> IDLE 3.7.0 on Mac cannot open subprocess

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

From report at bugs.python.org  Fri Sep  7 17:50:36 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 21:50:36 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536357036.1.0.56676864532.issue34246@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8562

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

From report at bugs.python.org  Fri Sep  7 17:53:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 21:53:18 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536357198.39.0.56676864532.issue34597@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/issue34597>
_______________________________________

From report at bugs.python.org  Fri Sep  7 18:01:02 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 22:01:02 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536357662.16.0.56676864532.issue33083@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8563
stage: resolved -> patch review

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

From report at bugs.python.org  Fri Sep  7 18:01:02 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 22:01:02 +0000
Subject: [issue34584] IDLE 3.7.0 on Mac cannot open subprocess
In-Reply-To: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>
Message-ID: <1536357662.75.0.56676864532.issue34584@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep  7 18:02:59 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 07 Sep 2018 22:02:59 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536357779.2.0.56676864532.issue23855@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 4e519377b1b84c9414a360961276993d24198825 by Berker Peksag (Zackery Spytz) in branch 'master':
bpo-23855: Add missing NULL checks for malloc() in _msi.c (GH-9038)
https://github.com/python/cpython/commit/4e519377b1b84c9414a360961276993d24198825


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

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

From report at bugs.python.org  Fri Sep  7 18:03:10 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 22:03:10 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536357790.58.0.56676864532.issue23855@psf.upfronthosting.co.za>


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


----------
pull_requests: +8564

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

From report at bugs.python.org  Fri Sep  7 18:04:51 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 22:04:51 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536357891.68.0.56676864532.issue34246@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset d5fbe9b1a3d65ceeb9159c5ba999ee966a945f76 by Pablo Galindo (Pablo Aguiar) in branch 'master':
bpo-34246: Use no mutable default args in smtplib (GH-8554)
https://github.com/python/cpython/commit/d5fbe9b1a3d65ceeb9159c5ba999ee966a945f76


----------

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

From report at bugs.python.org  Fri Sep  7 18:04:58 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 22:04:58 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536357898.75.0.56676864532.issue34246@psf.upfronthosting.co.za>


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


----------
pull_requests: +8565

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

From report at bugs.python.org  Fri Sep  7 18:07:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Sep 2018 22:07:18 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536358038.64.0.56676864532.issue34604@psf.upfronthosting.co.za>


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

Wouldn't be better to use %R? The name can contain invisible characters or trailing whitespaces, in which case the traceback can look confusing. Since names are likely created with PyUnicode_DecodeFSDefault(), they can contain undecodable bytes represented as surrogates U+D8XX if the current filesystem encoding doesn't match the filesystem encoding used for creating entries.

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

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

From report at bugs.python.org  Fri Sep  7 18:09:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 22:09:08 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536358148.4.0.56676864532.issue34604@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

%R sounds like a good idea, but I suggest to only use %R in the master branch.

----------

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

From report at bugs.python.org  Fri Sep  7 18:10:31 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 22:10:31 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1536358231.84.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 963bcc8b71e4ab8c9ee9a91ed1300b6e39219821 by Pablo Galindo in branch '3.6':
[3.6] bpo-34007: Skip traceback tests if the Program Counter is not available. (GH-9022)
https://github.com/python/cpython/commit/963bcc8b71e4ab8c9ee9a91ed1300b6e39219821


----------

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

From report at bugs.python.org  Fri Sep  7 18:15:33 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 22:15:33 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536358533.18.0.56676864532.issue23855@psf.upfronthosting.co.za>


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


New changeset 73994077250bd70385cb8e7a92f24874129369d1 by Miss Islington (bot) in branch '3.7':
bpo-23855: Add missing NULL checks for malloc() in _msi.c (GH-9038)
https://github.com/python/cpython/commit/73994077250bd70385cb8e7a92f24874129369d1


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

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

From report at bugs.python.org  Fri Sep  7 18:29:32 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 07 Sep 2018 22:29:32 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536359372.4.0.56676864532.issue34246@psf.upfronthosting.co.za>


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


New changeset 9835696ec4c57a9a30f1c11cfb4c5d3e121bf97c by Miss Islington (bot) in branch '3.7':
bpo-34246: Use no mutable default args in smtplib (GH-8554)
https://github.com/python/cpython/commit/9835696ec4c57a9a30f1c11cfb4c5d3e121bf97c


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

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

From report at bugs.python.org  Fri Sep  7 19:08:27 2018
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Sep 2018 23:08:27 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536361707.74.0.56676864532.issue34605@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I'm using "master" in memoryview because of the audio connotation ("the 
source from which all copies will be produced"):

   https://en.wikipedia.org/wiki/Audio_mastering

The ManagedBufferObject is literally the source from which all views 
are produced.

Conductors are sometimes called "Maestro", there are chess grandmasters, 
Tiger Woods won the Masters Tournament, Art Tatum is called a master 
pianist, millions of people hold a master's degree.

The term "master" has so many positive connotations that I think it is 
misguided to effectively eliminate it from the current English language.

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

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

From report at bugs.python.org  Fri Sep  7 19:12:17 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 23:12:17 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536361937.78.0.56676864532.issue34246@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8566

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

From report at bugs.python.org  Fri Sep  7 19:15:25 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 23:15:25 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536362125.93.0.56676864532.issue34246@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 5b7a2cb5caeb7df68e637f45a98632cbc84a51bf by Pablo Galindo in branch 'master':
bpo-34246: Make sure test_smtplib always cleans resources when finished (GH-9108)
https://github.com/python/cpython/commit/5b7a2cb5caeb7df68e637f45a98632cbc84a51bf


----------

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

From report at bugs.python.org  Fri Sep  7 19:16:20 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 23:16:20 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1536362180.9.0.56676864532.issue33083@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset fa221d804f1bc07d992f820069bad24f176ed66d by Pablo Galindo in branch 'master':
bpo-33083: Update "What's new" with math.factorial changes (GH-9109)
https://github.com/python/cpython/commit/fa221d804f1bc07d992f820069bad24f176ed66d


----------

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

From report at bugs.python.org  Fri Sep  7 19:43:37 2018
From: report at bugs.python.org (deltaclock)
Date: Fri, 07 Sep 2018 23:43:37 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
Message-ID: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>


New submission from deltaclock <deltaclock at protonmail.com>:

The manager class of the multiprocessing module doesnt implement __next__ or __iter__ on its dictionary method and relies on using __getitem__.

This results in an unexpected functionality of an object that is supposed to act like a dict, and instead of looping over the dictionary keys it loops over its values.

The user needs to call dict() on this object in order to loop over it correctly, which is not that obvious.

The problem originates from there https://github.com/python/cpython/blob/master/Lib/multiprocessing/managers.py#L1136

Poc link: https://hastebin.com/codoqihowi.py

----------
components: Library (Lib)
files: test.py
messages: 324813
nosy: deltaclock
priority: normal
severity: normal
status: open
title: Incorrect iteration of Manager.dict() method of the multiprocessing module.
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47792/test.py

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

From report at bugs.python.org  Fri Sep  7 20:42:30 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 08 Sep 2018 00:42:30 +0000
Subject: [issue34609] Idle Unitest
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1536367350.84.0.56676864532.issue34609@psf.upfronthosting.co.za>


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

I have Python 3.6.5 on Ubuntu 18.04.  Initially, I was unable to recreate the issue.  However, issue33065 from 4 months ago has the same trace (except on a different import), so I tried stepping through debug using the minimal example that Terry gave and successfully reproduced the trace.

I then tried a new build of 3.8 on Ubuntu and was also able to reproduce by using 'step' while in debug.

I also was able to recreate using 'step' under 3.6.3 on Windows 7.

Note: At one point while stepping, the debug window shows a KeyError on unittest.  You'll see it yourself, but it is interesting.

----------

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

From report at bugs.python.org  Fri Sep  7 20:52:46 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 08 Sep 2018 00:52:46 +0000
Subject: [issue34609] Idle Unitest
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1536367966.31.0.56676864532.issue34609@psf.upfronthosting.co.za>


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

Just to help track this down, 'import math' does not cause the trace, but 'import email' does.  It seems to be modules that have a loader function.  My guess (but I haven't tried it yet) is that this would happen if stepping through pdb outside of IDLE too.

----------

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

From report at bugs.python.org  Fri Sep  7 21:04:13 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 08 Sep 2018 01:04:13 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536368653.75.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

I strongly disagree with this as a general principle.

"Master/slave" is a powerful, obvious metaphor which works well and is not the same as parent/child, server/client or employer/worker.

In fact, in the BDSM subcultures, "master/slave" can have *positive* connotations. You want to support diversity, then why are you discriminating against that subculture?

Talking about diversity: my wife is of a nationality that historically were often stolen to be slaves and indentured servants, and were discriminated against as second-class people right well into the second half the middle of the 20th century. My maternal family comes from a racial group (Slavic) which gives us the English word for slave and come from serf background. Both of us are angered by this attack on our linguistic culture. Stop trying to sanitize and infantalize language. That's far more offensive than the master/slave terminology.

I'm not sorry for this impassioned plea. You want diversity, that includes people like me.

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

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

From report at bugs.python.org  Fri Sep  7 21:20:31 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 08 Sep 2018 01:20:31 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536369631.59.0.56676864532.issue34246@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset eb6ab73f93c8b883a8d75a83560e2b4c59170d95 by Pablo Galindo in branch '3.6':
[3.6] bpo-34246: Use no mutable default args in smtplib (GH-8554) (#9112)
https://github.com/python/cpython/commit/eb6ab73f93c8b883a8d75a83560e2b4c59170d95


----------

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

From report at bugs.python.org  Fri Sep  7 21:22:13 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 08 Sep 2018 01:22:13 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1536369733.09.0.56676864532.issue34246@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Fri Sep  7 21:59:29 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 01:59:29 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536371969.45.0.56676864532.issue23855@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri Sep  7 22:56:34 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Sat, 08 Sep 2018 02:56:34 +0000
Subject: [issue34602] python3 resource.setrlimit strange behaviour under macOS
In-Reply-To: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>
Message-ID: <1536375394.25.0.56676864532.issue34602@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

I can repro it with a given sample file 
```
vladima-mbp $ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/resource.h>

int main() {
  struct rlimit rl;
  if(getrlimit(RLIMIT_STACK, &rl) < 0) {
    perror("getrlimit");
    exit(1);
  }

  rl.rlim_cur = rl.rlim_max;
  if(setrlimit(RLIMIT_STACK, &rl) < 0) {
    perror("setrlimit");
    exit(1);
  }
  return 0;
}vladima-mbp $ gcc   -Wl,-stack_size,1000000   -o test test.c
vladima-mbp $ ./test
setrlimit: Invalid argument
```
Similar settings were added to Python in https://github.com/python/cpython/commit/335ab5b66f4

----------
nosy: +v2m

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

From report at bugs.python.org  Sat Sep  8 02:10:54 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Sep 2018 06:10:54 +0000
Subject: [issue34608] gc.get_referrers behavior change 3.6 to 3.7
In-Reply-To: <1536337804.03.0.56676864532.issue34608@psf.upfronthosting.co.za>
Message-ID: <1536387054.96.0.56676864532.issue34608@psf.upfronthosting.co.za>


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

Likely fallout from 5a625d0aa6a6d9ec6574ee8344b41d63dcb9897e.

get_referrers() doesn't really guarantee anything. It's more of a clever hack based on however the Python GC works at the moment. So, this it probably WONTFIX.

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

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

From report at bugs.python.org  Sat Sep  8 03:21:56 2018
From: report at bugs.python.org (taketakeyyy)
Date: Sat, 08 Sep 2018 07:21:56 +0000
Subject: [issue34611] some examples in 'itertools' modules docs are inaccuracy.
Message-ID: <1536391316.81.0.56676864532.issue34611@psf.upfronthosting.co.za>


Change by taketakeyyy <taketakeyyy at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, taketakeyyy at gmail.com
priority: normal
severity: normal
status: open
title: some examples in 'itertools' modules docs are inaccuracy.
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep  8 04:08:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 08:08:20 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1536394100.92.0.56676864532.issue34610@psf.upfronthosting.co.za>


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

DictProxy needs to provide the __iter__() method. And perhaps methods keys(), values() and items() need to be reworked in Python 3. has_key() is unneeded in Python 3.

It is worth to test also other special and new in Python 3 methods.

----------
nosy: +benjamin.peterson, serhiy.storchaka
versions: +Python 2.7, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep  8 04:16:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Sep 2018 08:16:19 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536394579.75.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

An alternative would be to add multiple formatters. Example:

* %Tn: type name, type.__name__, Py_TYPE(obj)->tp_name
* %Tq: qualified name, type.__qualname__
* %Ts: short name, never contains "."
* %Tf: fully qualified name, "module.qualified.name"

What do you think Serhiy?

----------

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

From report at bugs.python.org  Sat Sep  8 04:39:53 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sat, 08 Sep 2018 08:39:53 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536395993.44.0.56676864532.issue34605@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@vstinner:

> For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

This is too vague. Define what "diversity reasons" are and elaborate your point. Referring to some online discussions is not a way for making a serious argument. Make a point at least (i.e. define the term, add pro/contra arguments and explain why you've taken your decision). Your political standpoint is your political standpoint and it's not my business. However, making these changes without giving reasons and arguments for them is a problem.

Let me ask:

Are these "diversity reasons" really reasons? What I've heard seen so far regarding "diversity reasons, ..." had little to nothing to do with rational thinking or argumentation. Is it really necessary to pollute Python code base with SJW ideology/terminology? What comes next?

Ad absurdum: If I find anything associated with something unpleasant to me in Python code or something which can be considered as e.g. "cultural appropriation", I'm free to change it for diversity reason?

----------
nosy: +suic

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

From report at bugs.python.org  Sat Sep  8 04:43:34 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 08 Sep 2018 08:43:34 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536396214.15.0.56676864532.issue34605@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/issue34605>
_______________________________________

From report at bugs.python.org  Sat Sep  8 04:49:20 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 08 Sep 2018 08:49:20 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536396560.83.0.56676864532.issue34605@psf.upfronthosting.co.za>


Matej Cepl <mcepl at cepl.eu> added the comment:

Guys, really, don't we have anything better to do with your time than this silliness?

Even if the terminology would be used in the strictest and most brutal meaning, i.e., slave must mindlessly follow orders of its master, there is nothing of approval of the real human slavery in the past (or present). This is just the pretty good terminology for such one-sided relationship which is traditionally used in the computer world. By elimination of the word from the world, not a yota changes about the reality of slavery in the past (or present).

-1 from me with the extreme violence for introducing such quasi-political nonsense to BPO and wasting everybody's time.

----------
nosy: +mcepl

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

From report at bugs.python.org  Sat Sep  8 05:05:28 2018
From: report at bugs.python.org (marche147)
Date: Sat, 08 Sep 2018 09:05:28 +0000
Subject: [issue34602] python3 resource.setrlimit strange behaviour under macOS
In-Reply-To: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>
Message-ID: <1536397528.28.0.56676864532.issue34602@psf.upfronthosting.co.za>


marche147 <bitmarche at gmail.com> added the comment:

Thanks for the repro! It did help for pinpointing the issue.

So I took a little spare time and dived into xnu kernel code, here is my assumption based on what I found (N.B. : My assumption comes from a simple experiment and a brief skim of the source code within 15 minutes or less, it could be seriously wrong since I'm not an expert of XNU kernel, and I currently don't have the time to build and debug it.) :

In bsd/kern/kern_resource.c, there's a function `dosetrlimit` which handles the `setrlimit` request, and here's part of it:

```
  case RLIMIT_STACK:
    // ...
    if (limp->rlim_cur > alimp->rlim_cur) {
      user_addr_t addr;
      user_size_t size;

        /* grow stack */
        size = round_page_64(limp->rlim_cur);
        size -= round_page_64(alimp->rlim_cur);

      addr = p->user_stack - round_page_64(limp->rlim_cur);
      kr = mach_vm_protect(current_map(),
               addr, size,
               FALSE, VM_PROT_DEFAULT);
      if (kr != KERN_SUCCESS) {
        error =  EINVAL;
        goto out;
      }
    } // ...

```

As we can see, the kernel will try to `mprotect` the memory preceding the stack to `VM_PROT_DEFAULT` (presumably read & write). I then used `vmmap` to see the difference between two binaries compiled with different commands. And the results are : 

1. Binary compiled without default stack size:

```
- Before calling setrlimit

...
STACK GUARD            00007ffee76d9000-00007ffeeaed9000 [ 56.0M     0K     0K     0K] ---/rwx SM=NUL          stack guard for thread 0
...
Stack                  00007ffeeaed9000-00007ffeeb6d9000 [ 8192K    20K    20K     0K] rw-/rwx SM=PRV          thread 0
...
                                VIRTUAL RESIDENT    DIRTY  SWAPPED VOLATILE   NONVOL    EMPTY   REGION
REGION TYPE                        SIZE     SIZE     SIZE     SIZE     SIZE     SIZE     SIZE    COUNT (non-coalesced)
===========                     ======= ========    =====  ======= ========   ======    =====  =======
Kernel Alloc Once                    8K       4K       4K       0K       0K       0K       0K        2
MALLOC guard page                   16K       0K       0K       0K       0K       0K       0K        5
MALLOC metadata                     60K      60K      60K       0K       0K       0K       0K        6
MALLOC_SMALL                      16.0M      16K      16K       0K       0K       0K       0K        3         see MALLOC ZONE table below
MALLOC_TINY                       2048K      32K      32K       0K       0K       0K       0K        3         see MALLOC ZONE table below
STACK GUARD                       56.0M       0K       0K       0K       0K       0K       0K        2
Stack                             8192K      20K      20K       0K       0K       0K       0K        2
__DATA                            2324K    1192K     208K       0K       0K       0K       0K       43
__LINKEDIT                       192.7M    21.7M       0K       0K       0K       0K       0K        4
__TEXT                            9448K    8224K       0K       0K       0K       0K       0K       48
shared memory                        8K       8K       8K       0K       0K       0K       0K        3
===========                     ======= ========    =====  ======= ========   ======    =====  =======
TOTAL                            286.3M    31.0M     348K       0K       0K       0K       0K      110
...

- After calling setrlimit

...
STACK GUARD            00007ffee76d9000-00007ffee76da000 [    4K     0K     0K     0K] ---/rwx SM=NUL          stack guard for thread 0
...
Stack                  00007ffee76da000-00007ffeeaed9000 [ 56.0M     0K     0K     0K] rw-/rwx SM=NUL          thread 0
Stack                  00007ffeeaed9000-00007ffeeb6d9000 [ 8192K    20K    20K     0K] rw-/rwx SM=PRV          thread 0
...
                                VIRTUAL RESIDENT    DIRTY  SWAPPED VOLATILE   NONVOL    EMPTY   REGION
REGION TYPE                        SIZE     SIZE     SIZE     SIZE     SIZE     SIZE     SIZE    COUNT (non-coalesced)
===========                     ======= ========    =====  ======= ========   ======    =====  =======
Kernel Alloc Once                    8K       4K       4K       0K       0K       0K       0K        2
MALLOC guard page                   16K       0K       0K       0K       0K       0K       0K        5
MALLOC metadata                     60K      60K      60K       0K       0K       0K       0K        6
MALLOC_SMALL                      16.0M      20K      20K       0K       0K       0K       0K        3         see MALLOC ZONE table below
MALLOC_TINY                       2048K      32K      32K       0K       0K       0K       0K        3         see MALLOC ZONE table below
STACK GUARD                          4K       0K       0K       0K       0K       0K       0K        2
Stack                             64.0M      20K      20K       0K       0K       0K       0K        3
__DATA                            2324K    1192K     208K       0K       0K       0K       0K       43
__LINKEDIT                       192.7M    21.7M       0K       0K       0K       0K       0K        4
__TEXT                            9448K    8224K       0K       0K       0K       0K       0K       48
shared memory                        8K       8K       8K       0K       0K       0K       0K        3
===========                     ======= ========    =====  ======= ========   ======    =====  =======
TOTAL                            286.3M    31.0M     352K       0K       0K       0K       0K      111
...
```

2. Binary compiled with default stack size:

```
Before calling setrlimit :
...
STACK GUARD            00007ffee09c2000-00007ffee09c3000 [    4K     0K     0K     0K] ---/rwx SM=NUL          stack guard for thread 0
...
Stack                  00007ffee09c3000-00007ffee19c3000 [ 16.0M    20K    20K     0K] rw-/rwx SM=PRV          thread 0
...
                                VIRTUAL RESIDENT    DIRTY  SWAPPED VOLATILE   NONVOL    EMPTY   REGION
REGION TYPE                        SIZE     SIZE     SIZE     SIZE     SIZE     SIZE     SIZE    COUNT (non-coalesced)
===========                     ======= ========    =====  ======= ========   ======    =====  =======
Kernel Alloc Once                    8K       4K       4K       0K       0K       0K       0K        2
MALLOC guard page                   16K       0K       0K       0K       0K       0K       0K        5
MALLOC metadata                     60K      60K      60K       0K       0K       0K       0K        6
MALLOC_SMALL                      8192K      12K      12K       0K       0K       0K       0K        2         see MALLOC ZONE table below
MALLOC_TINY                       1024K      20K      20K       0K       0K       0K       0K        2         see MALLOC ZONE table below
STACK GUARD                          4K       0K       0K       0K       0K       0K       0K        2
Stack                             16.0M      20K      20K       0K       0K       0K       0K        2
__DATA                            2324K    1192K     208K       0K       0K       0K       0K       43
__LINKEDIT                       192.7M    22.3M       0K       0K       0K       0K       0K        4
__TEXT                            9448K    8232K       0K       0K       0K       0K       0K       48
shared memory                        8K       8K       8K       0K       0K       0K       0K        3
===========                     ======= ========    =====  ======= ========   ======    =====  =======
TOTAL                            229.3M    31.7M     332K       0K       0K       0K       0K      108
```

As we can see, it seems that the kernel tried to `mprotect` (or we can say, allocate) from the "STACK GUARD" region. So where does this "STACK GUARD" region comes from? Let's see this:

bsd/kern/kern_exec.c, in `create_unix_stack` function (where the kernel creates the stack for a new task, I assume) :

```
...
#define unix_stack_size(p)  (p->p_rlimit[RLIMIT_STACK].rlim_cur)
...
    if (load_result->user_stack_size == 0) {
      load_result->user_stack_size = unix_stack_size(p);
      prot_size = mach_vm_trunc_page(size - load_result->user_stack_size);
    } else {
      prot_size = PAGE_SIZE;
    }

    prot_addr = addr;
    kr = mach_vm_protect(map,
             prot_addr,
             prot_size,
             FALSE,
             VM_PROT_NONE);
  ...
```

So that comes my conclusion: if the binary has a specified default stack size, this `load_result->user_stack_size` would not be zero (this should be set somewhere inside the mach-o parser/loader, I guess), so the kernel will only map a small page for the "STACK GUARD" region, otherwise the kernel will use the current stack size soft limit (inherited from the parent) as the `user_stack_size` and calculates a `prot_size`, which should be (rlim_max - rlim_cur). And of course, the python3 binary was built with default stack size, so the kernel does not provide a huge enough "STACK GUARD" region for the `setrlimit` syscall to allot more stack space than the default stack size.

----------

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

From report at bugs.python.org  Sat Sep  8 05:27:12 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sat, 08 Sep 2018 09:27:12 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536398832.77.0.56676864532.issue34605@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@mcepl: I completely agree with you that we shouldn't waste time with this. I would be better not to dig into the discussion about "master-slave" terminology. IMO we don't even need to go into that as the problem here is more substantial:

This case can create a very problematic precedent i.e. _on can modify (even drastically) a well established terminology based on "pseudo-reasons", political opinion or ideology_.

IMO this should be stopped and  prevented as soon as possible for all sake. On the other hand, I believe the @vstinner is a rational person and he is able to give _rational reasons_ for his decision which other could challenge as "potential offensiveness" of language is not an argument.

----------

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

From report at bugs.python.org  Sat Sep  8 05:42:13 2018
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 08 Sep 2018 09:42:13 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536399733.03.0.56676864532.issue34597@psf.upfronthosting.co.za>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

related: issue31359

----------
nosy: +lazka

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

From report at bugs.python.org  Sat Sep  8 06:01:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 10:01:11 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1536400871.31.0.56676864532.issue34610@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  8 06:01:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 10:01:33 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1536400893.3.0.56676864532.issue34610@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  8 06:17:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 10:17:54 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536401874.2.0.56676864532.issue34588@psf.upfronthosting.co.za>


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

In case of 4 repeated lines it doesn't make much sense to output 3 repeated lines and replace the forth line with "Previous line repeated 1 more time". This doesn't save space and doesn't help reading the traceback. I think it is better to output the forth repeated line.

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

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

From report at bugs.python.org  Sat Sep  8 06:33:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 10:33:56 +0000
Subject: [issue34611] some examples in 'itertools' modules docs are inaccuracy.
Message-ID: <1536402836.65.0.56676864532.issue34611@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Sat Sep  8 06:49:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 10:49:28 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536403768.97.0.56676864532.issue34595@psf.upfronthosting.co.za>


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

I think we need to handle only two cases: short and fully qualified names. __qualname__ without __module__ doesn't make sense, and the value of tp_name depends on implementation details (is it Python class or builtin class, heap class or dynamic class?). Maybe use %t and %T?

But we may want to support formatting the name of the type itself and the name of the object's type. This give us 4 variants.

For old string formatting we can introduce new % codes (with possible modifiers). But in modern string formatting "T" can have meaning for some types (e.g. for datetime). We can implement __format__ for the type type itself (though it can cause confusion if cls.__format__() is different from cls.__format__(instance)), but for formatting the name of  the object's type (as in your original proposition) we need to add a new  conversion flag like "!r".

----------

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

From report at bugs.python.org  Sat Sep  8 06:51:22 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Sep 2018 10:51:22 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536403882.82.0.56676864532.issue23855@psf.upfronthosting.co.za>


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


----------
pull_requests: +8568

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

From report at bugs.python.org  Sat Sep  8 06:51:33 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Sep 2018 10:51:33 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536403893.08.0.56676864532.issue23855@psf.upfronthosting.co.za>


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


----------
pull_requests: +8569

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

From report at bugs.python.org  Sat Sep  8 07:02:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 11:02:22 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>
Message-ID: <1536404542.43.0.56676864532.issue22807@psf.upfronthosting.co.za>


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

This breaks pickle compatibility. UUIDs pickled in 3.7 can't be unpickled in older Python versions because they do not have the SafeUUID class. See issue30977 for possible solution.

----------
nosy: +serhiy.storchaka, taleinat

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

From report at bugs.python.org  Sat Sep  8 07:03:59 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 Sep 2018 11:03:59 +0000
Subject: [issue34611] some examples in 'itertools' modules docs are inaccuracy.
Message-ID: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

@taketakeyyy: Did you mean to include information about *which* examples are inaccurate? This issue isn't really useful without that information.

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

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

From report at bugs.python.org  Sat Sep  8 07:37:13 2018
From: report at bugs.python.org (William Grzybowski)
Date: Sat, 08 Sep 2018 11:37:13 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536406633.75.0.56676864532.issue34604@psf.upfronthosting.co.za>


William Grzybowski <william88 at gmail.com> added the comment:

What is the policy to amend a new commit to master for %R? Create a new PR? Wont that cause problem with NEWS entry?

----------

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

From report at bugs.python.org  Sat Sep  8 07:48:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 11:48:22 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1536407302.66.0.56676864532.issue20104@psf.upfronthosting.co.za>


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


New changeset d700f97b627989d41cd4629dc02969f9a6b56d2f by Serhiy Storchaka in branch 'master':
bpo-20104: Change the file_actions parameter of os.posix_spawn(). (GH-6725)
https://github.com/python/cpython/commit/d700f97b627989d41cd4629dc02969f9a6b56d2f


----------

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

From report at bugs.python.org  Sat Sep  8 07:51:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 11:51:33 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1536407493.52.0.56676864532.issue20104@psf.upfronthosting.co.za>


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

Thank you for your contribution Pablo. This issue have appeared much more complex and less obvious than it looked initially.

----------

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

From report at bugs.python.org  Sat Sep  8 08:15:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 12:15:54 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <1536408954.81.0.56676864532.issue34586@psf.upfronthosting.co.za>


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

I concur with Raymond. The purpose of ChainMap is providing a mapping that hides the implementation detail of using several mappings as fallbacks. If you don't want to hide the implementation detail, you don't need to use ChainMap.

ChainMap exposes underlying mappings as the maps attribute, so you can use this implementation detail if you know that it is a ChainMap an not a general mapping. It is easy to write a code for searching what mapping contains the specified key.

    for m in cm.maps:
        if key in m:
            found = m
            break
    else:
        # raise an error or set a default,
        # what is appropriate for your concrete case

or even

    found = next(m for m in cm.maps if key in m)

if the key is always found or StopIteration is appropriate.

I don't think that such trivial snatch of code is worth adding a special ChainMap method or even documenting it explicitly in the ChainMap documentation.

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

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

From report at bugs.python.org  Sat Sep  8 08:19:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 12:19:43 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536409183.44.0.56676864532.issue34600@psf.upfronthosting.co.za>


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

> But the C version XMLParser requires that its TreeBuilder not be a subclass, when used in iterparse.

Creating a TreeBuilder subclass looks the Right Way. What are problems with this? Could you please provide a complete script that works in 2.7, but doesn't work in 3.x?

----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

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

From report at bugs.python.org  Sat Sep  8 08:31:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 12:31:23 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536409883.5.0.56676864532.issue34596@psf.upfronthosting.co.za>


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

It doesn't look like a good design to me if allow a function be a decorator and a decorator fabric at the same time. It always lead to cumbersome and errorprone implementation. Currently there is only one example of such design in the stdlib, other propositions were rejected.

Checking that the argument is a string and raising exception otherwise looks good to me for 3.8. There is no a bug that need to be fixed in maintained versions. If you use unittest.skip() improperly, it is your failure. Helping to catch such mistakes is a new feature.

----------
nosy: +serhiy.storchaka
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep  8 08:32:16 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 08 Sep 2018 12:32:16 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536409936.87.0.56676864532.issue34600@psf.upfronthosting.co.za>


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

There are dedicated handler methods that you can implement: "def comment(self, comment)" and "def pi(self, target, data)". Both (c)ElementTree and lxml support those.

I think the "target" argument to the parser is a bit underdocumented, and the standard TreeBuilder does not implement those methods (because it does not use them).

https://docs.python.org/3/library/xml.etree.elementtree.html#xmlparser-objects

Probably worth mentioning that in the docs.

----------

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

From report at bugs.python.org  Sat Sep  8 08:32:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 12:32:21 +0000
Subject: [issue34574] OrderedDict iterators are exhausted during pickling
In-Reply-To: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>
Message-ID: <1536409941.32.0.56676864532.issue34574@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Sep  8 08:34:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 12:34:30 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536410070.68.0.56676864532.issue34580@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag, ghaering

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

From report at bugs.python.org  Sat Sep  8 08:59:21 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 08 Sep 2018 12:59:21 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536411561.1.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

This is certainly a topic that generates a lot of opinions both ways, not just here, but on many other projects.  Based on that, I don't think it's fair to blame Victor for bringing it up for discussion.  This is and has been an industry discussion for many years (master/slave as it relates to technology was named the most politically incorrect term in 2004).  Victor simply brought it up here.

All of the same arguments and counterarguments have been mentioned in these past discussions.  You can argue that this is ridiculous and political correctness has gone too far.  You can argue that this term (master/slave) perfectly reflects the model.  You can argue that it's not the same relationship as parent/child.  These are probably all valid reasons to not change it.  But, I think it's mostly because it's what we're used to.  

Here's an idea -- find a friend and explain to them that there is a concept in computer science where there is a group of 'things' and exactly one of those things is the main point of contact or first in line, but the other things around it that either get direction from that main one, or they are exact copies of that main one, or they are downstream from that main one.  Sometimes it's because if the main one isn't available, then one of the others is ready to take its place.  Or sometimes it's for other purposes (like IDE).  Really set the stage in describing what it is.  Then tell them it's called master/slave.  They probably won't believe that name because it's a little shocking.  We take it for granted, but it doesn't really describe the situation.

I know I'm simplifying and I'm probably not 100% accurate, but I think you get my point.  Except for the fact that it's imbedded in engineering and computer science and we know it, there's not really a  reason for it to be called what it is and there might be other alternatives that are better descriptors.

Personally, one that I've never seen suggested, but one that I think can be used to describe the relationship of "one in charge and others follow, but can take over" would be alpha/omega (as in a wolf pack).  It's a little stronger that leader/follower, doesn't imply the same structure as parent/child, and allows for the idea that an omega could take over the role of an alpha.  Plus, it's very neutral.  Just too bad the guys who originally coined the phrase "master/slave" didn't use "alpha/omega".  

(for the record, political correctness sometimes drives me crazy and I may not see a need to change something like master/slave, but at the same time, I can understand why other people would like to see it changed)

(second aside - I don't recall that there were arguments a few months ago on the PR to make the docs gender neutral.  Maybe people were against that too as being 'too politically correct', but they didn't feel the need to talk about.  To me, this issue is similar to that one.)

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Sat Sep  8 09:42:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 13:42:03 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1536414123.61.0.56676864532.issue34410@psf.upfronthosting.co.za>


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

I take this.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Sep  8 09:48:14 2018
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 08 Sep 2018 13:48:14 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536414494.64.0.56676864532.issue34605@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Most of the opposition seems to be against a blanket replacing of all master and slave usages, which seems fairly reasonable to me. 

For example, I'm all for the libregrtest change since it conveys the meaning just as well and is an internal tool. However, changing MemoryView and pty seem way more iffy. These changes are potentially backwards incompatible and actually hurt usability.

Unlike other projects, Python doesn't have nearly enough uses of this terminology to warrant a massive political discussion in my opinion. Just look at the usages on a case-by-case basis and be done with it.

----------

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

From report at bugs.python.org  Sat Sep  8 09:55:31 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Sep 2018 13:55:31 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536414931.63.0.56676864532.issue34605@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I commented here to explain the master <-> view terminology of memoryview. 
If anyone wants to change that, please open a separate issue and add me as 
the author to the nosy list.

----------

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

From report at bugs.python.org  Sat Sep  8 09:55:56 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Sep 2018 13:55:56 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536414956.27.0.56676864532.issue34605@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/issue34605>
_______________________________________

From report at bugs.python.org  Sat Sep  8 10:00:26 2018
From: report at bugs.python.org (Zahari Dim)
Date: Sat, 08 Sep 2018 14:00:26 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536408954.81.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <CANx7HSYTZf4qTvAz-ym48rWJcPx-uGbUca9H+Q00Udm9JM=U_w@mail.gmail.com>


Zahari Dim <zaharid at gmail.com> added the comment:

On Sat, Sep 8, 2018 at 1:15 PM Serhiy Storchaka <report at bugs.python.org> wrote:
>
>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> I concur with Raymond. The purpose of ChainMap is providing a mapping that hides the implementation detail of using several mappings as fallbacks. If you don't want to hide the implementation detail, you don't need to use ChainMap.
>
> ChainMap exposes underlying mappings as the maps attribute, so you can use this implementation detail if you know that it is a ChainMap an not a general mapping. It is easy to write a code for searching what mapping contains the specified key.

I don't know where the idea that the underlying mappings are an
implementation detail comes from. It certainly isn't from the
documentation, which mentions uses such as nested scopes and
templates, which cannot be attained with a single mapping. It also
doesn't match my personal usage, where as discussed, even the simpler
cases benefit from information on the underlying mappings. It is a
surprising claim to make given than the entirety of the public
interface specific to ChainMap (maps, new_child and parents) deals
with the fact that there is more structure than one mapping. I also
have a hard time discerning this idea from Raymond's messages.

>
>     for m in cm.maps:
>         if key in m:
>             found = m
>             break
>     else:
>         # raise an error or set a default,
>         # what is appropriate for your concrete case

This "trivial snatch of code" contains at least two issues that make
it fail in situations where the actual implementation of `__getitem__`
would work, opening the door for hard to diagnose corner cases. If
anything, in my opinion, the fact that this code is being proposed as
an alternative reinforces the idea that the implementation of the
searching method should be in the standard library.

----------

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

From report at bugs.python.org  Sat Sep  8 10:05:51 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sat, 08 Sep 2018 14:05:51 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536415551.89.0.56676864532.issue34605@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@cheryl.sabella let me challenge some points in your arguments:

> Based on that, I don't think it's fair to blame Victor for bringing it up for discussion.

Ok, but where was the discussion? @vstinner didn't even make a point and some of the PRs were merged. Maybe I'm too spoiled by the field where I come from but this can be hardly considered to be "bringing up something for a discussion" when someone doesn't even make a point (like e.g. "I think it should be changed because..."). Ad absurdum I could say: Because of because-it-can-hurt-someones-feelings reasons it would be nice to...

> I don't recall that there were arguments a few months ago on the PR to make the docs gender neutral.  Maybe people were against that too as being 'too politically correct', but they didn't feel the need to talk about.  To me, this issue is similar to that one.

_Personally_, I consider that to be the same kind of PC/SJW nonsense and there should've been a similar discussion. However, there's a big difference. Making documentation gender neutral is unnecessary but it doesn't affect any established CS terminology and doesn't introduce artificial terminological inconsistency between related technologies. 

> But, I think it's mostly because it's what we're used to.

Yes, and that's what is established terminology about.

> Here's an idea -- find a friend and explain to them that there is a concept in computer science...

When you enter a new field a part of your responsibility is to learn its terminology and not voluntarily change it because it somehow affects you (hurts your feelings, not compatible with your political view point etc.). Imagine doing the same thing in physics, chemistry or mathematics. Would you redefine number 1 for diversity reasons (there are ways for making up diversity reasons even for this*)? The terminology used inside a field is primarily for the people who are inside the field and understand it.

My arguments can sound a bit sarcastic as they try to illustrate the absurdity of this whole issue. They are by no means personal. Seeing all the PC/SJW nonsense around me, I'm afraid that this can be the starting of Python becoming PCython (by which I don't mean a combination of Python with Cython :)).

* To see how far could this go, look at this video: https://www.youtube.com/watch?v=iKcWu0tsiZM

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

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

From report at bugs.python.org  Sat Sep  8 10:07:43 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Sat, 08 Sep 2018 14:07:43 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536415663.79.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <lolbuntu at chown.me> added the comment:

Thanks for working on this bug!

My message focussed on the closing aspect because that was my problem. :)

Maybe the wording should be more general like:
- "Note that this does not automatically call :meth:`close` on the connection object."
+ "Note that this does not automatically handle the connection object."

(I'm not sure if I should comment here or on the PR on gh)

----------

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

From report at bugs.python.org  Sat Sep  8 11:20:45 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 08 Sep 2018 15:20:45 +0000
Subject: [issue34608] gc.get_referrers behavior change 3.6 to 3.7
In-Reply-To: <1536337804.03.0.56676864532.issue34608@psf.upfronthosting.co.za>
Message-ID: <1536420045.02.0.56676864532.issue34608@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  8 11:55:00 2018
From: report at bugs.python.org (=?utf-8?b?5aSn6YeO6ZqG5byY?=)
Date: Sat, 08 Sep 2018 15:55:00 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1536356057.33.0.902498594338.issue34546@psf.upfronthosting.co.za>
Message-ID: <CAKyqbBrBSTSa7ZyeoG4oHxz8JBRZYqOaSiJQvA+R09W-F8HC0g@mail.gmail.com>


???? <oono0114 at gmail.com> added the comment:

My original reason of this is supporting Windows Explore decryption.
That doesn't support AES but support only this traditional PKWARE
encryption.
In my work, some recipients who received the zip file cannot install 3rd
party tools on their Windows
https://blogs.msdn.microsoft.com/oldnewthing/20180515-00/?p=98755

But as Christian explained for me in below thread, I understand we should
use 3rd party module for this purpose
https://mail.python.org/pipermail/python-dev/2018-September/155091.html

Thanks and Regards,
-----------
Takahiro Ono

2018?9?8?(?) 6:34 Serhiy Storchaka <report at bugs.python.org>:

>
> Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:
>
>
> ----------
> resolution:  -> rejected
> stage: patch review -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34546>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Sep  8 12:23:34 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 16:23:34 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536423814.43.0.56676864532.issue34580@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

We always explicitly document what the context manager does even if it simply calls an object's close() method. See https://docs.python.org/3/library/fileinput.html#fileinput.input and https://docs.python.org/3/library/shelve.html#shelve.Shelf for example.

In this case, the documentation already explains what the context manager does after the with block finishes (it also explains the behavior on success and error) with a detailed example.

Would adding a "con.close()" line to the example at https://docs.python.org/3/library/sqlite3.html#using-the-connection-as-a-context-manager clarify the behavior for you?

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

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

From report at bugs.python.org  Sat Sep  8 12:41:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 16:41:51 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536424911.21.0.56676864532.issue34605@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Personally, I find parent/child more descriptive if it can be used in the same context with master/slave, so I'm in favor of replacing master/slave with parent/child where applicable.

However, I agree that the code changes in PR 9100 are a bit excessive. It would be nice if we could keep the members of the public API (some of them have already been deprecated) and variable/function/parameter names left out of this cleanup.

----------
components: +Documentation
nosy: +berker.peksag
type:  -> enhancement

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

From report at bugs.python.org  Sat Sep  8 13:01:32 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Sat, 08 Sep 2018 17:01:32 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536426092.17.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <lolbuntu at chown.me> added the comment:

Thanks, I lacked the greater picture.

Yes, adding a "con.close()" line to the snippet would clarify for me!

----------

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

From report at bugs.python.org  Sat Sep  8 13:04:14 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Sep 2018 17:04:14 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536426254.34.0.56676864532.issue34605@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Trying to remove myself from the nosy list again (I know that the interface sometimes surprisingly adds/removes persons).

----------

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

From report at bugs.python.org  Sat Sep  8 13:04:38 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 Sep 2018 17:04:38 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536426278.8.0.56676864532.issue34605@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/issue34605>
_______________________________________

From report at bugs.python.org  Sat Sep  8 13:07:03 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 08 Sep 2018 17:07:03 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536426092.17.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <CAAjsFLTkp2Nd9oMhwxDbDZB-mdh78o-2FbWpC69XFYAOXCeTmA@mail.gmail.com>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the comments. I will add `con.close()` to the examples linked.
Should I remove or change this line as per Daniel's comment "Note that this
does not automatically call :meth:`close` on the connection object."

Thanks
-- 

Regards,
Karthikeyan S

----------

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

From report at bugs.python.org  Sat Sep  8 13:18:35 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 17:18:35 +0000
Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11
 files
In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za>
Message-ID: <1536427115.94.0.56676864532.issue20178@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I'm working on converting Modules/_sqlite/* to Argument Clinic.

----------
nosy: +berker.peksag
versions: +Python 3.8 -Python 3.5

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

From report at bugs.python.org  Sat Sep  8 13:21:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 17:21:47 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536427307.57.0.56676864532.issue34580@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> Should I remove or change this line as per Daniel's comment "Note that
> this does not automatically call :meth:`close` on the connection object."

I'd prefer to keep the current wording as-is.

----------

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

From report at bugs.python.org  Sat Sep  8 13:32:23 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 08 Sep 2018 17:32:23 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536427943.27.0.56676864532.issue34596@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I don't agree that this change makes the implementation significantly more cumbersome.  I also think there's a backward compatibility argument to be made for allowing the uncalled usage, particularly considering the OP's published example and other similar ones, such as https://stackoverflow.com/questions/2066508/disable-individual-python-unit-tests-temporarily which was for me the first Google result for "python unittest skip" that was not our own docs.

----------

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

From report at bugs.python.org  Sat Sep  8 13:32:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 08 Sep 2018 17:32:52 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536427972.19.0.56676864532.issue34580@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks, I have pushed a change adding `con.close` at the end of the example and also verified that `./python.exe Doc/includes/sqlite3/ctx_manager.py` works as expected.

Thanks

----------

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

From report at bugs.python.org  Sat Sep  8 13:53:42 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 17:53:42 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536429222.63.0.56676864532.issue34580@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

PR 9079 looks good to me.

I think we can use this as an opportunity to make the rest of the examples in the sqlite3 documentation more consistent and add missing "conn.close()" calls.

----------

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

From report at bugs.python.org  Sat Sep  8 13:57:46 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Sat, 08 Sep 2018 17:57:46 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536429466.56.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <bpo at chown.me> added the comment:

Yes, I would totally support this move as it would show users that it's important to close it!

----------

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

From report at bugs.python.org  Sat Sep  8 14:33:48 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 18:33:48 +0000
Subject: [issue31734] crash or SystemError in sqlite3.Cache in case it is
 uninitialized or partially initialized
In-Reply-To: <1507557245.08.0.213398074469.issue31734@psf.upfronthosting.co.za>
Message-ID: <1536431628.54.0.56676864532.issue31734@psf.upfronthosting.co.za>


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


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Sep  8 14:35:14 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 08 Sep 2018 18:35:14 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536431714.36.0.56676864532.issue34580@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sounds good to me too since I copy paste from there time to time and also an unclosed connection doesn't seem to trigger a ResourceWarning it seems. I have pushed a commit to the same PR. I have changed it manually for all the include files. I have ran the files after the PR with the below and I couldn't see any breakages. Let me know if I have missed anything in the include files. I guess there are some more examples in sqlite3.rst but I don't know if it needs to be added on all snippets since they are more focused on the particular function unlike the files in the include folder that has full programs.

Verified with : 

$ ls -1 Doc/includes/sqlite3/*py > sample.txt
$ cat sample.txt | xargs -n 1 ./python.exe

Thanks

----------

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

From report at bugs.python.org  Sat Sep  8 15:01:30 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Sep 2018 19:01:30 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536433290.4.0.56676864532.issue34588@psf.upfronthosting.co.za>


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

It actually does save space because each traceback entry is usually two lines (frame id and source snippet).

I don't really have an opinion about what should happen be printed on the boundary cases. My current PR seems like a strict improvement to the current implementation, which is just incorrect.

----------

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

From report at bugs.python.org  Sat Sep  8 15:25:35 2018
From: report at bugs.python.org (Leo Singer)
Date: Sat, 08 Sep 2018 19:25:35 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1536434735.68.0.56676864532.issue14156@psf.upfronthosting.co.za>


Leo Singer <doc.aronnax at gmail.com> added the comment:

I just hit this bug. Would the proposed patch get any more attention if submitted as a pull request?

----------
nosy: +Leo Singer

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

From report at bugs.python.org  Sat Sep  8 15:50:20 2018
From: report at bugs.python.org (David Spahn)
Date: Sat, 08 Sep 2018 19:50:20 +0000
Subject: [issue31652] make install fails: no module _ctypes
In-Reply-To: <1506812661.87.0.213398074469.issue31652@psf.upfronthosting.co.za>
Message-ID: <1536436220.25.0.56676864532.issue31652@psf.upfronthosting.co.za>


David Spahn <dgerardspahn at gmail.com> added the comment:

I'm getting the same error   File "/usr/src/Python-3.7.0/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
Makefile:1122: recipe for target 'install' failed
make: *** [install] Error 1
 
Linux Mint 19

----------
nosy: +dgspahn
Added file: https://bugs.python.org/file47793/query.csv

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

From report at bugs.python.org  Sat Sep  8 16:31:29 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 Sep 2018 20:31:29 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536438689.96.0.56676864532.issue34421@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset 0afada163c7ef25c3a9d46ed445481fb69f2ecaf by ?ric Araujo (Julien Malard) in branch 'master':
bpo-34421 avoid unicode error in distutils logging (GH-8799)
https://github.com/python/cpython/commit/0afada163c7ef25c3a9d46ed445481fb69f2ecaf


----------

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

From report at bugs.python.org  Sat Sep  8 16:32:05 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Sep 2018 20:32:05 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536438725.03.0.56676864532.issue34421@psf.upfronthosting.co.za>


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


----------
pull_requests: +8570

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

From report at bugs.python.org  Sat Sep  8 16:32:13 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Sep 2018 20:32:13 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536438733.44.0.56676864532.issue34421@psf.upfronthosting.co.za>


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


----------
pull_requests: +8571

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

From report at bugs.python.org  Sat Sep  8 16:35:11 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 Sep 2018 20:35:11 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536438911.59.0.56676864532.issue34421@psf.upfronthosting.co.za>


Change by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
resolution:  -> fixed
stage: patch review -> commit review
status: open -> pending
type: crash -> behavior
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep  8 16:44:23 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Sep 2018 20:44:23 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536439463.83.0.56676864532.issue34421@psf.upfronthosting.co.za>


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


New changeset 3b36642924a51e6bceb7033916c3049764817166 by Miss Islington (bot) in branch '3.6':
bpo-34421 avoid unicode error in distutils logging (GH-8799)
https://github.com/python/cpython/commit/3b36642924a51e6bceb7033916c3049764817166


----------
nosy: +miss-islington
status: pending -> open

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

From report at bugs.python.org  Sat Sep  8 16:53:02 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Sep 2018 20:53:02 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536439982.18.0.56676864532.issue34421@psf.upfronthosting.co.za>


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


New changeset 77b92b15a5e5c84b91d3fd9d02f63db432fa8903 by Miss Islington (bot) in branch '3.7':
bpo-34421 avoid unicode error in distutils logging (GH-8799)
https://github.com/python/cpython/commit/77b92b15a5e5c84b91d3fd9d02f63db432fa8903


----------

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

From report at bugs.python.org  Sat Sep  8 17:59:30 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 08 Sep 2018 21:59:30 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536443970.08.0.56676864532.issue34605@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/issue34605>
_______________________________________

From report at bugs.python.org  Sat Sep  8 18:29:55 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 22:29:55 +0000
Subject: [issue34612] doc Some classes are treated as functions in Built-in
 Functions
Message-ID: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

Beyond other classes documented as functions (classmethod, enumerate, filter, map, reversed, staticmethod, super and zip), the following issues exist:

* memoryview, range, and tuple are marked as functions
* complex and object treat themselves as functions in their descriptions

Attached PR fixes this.

----------
assignee: docs at python
components: Documentation
messages: 324864
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc Some classes are treated as functions in Built-in Functions
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep  8 18:31:30 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 22:31:30 +0000
Subject: [issue34612] doc Some classes are treated as functions in Built-in
 Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536445890.03.0.56676864532.issue34612@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
keywords: +patch
pull_requests: +8572
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34612>
_______________________________________

From report at bugs.python.org  Sat Sep  8 19:03:27 2018
From: report at bugs.python.org (Jens Troeger)
Date: Sat, 08 Sep 2018 23:03:27 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1536447807.46.0.56676864532.issue28879@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

Any updates on this? Looks like the proposed change has not been merged into mainstream yet?

I?m having problems with Google rejecting emails:

    (555, b'5.5.2 Syntax error, goodbye. r10-v6sm7321838qtj.41 - gsmtp', '?')

and using IETF?s message linter (https://tools.ietf.org/tools/msglint/) I get the following:

    ERROR: missing mandatory header 'date' lines 1-7
    ERROR: missing mandatory header 'return-path' lines 1-7

amongst a few others.

----------
nosy: +_savage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Sat Sep  8 19:11:13 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 08 Sep 2018 23:11:13 +0000
Subject: [issue34612] doc Some classes are treated as functions in Built-in
 Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536448273.79.0.56676864532.issue34612@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure this is an improvement. While it's true that 'complex' is a class, it's described here as a function. Same as 'int'. The fact that it's a function or class isn't so important here.

I suspect it will confuse people to have something described as a class in the section titled 'Built-in Functions'. We wouldn't want to change the section to the more correct 'Built-in Callables'.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34612>
_______________________________________

From report at bugs.python.org  Sat Sep  8 19:39:51 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 23:39:51 +0000
Subject: [issue34612] doc Some classes are treated as functions in Built-in
 Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536449991.01.0.56676864532.issue34612@psf.upfronthosting.co.za>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Please note that several classes are marked as such (e.g., int, float, str, dict, list) and bool for example treats itself as a class in it's description.

Perhaps your concerns applies to all those ocurrences too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34612>
_______________________________________

From report at bugs.python.org  Sat Sep  8 19:46:09 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 08 Sep 2018 23:46:09 +0000
Subject: [issue34612] doc Some classes are treated as functions in Built-in
 Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536450369.25.0.56676864532.issue34612@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Ah, you're correct. I just looked for the word "class" inside the "int" text, and it doesn't appear there: I thought it was deliberately left out. But it does show up in the sub-section header (before "int" itself). Sorry about that.

The text changes look good, then. I don't know enough about Sphinx to know how changing the meta-data affects things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34612>
_______________________________________

From report at bugs.python.org  Sat Sep  8 20:35:04 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Sep 2018 00:35:04 +0000
Subject: [issue34612] doc Some classes are treated as functions in Built-in
 Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536453304.33.0.56676864532.issue34612@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Eric.  These were marked as functions in the function section of the docs.  Their role as classes is noted in the body.  And their role as complete classes with a listing of their methods is documented elsewhere.

----------
nosy: +rhettinger
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34612>
_______________________________________

From report at bugs.python.org  Sat Sep  8 20:48:53 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Sep 2018 00:48:53 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536454133.16.0.56676864532.issue34605@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Mostly, I don't think these changes should be made, particularly in cases where "slave" isn't mentioned at all.  The word "master" is used in many contexts where master/slave doesn't apply (such as "master key").   Also, I think the PR disrespects all the original authors of the various documentation entries, none of whom have been consulted.

If a particular passage is demonstrably unclear or offensive, it should be changed; otherwise, we shouldn't let vaguely formed notions of political correctness shape other clear uses of plain English.  

As far as I can't tell there isn't a single instance where the docs use "master" as a reference to human slavery or where the use could be seen to imply an endorsement of that notion.

FWIW, Guido drew a line for this a few years ago when someone suggested removing the example using the phrase, "I see said the blind man and he picked up the hammer and saw".  The judgment was that we weren't going to go down this path unless there was actual offensive speech.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Sat Sep  8 23:56:11 2018
From: report at bugs.python.org (taketakeyyy)
Date: Sun, 09 Sep 2018 03:56:11 +0000
Subject: [issue34611] some examples in 'itertools' modules docs are inaccuracy.
In-Reply-To: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>
Message-ID: <1536465371.41.0.56676864532.issue34611@psf.upfronthosting.co.za>


Change by taketakeyyy <taketakeyyy at gmail.com>:


----------
keywords: +patch
pull_requests: +8573
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34611>
_______________________________________

From report at bugs.python.org  Sun Sep  9 01:45:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 09 Sep 2018 05:45:27 +0000
Subject: [issue34611] some examples in 'itertools' modules docs are inaccuracy.
In-Reply-To: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>
Message-ID: <1536471927.31.0.56676864532.issue34611@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I don't know if it's worth it to edit the results to return Python data structures in the linked PR. The current version is more concise and indicates the general result of the function instead of the actual return values of the function calls which is intentional. Maybe is there some example in itertools that you are referring to that has incorrect results?

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34611>
_______________________________________

From report at bugs.python.org  Sun Sep  9 02:35:46 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Sep 2018 06:35:46 +0000
Subject: [issue34611] some examples in 'itertools' modules docs are inaccuracy.
In-Reply-To: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>
Message-ID: <1536474946.31.0.56676864532.issue34611@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with  Karthikeyan.   The doc examples read fine as-is.  They have worked well for many users for a long time.  It only takes seconds of experimentation to see exactly what is returned.  There is also a plain text description and a rough pure python equivalent.

Marking this as not a bug.  Thank you for looking at the docs, but I'm going to pass on this particular suggestion.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34611>
_______________________________________

From report at bugs.python.org  Sun Sep  9 03:00:39 2018
From: report at bugs.python.org (Laurent Peuch)
Date: Sun, 09 Sep 2018 07:00:39 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
Message-ID: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>


New submission from Laurent Peuch <python at worlddomination.be>:

asyncio.StreamReader documentation incorrectly declare its initialization argument "limit" to be "None" by default https://docs.python.org/3/library/asyncio-stream.html#asyncio.StreamReader

In the source code it is set to _DEFAULT_LIMIT https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/asyncio/streams.py#L353 

_DEFAULT_LIMIT is set to "2 ** 16 # 64 KiB" https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/asyncio/streams.py#L19

This information is especially needed when you get the exception "asyncio.streams.LimitOverrunError: Separator is not found, and chunk exceed the limit" and want to increase the limit, but you don't have the initial value and you have to look at the source code to get it.

PS: this is my first ticket, I don't know if I should have open one for such a minor detail in the documentation

----------
assignee: docs at python
components: Documentation, asyncio
messages: 324873
nosy: asvetlov, docs at python, psycojoker, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.StreamReader initialization documentation incorrectly declare limit as None
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/issue34613>
_______________________________________

From report at bugs.python.org  Sun Sep  9 03:05:55 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Sep 2018 07:05:55 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536476755.03.0.56676864532.issue34613@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8574
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34613>
_______________________________________

From report at bugs.python.org  Sun Sep  9 03:06:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Sep 2018 07:06:29 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536476789.51.0.56676864532.issue34421@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I would prefer to use the backslashreplace error handler rather of the unicode-escape codec. Just as few lines above, but with ASCII encoding.

    msg = msg.encode('ascii', 'backslashreplace').decode('ascii')

It is still not clear to me why the current code purposed to handle this problem doesn't work in this case. We need to find the cause and fix the existing solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep  9 03:43:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 07:43:23 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536479003.45.0.56676864532.issue34595@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Sun Sep  9 03:53:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 07:53:53 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536479633.66.0.56676864532.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I think we need to handle only two cases: short and fully qualified names. __qualname__ without __module__ doesn't make sense, and the value of tp_name depends on implementation details (is it Python class or builtin class, heap class or dynamic class?). Maybe use %t and %T?

Ok, I wrote PR 9122 to add %t format and modify %T format:

* %t <=> type(obj).__name__
* %T <=> f"{type(obj).__module__}.{type(obj).__qualname__}"


> But we may want to support formatting the name of the type itself and the name of the object's type. This give us 4 variants.

Again, I'm not sure about these ones. _PyType_Name() can be used for %t-like directly on a type. Later we can expose _PyType_FullName() (function that I added in my latest PR) as a private function for %T-like directly on a type.


> For old string formatting we can introduce new % codes (with possible modifiers). But in modern string formatting "T" can have meaning for some types (e.g. for datetime). We can implement __format__ for the type type itself (though it can cause confusion if cls.__format__() is different from cls.__format__(instance)), but for formatting the name of  the object's type (as in your original proposition) we need to add a new  conversion flag like "!r".

I'm not sure that I understood directly.

Do you want to add a third formatter in PyUnicode_FromFormat() which would use Py_TYPE(obj)->tp_name? I dislike Py_TYPE(obj)->tp_name, since my intent is to conform to the PEP 399: tp_name is not accessible at the Python level, only type(obj).__name__ and type(obj).__qualname__.

Or do you want to add a new formatter to type.__format__() to expose %T at the Python level, f"{type(obj).__module__}.{type(obj).__qualname__}"?

Currently, type(obj).__name__ is the most popular way to format a string. Would it break the backward compatibility to modify *existing* error messages?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Sun Sep  9 04:33:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Sep 2018 08:33:14 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536481994.8.0.56676864532.issue34595@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Ok, I wrote PR 9122 to add %t format and modify %T format:

Nice!

I agree that it is easy to use _PyType_Name() directly. But using _PyType_FullName() instead of tp_name can be cumbersome because it returns a new object and needs error handling.

> Or do you want to add a new formatter to type.__format__() to expose %T at the Python level, f"{type(obj).__module__}.{type(obj).__qualname__}"?

Yes, I think we need a convenient way of formatting fully qualified name that omits the module name for types in the builtins module. It is equivalent to Py_TYPE(obj)->tp_name for extension types which is the most popular way to format a type name in error messages for now.

There are several open issues for inconsistency in error messages for Python and C implementations, because the former use type(obj).__name__ or obj.__class__.__name__, and the latter use Py_TYPE(obj)->tp_name. I hope finally we will fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Sun Sep  9 04:37:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Sep 2018 08:37:06 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536482226.96.0.56676864532.issue34595@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> in error messages

And in reprs. It is common to format a repr as "{typename}(...)" or "<{typename}(...)>". The difference is whether the typename is a short or fully qualified name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Sun Sep  9 05:17:44 2018
From: report at bugs.python.org (hongweipeng)
Date: Sun, 09 Sep 2018 09:17:44 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1536484664.35.0.56676864532.issue14156@psf.upfronthosting.co.za>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
pull_requests: +8577
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sun Sep  9 05:47:56 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 09 Sep 2018 09:47:56 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536486476.82.0.56676864532.issue34421@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

The existing re-code solution is being triggered, as the `errors` in this case is 'surrogateescape' with an encoding of 'cp1252'.

Here, pip is using subprocess.Popen() to have Python run setup.py.  During execution, a filename, 'taqdir\\\u0634\u0645\u0627\u0631.py', which has characters not encodable in cp1252.

I think that here, Python is not configuring its stdin/stdout/stderr streams correctly when run as a subprocess connected to pipes.  Or, at least, subprocess.Popen() isn't passing the right (or enough) information to Python to get itself configured.

There should ultimately be a way to have Python (in a subprocess, on Windows) pass through Unicode untouched to its calling process.  I suppose it would mean setting the PYTHONIOENCODING envvar when using subprocess.

After all that, it seems that:
1) pip needs to be changed to support calling Python subprocesses to enable lossless unicode transmission,
2) change the `errors` check in distutils.log to include 'surrogateescape'? (the heart of this issue)

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep  9 07:26:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 11:26:58 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536492418.64.0.56676864532.issue34604@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1bcd891c200b8122493ddad5a203331e1a3bfcb5 by Victor Stinner (William Grzybowski) in branch '3.6':
[3.6] bpo-34604: Fix possible mojibake in pwd.getpwnam() and grp.getgrnam() (GH-9098) (GH-9105)
https://github.com/python/cpython/commit/1bcd891c200b8122493ddad5a203331e1a3bfcb5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34604>
_______________________________________

From report at bugs.python.org  Sun Sep  9 07:27:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 11:27:35 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536492455.44.0.56676864532.issue34604@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7a633ed79cfba2cfc0f80410ddcaeecadc2030e9 by Victor Stinner (William Grzybowski) in branch '3.7':
[3.7] bpo-34604: Fix possible mojibake in pwd.getpwnam() and grp.getgrnam() (GH-9098) (GH-9104)
https://github.com/python/cpython/commit/7a633ed79cfba2cfc0f80410ddcaeecadc2030e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34604>
_______________________________________

From report at bugs.python.org  Sun Sep  9 07:30:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 11:30:35 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1536407493.52.0.56676864532.issue20104@psf.upfronthosting.co.za>
Message-ID: <CA+3bQGE+5szLPHSnO5peCv7vVrqqErVyx3WHkjkH4JpVgRu8AA@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

> Thank you for your contribution Pablo. This issue have appeared much more
complex and less obvious than it looked initially.

Yeah, thanks Pablo for your tenacy! This function is interesting in term of
performance and correctness ("atomic" function, signal safe?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sun Sep  9 07:34:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 11:34:06 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536492846.65.0.56676864532.issue34604@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug has been fixed. For %R, does someone want to propose a change for master? William?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34604>
_______________________________________

From report at bugs.python.org  Sun Sep  9 07:40:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 Sep 2018 11:40:06 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1536493206.4.0.56676864532.issue20104@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I close the issue, it's now done.

If someone wants to experiment in posix_spawn() in subprocess, please open a new issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Sun Sep  9 07:44:19 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 09 Sep 2018 11:44:19 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536493459.41.0.56676864532.issue34597@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Binaries currently work on the system you compiled on and any later release of macOS.  That's the only "promise" there currently is.

Anything better requires work, and hence someone willing to do that work. 

I'd love to be able to build on the latest macOS and deploy to older versions, but that's functionality I don't need myself at the moment which means this does not have priority for me. 

BTW. I haven't checked yet how invasive supporting weak linking for these symbols will be. That depends on where the symbols are used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Sun Sep  9 09:47:26 2018
From: report at bugs.python.org (Mike Thompson)
Date: Sun, 09 Sep 2018 13:47:26 +0000
Subject: [issue17535] IDLE: Add an option to show line numbers along the left
 side of the editor window, and have it enabled by default.
In-Reply-To: <1364102013.73.0.373085073641.issue17535@psf.upfronthosting.co.za>
Message-ID: <1536500846.72.0.56676864532.issue17535@psf.upfronthosting.co.za>


Mike Thompson <mthompson at sau23.org> added the comment:

I am a teacher, and this feature would really help me teach Python to my students. Especially when I am teaching the course remotely.

----------
nosy: +mthompsonwhs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17535>
_______________________________________

From report at bugs.python.org  Sun Sep  9 09:54:32 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 09 Sep 2018 13:54:32 +0000
Subject: [issue34608] gc.get_referrers behavior change 3.6 to 3.7
In-Reply-To: <1536337804.03.0.56676864532.issue34608@psf.upfronthosting.co.za>
Message-ID: <1536501272.69.0.56676864532.issue34608@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Benjamin is right.
This is very implementation detail.  We shouldn't rely on such edge case.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34608>
_______________________________________

From report at bugs.python.org  Sun Sep  9 09:55:18 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sun, 09 Sep 2018 13:55:18 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1536501318.45.0.56676864532.issue32502@psf.upfronthosting.co.za>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
pull_requests: +8578

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Sun Sep  9 09:57:21 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sun, 09 Sep 2018 13:57:21 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1536501441.36.0.56676864532.issue32502@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

I created the backport PR for 2.7 branch. Can anyone reopen this issue?

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Sun Sep  9 10:15:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Sep 2018 14:15:47 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536502547.64.0.56676864532.issue34421@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8579
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep  9 10:25:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Sep 2018 14:25:50 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536503150.24.0.56676864532.issue34421@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 9126 makes distutils.log using "backslashreplace" instead of "unicode-escape" and simplifies the code (it is more efficient now, although the performance of logging is not critical).

"unicode-escape" escapes all non-ASCII characters, even encodable. It also escapes control characters like \t, \b, \r or \x1a (which starts control sequences for ANSI compatible terminals), this can be not desirable.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep  9 10:45:17 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 09 Sep 2018 14:45:17 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1536504317.16.0.56676864532.issue34569@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8580
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34569>
_______________________________________

From report at bugs.python.org  Sun Sep  9 10:46:55 2018
From: report at bugs.python.org (Julien Malard)
Date: Sun, 09 Sep 2018 14:46:55 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1536486476.82.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <YTOPR01MB028313DD7AC7D0FB4E263319D9060@YTOPR01MB0283.CANPRD01.PROD.OUTLOOK.COM>


Julien Malard <julien.malard at mail.mcgill.ca> added the comment:

Hello,

Thanks for the insights and better fixes. Regarding (1), do you have any pointers on how or where to fix pip? I have an inprogress pull request there (https://github.com/pypa/pip/pull/5712) to fix a related unicode error during installation and could perhaps combine both solutions.

Thanks!

-Julien

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep  9 11:47:39 2018
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 09 Sep 2018 15:47:39 +0000
Subject: [issue34614] Builtin `abs(Path)` returns `Path.absolute()`.
Message-ID: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

This complements the current Path behavior that overrides division operators for path joining, in that it makes manually-constructed paths easier to form and arguably more readable.

Before:

p = Path("some", "relative", "path")
q = p.absolute() / "some" / "further" / "path"

After:

p = Path("some", "relative", "path")
q = abs(p) / "some" / "further" / "path"

----------
components: Library (Lib)
messages: 324890
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Builtin `abs(Path)` returns `Path.absolute()`.
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 11:48:17 2018
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 09 Sep 2018 15:48:17 +0000
Subject: [issue34614] Builtin `abs(Path)` returns `Path.absolute()`.
In-Reply-To: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>
Message-ID: <1536508097.82.0.56676864532.issue34614@psf.upfronthosting.co.za>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +8581
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 12:35:44 2018
From: report at bugs.python.org (hongweipeng)
Date: Sun, 09 Sep 2018 16:35:44 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1536510944.97.0.56676864532.issue34486@psf.upfronthosting.co.za>


hongweipeng <hongweichen8888 at sina.com> added the comment:

It seems to me the problem is related to nested `finally` or `with`, which can't handle signals well.

class Event:
    ...
    def wait(self, timeout=None):
        self._cond.__enter__()
        signaled = self._flag
        if not signaled:
            signaled = self._cond.wait(timeout)
        self._cond.__exit__()
        return signaled


Reducing one layer of nesting can solve this issue,but it can't pass `test` module.

----------
nosy: +hongweipeng

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:03:17 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 09 Sep 2018 17:03:17 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1536512597.29.0.56676864532.issue14156@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

It's been sometime since I looked at this issue.  

The main sticking point is passing unittests, and ensuring that there are no backward compatibility issues.

But, since FileType is a standalone class, anyone could put a corrected version in their own workspace without modifying their stock version.  The 'type' parameter is designed for this kind of flexibility - it accepts any callable, whether a function, or a class with a __call__ method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:04:41 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Sep 2018 17:04:41 +0000
Subject: [issue34614] Builtin `abs(Path)` returns `Path.absolute()`.
In-Reply-To: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>
Message-ID: <1536512681.71.0.56676864532.issue34614@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:05:18 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Sep 2018 17:05:18 +0000
Subject: [issue34614] Builtin `abs(Path)` should return `Path.absolute()`.
In-Reply-To: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>
Message-ID: <1536512718.02.0.56676864532.issue34614@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
title: Builtin `abs(Path)` returns `Path.absolute()`. -> Builtin `abs(Path)` should return `Path.absolute()`.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:11:42 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 09 Sep 2018 17:11:42 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1536513102.97.0.56676864532.issue34486@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

It's not right to replace with statement by manually calling __enter__ and __exit__. If there is any exception after __enter__ and before __exit__, __exit__ method will be skipped. That's not what we want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:13:04 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Sep 2018 17:13:04 +0000
Subject: [issue34614] Builtin `abs(Path)` should return `Path.absolute()`.
In-Reply-To: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>
Message-ID: <1536513184.4.0.56676864532.issue34614@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, thanks for taking the time of proposing this and submitting a PR, but no.  The documentation for `abs()` states:
"""
Return the absolute value of a number. The argument may be an integer or a floating point number. If the argument is a complex number, its magnitude is returned.
"""

This is all about numbers. Not about filesystem paths or any other kind of object. It's true that Path overrides the "division" operator, but that's an exception meant to make it easy to write a very common operation on paths (path joining), and because some people felt it looked pleasantly like the standard Unix path separator (it wasn't the initial choice, by the way).  No such argument applies in favour of abs(Path).

Moreover, Path.resolve() is strongly recommended over Path.absolute(), which currently isn't even exposed in the docs (though it seems that doesn't prevent people from actually using it ;-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:13:15 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Sep 2018 17:13:15 +0000
Subject: [issue34614] Builtin `abs(Path)` should return `Path.absolute()`.
In-Reply-To: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>
Message-ID: <1536513195.07.0.56676864532.issue34614@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:19:46 2018
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 09 Sep 2018 17:19:46 +0000
Subject: [issue34614] Builtin `abs(Path)` should return `Path.absolute()`.
In-Reply-To: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>
Message-ID: <1536513586.67.0.56676864532.issue34614@psf.upfronthosting.co.za>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

That all makes sense. Thanks for the quick response!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34614>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:47:14 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sun, 09 Sep 2018 17:47:14 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1536515234.48.0.56676864532.issue12733@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/issue12733>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:47:15 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Sun, 09 Sep 2018 17:47:15 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1536515235.97.0.56676864532.issue34486@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

To bring in analogy: C# has lock statement that allow to run a block of code holding a mutual-exclusion lock on some object. 
```
lock(o) 
{  
}
```
is compiled as 
```
object _lock = o;
bool _lockTaken = false;
try
{
   System.Threading.Monitor.Enter(_lock, out _lockTaken);
   ...
}
finally 
{
   if (_lockTaken) 
   {
      System.Threading.Monitor.Exit(_lock);
   }
}
```
In C# System.ThreadAbortException can be raised in arbitrary point in code and yet lock statement needs to to enforce the invariant "if lock is taken it will be released". In order to do so:
- lock acquisition is performed inside the try block, as a side effect it sets the value of '_lockTaken' passed as out parameter - these two actions are performed atomically and cannot be interrupted by the asynchronous exception
- lock is released in finally block only if lock was previously taken. Also finally blocks in .NET has a property that they cannot be interrupted by asynchronous exceptions so call to Monitor.Exit is guaranteed to be run if control flow has entered matching try block.

I feel that something similar can be used to solve this issue as well. Discussions for issue29988 has already mentioned adding special semantic to __enter__/__exit__ methods or marking bytecode ranges as atomic to make sure that they are not interrupted. While the former case is specific to with statements, the latter one can probably be generalized to support finally blocks as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Sun Sep  9 13:47:32 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sun, 09 Sep 2018 17:47:32 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1536515252.41.0.56676864532.issue30717@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/issue30717>
_______________________________________

From report at bugs.python.org  Sun Sep  9 15:02:37 2018
From: report at bugs.python.org (Kay Hayen)
Date: Sun, 09 Sep 2018 19:02:37 +0000
Subject: [issue34615] subprocess.call wrong exit code
Message-ID: <1536519757.93.0.56676864532.issue34615@psf.upfronthosting.co.za>


New submission from Kay Hayen <kay.hayen at gmail.com>:

Hello there,

I am probably confusing myself. I am using this kind of code in Nuitka to emulate "os.execl" on Windows, and so far it never let me down:

            r = subprocess.call(
                args,
                shell = False
            )

            print (r, args)

            sys.exit(r)

When i execute my tests with Nuitka and Python 3.6 and everything before, this gives:

1 ['test_call.exe']
1 ['C:\\Python36_32\\python.exe', '-S', '..\\..\\nuitka\\__main__.py', '--run', 'test/test_call.py']

And with python 3.7 it gives:

0 ['test_call.exe']
0 ['C:\\Python37_32\\python.exe', '-S', '..\\..\\nuitka\\__main__.py', '--run', 'test/test_call.py']

So I am in Nuitka re-executing itself without the site module, and then immediately the created binary. For 3.7 it doesn't give me an error. I manually confirmed that "test_call.exe" indeed gives error code 1 as well, in both bash and cmd.exe, but it is not seen in the return value. Checking existing issues, I didn't find any hint at all, how this can be. I added "shell = False" to make it clear that no "cmd.exe" should be used, for which there had been issues.

I also confirmed, by adding a exit(27), that if I simulate that "test_call.exe" gave 27, rather then 0, then that one is detected by the exec, so what could be going on here. But I am also sure I don't confuse binaries or so, plus it's working as expected in other Python versions than 3.7.0 here.

This happens with 64 bits too, I am only citing 32 bits. And it is happening with just about every compiled unit test that gives an error exit, where otherwise e.g. tests that check for error exits to be the case work nicely.

Thanks for any help or direction you can give me there. I am at loss.

Yours,
Kay

----------
components: Windows
messages: 324897
nosy: kayhayen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess.call wrong exit code
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34615>
_______________________________________

From report at bugs.python.org  Sun Sep  9 15:05:34 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 09 Sep 2018 19:05:34 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1536519934.38.0.56676864532.issue17781@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

After 2.5 years without response, I think the answer is probably "no" :)

----------
resolution:  -> fixed
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Sun Sep  9 15:10:45 2018
From: report at bugs.python.org (Kay Hayen)
Date: Sun, 09 Sep 2018 19:10:45 +0000
Subject: [issue34615] subprocess.call wrong exit code
In-Reply-To: <1536519757.93.0.56676864532.issue34615@psf.upfronthosting.co.za>
Message-ID: <1536520245.61.0.56676864532.issue34615@psf.upfronthosting.co.za>


Kay Hayen <kay.hayen at gmail.com> added the comment:

I think that the whole reason I was doing this, is because with "os.execl" on Windows, the exit code was always lost, but of course it is very important and "subprocess.call" promises to return it. 

I just tried if 3.7 has any better exit code handling right there for "os.execl", but apparently it's not the case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34615>
_______________________________________

From report at bugs.python.org  Sun Sep  9 17:57:12 2018
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sun, 09 Sep 2018 21:57:12 +0000
Subject: [issue34616] implement "Async exec"
Message-ID: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>


New submission from Matthias Bussonnier <bussonniermatthias at gmail.com>:

Hi, 

This is an issue, prompted by twitter (https://twitter.com/Mbussonn/status/1038866329971961859) and by the imminent release of IPython 7.0 that provides an async REPL to discuss the introducion of something I'll call "Async exec", the exact form can vary, but I believe the name si relatively self explanatory. 

The short description would be to allow something akin to `exec` but for asynchronous code. Typically for one to be able to write an async-repl in the generic sens that is not say not obviously liked to asyncio.

For example IPython 7.0 (current master branch) allow the following:

```

In [1]: import asyncio, trio, curio

In [2]: await asyncio.sleep(0)

In [3]: %autoawait trio

In [4]: await trio.sleep(0)

In [5]: %autoawait curio

In [6]: await curio.sleep(0)
Out[6]: 30980.70591396
```


Sleep is here and example, but you can play with aoihttp, asks, and other library and it "just works". Alternatively when using IPython via Jupyter, you can also schedule background tasks that will execute in the currently running loop. 

To reach this, we had to work around a large number of roadblock, and there is a number of missing pieces (or things especially prevented) in core Python we had to work around. To see how we did that see https://github.com/ipython/ipython/pull/11265

The core being if we have a block of async code like `await sleep(0)`, we need an asynchronous way to exec it without blocking, hence the proposal for async-exec.

During the development and test of the above feature of IPython here are some of the challenges we got with top-level async code. 

1) top-level async is invalid syntax. 

It make sens for a module for this to be invalid syntax, but not in a repl.
Since Python 3.7 we can (at least) compile it to AST, but not to bytecode.

2) It would also be extremely convenient to have a util function to tell you whether what you just compiled need to be ran async or not, from Source Code, ast tree, code object. It's surprisingly not trivial to get it always right.

So far in IPython we have to carry-over and recompute whether to actually run the compiled byte code in classical `exec` or our pseudo async-exec. You may think that `await exec()` always cover the case, but when you are already running under asyncio, you may want to tell user "no you can't run async code", and use the normal `exec` path.


3) Have  distinction in this `async exec`/`compile` between "I am compiling a module", currently `exec` mode for both exec and compile, and a "I'm compiling a _multiline_ interactive statement".

4) Not be coupled to a specific async library.

Allow new AIO library like trio/curio/... to use this.

Note that despite both using IPython, the above cover 2 use cases. 
- Terminal IPython were the loop is started/stopped between each user input. 
- Notebook kernel/Jupyter IPython where the loop is already running and task/user code can be process in background w/o pausing the loop. 

AFAICT, this would also be of potential use for other REPL (Xonsh, Bpython).

I'm happy to give more details, but I think that's a enough of a broad overview, as we should be releasing this in IPython in a few days/week, we will likely have further feedback from a wider range of users that can inform the design.

----------
components: Interpreter Core
messages: 324900
nosy: mbussonn
priority: normal
severity: normal
status: open
title: implement "Async exec"
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34616>
_______________________________________

From report at bugs.python.org  Sun Sep  9 17:59:21 2018
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sun, 09 Sep 2018 21:59:21 +0000
Subject: [issue34616] implement "Async exec"
In-Reply-To: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>
Message-ID: <1536530361.13.0.56676864532.issue34616@psf.upfronthosting.co.za>


Change by Matthias Bussonnier <bussonniermatthias at gmail.com>:


----------
nosy: +minrk, willingc, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34616>
_______________________________________

From report at bugs.python.org  Sun Sep  9 18:21:11 2018
From: report at bugs.python.org (Anees Ahmed)
Date: Sun, 09 Sep 2018 22:21:11 +0000
Subject: [issue34617] socket.recvfrom(): docs should warn about packet
 truncation when bufsize is insufficient
Message-ID: <1536531671.36.0.56676864532.issue34617@psf.upfronthosting.co.za>


New submission from Anees Ahmed <aneesahmedpro at gmail.com>:

When one is receiving UDP packets (socket.SOCK_DGRAM) using:

    socket.recvfrom(bufsize, flags)

the UDP packet payload is truncated if it was too big to fit into the buffer (decided by `bufsize` here).


This is documented in Linux Docs:

    All receive operations return only one packet.  When the packet is
    smaller than the passed buffer, only that much data is returned; when
    it is bigger, the packet is truncated and the MSG_TRUNC flag is set.
    MSG_WAITALL is not supported.

    Source: http://man7.org/linux/man-pages/man7/udp.7.html


This is also documented in Windows Docs:

    For message-oriented sockets, data is extracted from the first enqueued message, up to the size of the buffer specified. If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost. For UDP if the packet received contains no data (empty), the return value from the recvfrom function function is zero.

    Source: https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-recvfrom


** PYTHON DOCS DO NOT WARN ABOUT THIS AT ALL !!! **

The relevant portion of Python Docs is here: https://docs.python.org/3.7/library/socket.html#socket.socket.recvfrom


I, not knowing this simple fact when I started socket programming today, wasted half an hour finding out what was wrong. This is a very important piece of information that MUST be present in the Python Docs, even though it is present at Linux Docs and Windows Docs.


PROPOSED FIX
------------

Include the warning about packet truncation in the docs.

NOTE: I have only pointed out socket.recvfrom(), but there are other related functions too, e.g. socket.recvfrom_into(), which require the same warning in their docs.

----------
assignee: docs at python
components: Documentation
messages: 324901
nosy: Anees Ahmed, docs at python
priority: normal
severity: normal
status: open
title: socket.recvfrom(): docs should warn about packet truncation when bufsize is insufficient
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/issue34617>
_______________________________________

From report at bugs.python.org  Sun Sep  9 19:51:47 2018
From: report at bugs.python.org (Paul Waldorf)
Date: Sun, 09 Sep 2018 23:51:47 +0000
Subject: [issue27869] test failures under Bash on Windows / WSL
In-Reply-To: <1472236837.41.0.811658562373.issue27869@psf.upfronthosting.co.za>
Message-ID: <1536537107.16.0.56676864532.issue27869@psf.upfronthosting.co.za>


Paul Waldorf <paul at dancesafe.org> added the comment:

Thought my experience could be helpful.  My env is varies from @brett.cannon in that I'm running Debian 9 (Stretch) on my WSL, which makes me think that these failures have more to do with WSL than any difference in distros? 

Configured with

./configure --with-pydebug

Tests ran with 

./python -m test -j0 -x test_signal -x test_ssl -v

Both test_signal and test_ssl would hang indefinitely.

364 tests OK.

27 tests failed:
    test_asyncio test_asyncore test_concurrent_futures test_epoll
    test_fcntl test_ftplib test_httplib test_httpservers test_import
    test_io test_mmap test_multiprocessing_fork
    test_multiprocessing_forkserver test_multiprocessing_main_handling
    test_multiprocessing_spawn test_os test_posix test_regrtest
    test_selectors test_socket test_source_encoding test_subprocess
    test_sys test_sysconfig test_syslog test_time test_unicode_file

20 tests skipped:
    test_curses test_devpoll test_gdb test_kqueue test_msilib
    test_ossaudiodev test_smtpnet test_socketserver test_startfile
    test_timeout test_tix test_tk test_ttk_guionly test_urllib2net
    test_urllibnet test_winconsoleio test_winreg test_winsound
    test_xmlrpc_net test_zipfile64

----------
nosy: +paul.waldorf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27869>
_______________________________________

From report at bugs.python.org  Sun Sep  9 20:36:51 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 10 Sep 2018 00:36:51 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536409883.5.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <20180910003642.GT27312@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

For what its worth, I'm +1 with Serhiy that we raise an exception 
on a non-string argument, including the case where the caller forgets to 
provide a reason at all.

I don't think that @skip with no reason was ever intended to work (it 
certainly wasn't documented as working) and as this only effects tests, 
not production code, I don't think we ought to be constrained by "bug 
compatibility" concerns. Fixing broken tests is easier than fixing 
broken production code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34596>
_______________________________________

From report at bugs.python.org  Sun Sep  9 21:58:00 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 10 Sep 2018 01:58:00 +0000
Subject: [issue34618] Encoding error running in subprocess with captured output
Message-ID: <1536544680.03.0.56676864532.issue34618@psf.upfronthosting.co.za>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

When running Python via subprocess with captured output an encoding error occurs attempting to output a Unicode filename.  The same does not happen when just using spawnl().

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, subprocess
>>> sys.stdout.encoding, sys.stdout.errors
('utf-8', 'surrogateescape')
>>> args = ['-u', '-c', "print('taqdir\\\u0634\u0645\u0627\u0631.py')"]
>>> os.spawnl(os.P_WAIT, sys.executable, '"%s"' % sys.executable, *args)
taqdir\????.py
0
>>> subprocess.run([sys.executable, *args], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
CompletedProcess(args=['C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Python36_64\\python.exe', '-u', '-c', "print('taqdir\\????.py')"], returncode=1, stdout=b'Traceback (most recent call last):\r\n  File "<string>", line 1, in <module>\r\n  File "C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Python36_64\\lib\\encodings\\cp1252.py", line 19, in encode\r\n    return codecs.charmap_encode(input,self.errors,encoding_table)[0]\r\nUnicodeEncodeError: \'charmap\' codec can\'t encode characters in position 7-10: character maps to <undefined>\r\n')

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
messages: 324904
nosy: ezio.melotti, jkloth, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Encoding error running in subprocess with captured output
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34618>
_______________________________________

From report at bugs.python.org  Sun Sep  9 21:58:38 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 10 Sep 2018 01:58:38 +0000
Subject: [issue34618] Encoding error running in subprocess with captured output
In-Reply-To: <1536544680.03.0.56676864532.issue34618@psf.upfronthosting.co.za>
Message-ID: <1536544718.63.0.56676864532.issue34618@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Related to issue34421

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34618>
_______________________________________

From report at bugs.python.org  Sun Sep  9 22:56:30 2018
From: report at bugs.python.org (kuri8ive)
Date: Mon, 10 Sep 2018 02:56:30 +0000
Subject: [issue34619] Typo in docs.python.jp
Message-ID: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>


New submission from kuri8ive <1yen.com at gmail.com>:

Typo in https://docs.python.jp/3/tutorial/index.html
"Python Web ???(htts://www.python.org)"
should be
"Python Web ???(https://www.python.org) "

----------
assignee: docs at python
components: Documentation
messages: 324906
nosy: docs at python, kuri8ive
priority: normal
severity: normal
status: open
title: Typo in docs.python.jp
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34619>
_______________________________________

From report at bugs.python.org  Sun Sep  9 22:57:57 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 10 Sep 2018 02:57:57 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1536548277.78.0.56676864532.issue34421@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

For pip, in call_subprocess() (given here in rough pseudo-code)

is_python = (cmd[0] == sys.executable)
kwds = {}
if is_python:
    env['PYTHONIOENCODING'] = 'utf8'
    kwds['encoding'] = 'utf8'
proc = Popen(..., **kwds)
.
.
.
if stdout is not None:
    while True:
        line = proc.stdout.readline()
        # When running Python, the output is already Unicode
        if not is_python:
            line = console_to_str(line)
        if not line:
            break


Hopefully, there is enough context to figure out the exact placement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep  9 23:30:56 2018
From: report at bugs.python.org (shashank)
Date: Mon, 10 Sep 2018 03:30:56 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1536550256.62.0.56676864532.issue21109@psf.upfronthosting.co.za>


shashank <shanx.shashank at gmail.com> added the comment:

A. Regrading Jakub's tests, I suppose the changes needed are to 
for every name in tar
i) find reasonable occurrence of symlink's name and replace it with smylink's linkname
ii) convert it to normal path and then check for relative / absolute paths

B. Jakub, are your tests exhaustive or there maybe some corner cases missing? I think we don't have tests for hardlinks, yet. Also I think, we will need tests for CHRTYPE, FIFOTYPE and BLKTYPE of tar's typeflag[0]


[0] http://www.gnu.org/software/tar/manual/html_node/Standard.html

----------
nosy: +shanxS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Sun Sep  9 23:46:24 2018
From: report at bugs.python.org (Martin Hosken)
Date: Mon, 10 Sep 2018 03:46:24 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536551184.54.0.56676864532.issue34600@psf.upfronthosting.co.za>


Martin Hosken <martin_hosken at sil.org> added the comment:

Sorry. This test is rather long because it is 3 tests:

from __future__ import print_function
import sys
import xml.etree.ElementTree as et
import xml.etree.cElementTree as cet
from io import StringIO

teststr = u"""<?xml version="1"?>
<root>
    <child>
        Hello <!-- Greeting --> World
    </child>
</root>"""
testf = StringIO(teststr)

if len(sys.argv) >= 2 and 'a' in sys.argv[1]:
    testf.seek(0)
    for event, elem in et.iterparse(testf, events=["end", "comment"]):
        if event == 'end':
            print(elem.tag + ": " + str(elem.text))
        elif event == 'comment':
            print("comment: " + elem.text)

if len(sys.argv) < 2 or 'b' in sys.argv[1]:
    testf.seek(0)
    def doComment(data):
        parser.parser.StartElementHandler("!--", ('text', data))
        parser.parser.EndElementHandler("!--")
    parser = et.XMLParser()
    parser.parser.CommentHandler = doComment
    for event, elem in et.iterparse(testf, parser=parser):
        if hasattr(elem, 'text'):
            print(elem.tag + ": " + str(elem.text))
        else:
            print(elem.tag + ": " + elem.get('text', ""))

if len(sys.argv) < 2 or 'c' in sys.argv[1] or 'd' in sys.argv[1]:
    testf.seek(0)
    useet = et if len(sys.argv) < 2 or 'c' in sys.argv[1] else cet
    class CommentingTb(useet.TreeBuilder):
        def __init__(self):
            self.parser = None
        def comment(self, data):
            self.parser.parser.StartElementHandler("!--", ('text', data))
            self.parser.parser.EndElementHandler("!--")
    tb = CommentingTb()
    parser = useet.XMLParser(target=tb)
    tb.parser = parser
    kw = {'parser': parser} if len(sys.argv) < 2 or 'c' in sys.argv[1] else {}
    for event, elem in useet.iterparse(testf, **kw):
        if hasattr(elem, 'text'):
            print(elem.tag + ": " + str(elem.text))
        else:
            print(elem.tag + ": " + elem.get('text', ""))

Test 'a' is how I would like to write the solution to my problem. Not sure why 'comment' isn't supported by iterparse directly, but hey.

Test 'b' is how I solved in it python2

Test 'c' is how I would have to solve it in python3 if it worked

Test 'd' is the same as 'c' but uses cElementTree rather than ElementTree.

Results:

Success output for a test is:
```
!--: None
child: 
        Hello 
root: 
    
```

Python2:
a    Fails (obviously)
b    Succeeds
c    Succeeds
d    Fails: can't inherit from cElementTree.TreeBuilder

Python3:
a    Fails (obviously)
b    Fails: XMLParser has no attribute 'parser'
c    Fails: event handling only supported for ElementTree.TreeBuilder targets
d    Fails: Gives output but no initial comment component (line 1)

The key failure here is Python3 'c'. This is what stops any hope of comment handling using the et.XMLParser. The only way I could get around it was to use my own copy from the source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34600>
_______________________________________

From report at bugs.python.org  Sun Sep  9 23:51:39 2018
From: report at bugs.python.org (Martin Hosken)
Date: Mon, 10 Sep 2018 03:51:39 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536551499.12.0.56676864532.issue34600@psf.upfronthosting.co.za>


Martin Hosken <martin_hosken at sil.org> added the comment:

Blast. Bugs. Sorry. Missing superclass init call in CommentingTb. I enclose the whole thing again to save editing. Also fixes comment output to give text.

from __future__ import print_function
import sys
import xml.etree.ElementTree as et
import xml.etree.cElementTree as cet
from io import StringIO

teststr = u"""<?xml version="1"?>
<root>
    <child>
        Hello <!-- Greeting --> World
    </child>
</root>"""
testf = StringIO(teststr)

if len(sys.argv) >= 2 and 'a' in sys.argv[1]:
    testf.seek(0)
    for event, elem in et.iterparse(testf, events=["end", "comment"]):
        if event == 'end':
            print(elem.tag + ": " + str(elem.text))
        elif event == 'comment':
            print("comment: " + elem.text)

if len(sys.argv) < 2 or 'b' in sys.argv[1]:
    testf.seek(0)
    def doComment(data):
        parser.parser.StartElementHandler("!--", ('text', data))
        parser.parser.EndElementHandler("!--")
    parser = et.XMLParser()
    parser.parser.CommentHandler = doComment
    for event, elem in et.iterparse(testf, parser=parser):
        if elem.tag == "!--":
            print(elem.tag + ": " + elem.get('text', ""))
        else:
            print(elem.tag + ": " + str(elem.text))

if len(sys.argv) < 2 or 'c' in sys.argv[1] or 'd' in sys.argv[1]:
    testf.seek(0)
    useet = et if len(sys.argv) < 2 or 'c' in sys.argv[1] else cet
    class CommentingTb(useet.TreeBuilder):
        def __init__(self):
            useet.TreeBuilder.__init__(self)
            self.parser = None
        def comment(self, data):
            self.parser.parser.StartElementHandler("!--", ('text', data))
            self.parser.parser.EndElementHandler("!--")
    tb = CommentingTb()
    parser = useet.XMLParser(target=tb)
    tb.parser = parser
    kw = {'parser': parser} if len(sys.argv) < 2 or 'c' in sys.argv[1] else {}
    for event, elem in useet.iterparse(testf, **kw):
        if elem.tag == "!--":
            print(elem.tag + ": " + elem.get('text', ""))
        else:
            print(elem.tag + ": " + str(elem.text))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34600>
_______________________________________

From report at bugs.python.org  Sun Sep  9 23:55:57 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 10 Sep 2018 03:55:57 +0000
Subject: [issue34618] Encoding error running in subprocess with captured output
In-Reply-To: <1536544680.03.0.56676864532.issue34618@psf.upfronthosting.co.za>
Message-ID: <1536551757.15.0.56676864532.issue34618@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

The interpreter uses the system ANSI codepage for non-console files. In your case this is codepage 1252. In my current setup I can't reproduce this issue since I'm using the new (beta) support in Windows 10 to configure the ANSI codepage as UTF-8 (65001).

You can force standard I/O to use UTF-8 by setting the environment variable PYTHONIOENCODING. Also, if you want the CompletedProcess stdout decoded as text, in 3.6+ you can pass the parameter `encoding='utf-8'`. For example:

    environ = os.environ.copy()
    environ['PYTHONIOENCODING'] = 'utf-8'
    p = subprocess.run([sys.executable, *args], stdout=subprocess.PIPE, stderr=subprocess.STDOUT, env=environ, encoding='utf-8')
    print(p.stdout)

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34618>
_______________________________________

From report at bugs.python.org  Mon Sep 10 00:06:37 2018
From: report at bugs.python.org (hongweipeng)
Date: Mon, 10 Sep 2018 04:06:37 +0000
Subject: [issue34475] functools.partial objects have no __qualname__ attribute
In-Reply-To: <1535034359.11.0.56676864532.issue34475@psf.upfronthosting.co.za>
Message-ID: <1536552397.23.0.56676864532.issue34475@psf.upfronthosting.co.za>


hongweipeng <hongweichen8888 at sina.com> added the comment:

the functools.partial returns an instance not fun or cls.using `p.func.__qualname__` may be you want.

----------
nosy: +hongweipeng

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34475>
_______________________________________

From report at bugs.python.org  Mon Sep 10 00:48:47 2018
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 10 Sep 2018 04:48:47 +0000
Subject: [issue34475] functools.partial objects have no __qualname__ attribute
In-Reply-To: <1535034359.11.0.56676864532.issue34475@psf.upfronthosting.co.za>
Message-ID: <1536554927.81.0.56676864532.issue34475@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Using p.func would name the function passed to functools.partial() rather than the partial object itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34475>
_______________________________________

From report at bugs.python.org  Mon Sep 10 02:09:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Sep 2018 06:09:56 +0000
Subject: [issue34475] functools.partial objects have no __qualname__ attribute
In-Reply-To: <1535034359.11.0.56676864532.issue34475@psf.upfronthosting.co.za>
Message-ID: <1536559796.76.0.56676864532.issue34475@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34475>
_______________________________________

From report at bugs.python.org  Mon Sep 10 02:10:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Sep 2018 06:10:58 +0000
Subject: [issue26093] __qualname__ different when calling generator object w/
 functions.partial
In-Reply-To: <1452638028.1.0.595104762218.issue26093@psf.upfronthosting.co.za>
Message-ID: <1536559858.79.0.56676864532.issue26093@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26093>
_______________________________________

From report at bugs.python.org  Mon Sep 10 02:17:01 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Sep 2018 06:17:01 +0000
Subject: [issue34475] functools.partial objects have no __qualname__ attribute
In-Reply-To: <1535034359.11.0.56676864532.issue34475@psf.upfronthosting.co.za>
Message-ID: <1536560221.91.0.56676864532.issue34475@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems __repr__ call to partial object has qualname but I think it always returns "partial". Ref : https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/functools.py#L276

>>> import functools
>>> int.__qualname__
'int'
>>> p = functools.partial(int)
>>> p.__qualname__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'functools.partial' object has no attribute '__qualname__'
>>> p
functools.partial(<class 'int'>)


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34475>
_______________________________________

From report at bugs.python.org  Mon Sep 10 02:17:18 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 10 Sep 2018 06:17:18 +0000
Subject: [issue34616] implement "Async exec"
In-Reply-To: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>
Message-ID: <1536560238.37.0.56676864532.issue34616@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

I think the first thing is to add async "modes" to compile: in particular "async-exec" and "async-single". These would be like the current "exec" and "single" modes respectively, except that they act like the code is inside an "async def", so "await" is allowed, and executing the resulting code object produces a coroutine object that has to be iterated to actually run the code.

I guess we might want "async-eval" too just for completeness, though I'm not currently aware of any use cases for that.

A utility to check whether an AST requires async mode should be fairly straightforward. So if you want to choose on the fly, you would do:

1. ast = compile(source, filename, "async-exec", ast.PyCF_ONLY_AST)
2. use a utility check whether 'ast' contains any top-level 'await'/'async with'/'async for'
3. if so, create bytecode with compile(ast, filename, "async-exec"). If not, create bytecode with compile(ast, filename, "exec").

Once you have a code object, I think it's too late: if you use "async-exec" mode to compile a code object that doesn't actually use 'await', then it should still return a coroutine object that needs iterating, etc., just like an 'async def' that has no 'await' in it. So if you want to do this check, the AST phase is the time to do it. Maybe ast.is_ast_async(ast_obj)?

> Have distinction in this `async exec`/`compile` between "I am compiling a module", currently `exec` mode for both exec and compile, and a "I'm compiling a _multiline_ interactive statement".


This seems like a separate problem from the async stuff... I'm curious to hear how what distinction you want to make between 'exec' and a new 'multi-single' (?) mode, but maybe that should be a new issue?

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34616>
_______________________________________

From report at bugs.python.org  Mon Sep 10 02:26:36 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Sep 2018 06:26:36 +0000
Subject: [issue34619] Typo in docs.python.jp
In-Reply-To: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>
Message-ID: <1536560796.18.0.56676864532.issue34619@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. I think translations use Github issues (https://github.com/python/python-docs-ja/issues). https://www.python.org/dev/peps/pep-0545/#language-team tells me "Redirect issues posted on b.p.o to the correct GitHub issue tracker for the language." . I think filing an issue there will help. In case you want to raise a PR the relevant line is available at https://github.com/python/python-docs-ja/blob/29fb57f236ad2230d1aba88bef114633f47a19f9/tutorial/index.po#L44

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34619>
_______________________________________

From report at bugs.python.org  Mon Sep 10 02:30:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Sep 2018 06:30:18 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536561018.35.0.56676864532.issue34600@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34600>
_______________________________________

From report at bugs.python.org  Mon Sep 10 03:50:25 2018
From: report at bugs.python.org (MatteoL)
Date: Mon, 10 Sep 2018 07:50:25 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1536565825.88.0.56676864532.issue34603@psf.upfronthosting.co.za>


Change by MatteoL <mlovato at gmail.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Mon Sep 10 06:13:09 2018
From: report at bugs.python.org (chaen)
Date: Mon, 10 Sep 2018 10:13:09 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1536574389.83.0.56676864532.issue18233@psf.upfronthosting.co.za>


chaen <christophe.haen at cern.ch> added the comment:

There is another very valid use case which is even described by an RFC: https://www.ietf.org/rfc/rfc3820.txt

And openssl supports this RFC. 

These proxy certificates are heavily used in the world of high energy physics computing, and having the get_peer_cert_chain exposed in python would allow to use standard tools. 

And any hope this would also be backported to the python 2.7 branch ?

----------
nosy: +chaen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Mon Sep 10 07:57:43 2018
From: report at bugs.python.org (Dan Snider)
Date: Mon, 10 Sep 2018 11:57:43 +0000
Subject: [issue34620] Octal byte literals with a decimal value > 255 are
 silently truncated
Message-ID: <1536580663.47.0.56676864532.issue34620@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

>>> b'\542\571\564\545\563', b'\142\171\164\145\163'
(b'bytes', b'bytes')

All the C compilers I know of at the very least generate a warning when one tries to assign an oct literal >= '\400' to a byte. And that's because it's nonsense when bytes have 8 bits, even more so for an 8 bit byte string.

The literal value:

>>> b'\542\571\564\545\563'

should be identical to:

>>> bytes([0o542, 0o571, 0o564, 0o545, 0o563])

That obviously doesn't work:

>>> b'\542\571\564\545\563' == bytes([0o542, 0o571, 0o564, 0o545, 0o563])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: bytes must be in range(0, 256)

This is on Windows/Intel. I haven't looked at the parser in much detail, but I wonder what would happen on a big-endian system?

----------
components: Interpreter Core, Windows
messages: 324918
nosy: bup, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Octal byte literals with a decimal value > 255 are silently truncated
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34620>
_______________________________________

From report at bugs.python.org  Mon Sep 10 08:16:57 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 12:16:57 +0000
Subject: [issue34621] uuid.UUID objects can't be unpickled in older Python
 versions (<3.7)
Message-ID: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za>


New submission from Tal Einat <taleinat at gmail.com>:

This affects only 3.7, where the new SafeUUID enum was introduced.

This was fixed on the master branch (3.8) while implementing issue30977.

Fixing this should simply require defining similar __getstate__ and __setstate__ methods as in 3.8.

----------
components: Library (Lib)
messages: 324919
nosy: serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: uuid.UUID objects can't be unpickled in older Python versions (<3.7)
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34621>
_______________________________________

From report at bugs.python.org  Mon Sep 10 08:17:40 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 12:17:40 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>
Message-ID: <1536581860.61.0.56676864532.issue22807@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

The fix for issue30977 did fix the unpickling in older versions. It was only applied to the master (i.e. 3.8) branch, though.

I've created issue34621 to deal with this separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22807>
_______________________________________

From report at bugs.python.org  Mon Sep 10 08:26:50 2018
From: report at bugs.python.org (Julien Malard)
Date: Mon, 10 Sep 2018 12:26:50 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1536548277.78.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <YTOPR01MB0283655FB018B02502D8B4C6D9050@YTOPR01MB0283.CANPRD01.PROD.OUTLOOK.COM>


Julien Malard <julien.malard at mail.mcgill.ca> added the comment:

Thanks! Will give it a try and reference this conversation here as background.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Mon Sep 10 08:36:41 2018
From: report at bugs.python.org (Ben Spiller)
Date: Mon, 10 Sep 2018 12:36:41 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
 well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1536583001.54.0.56676864532.issue5166@psf.upfronthosting.co.za>


Ben Spiller <ben.spiller at softwareag.com> added the comment:

Hi it's been a few years now since this was reported and it's still a problem, any chance of a fix for this? The API gives the impression that if you pass python strings to the XML API then the library will generate valid XML. It takes care of the charset/encoding and entity escaping aspects of XML generation so would be logical for it to in some way take care of control characters too - especially as silently generating unparseable XML is a somewhat dangerous failure mode. 

I think there's a strong case for some built-in functionality to replace/ignore the control characters (perhaps as a configurable option, in case of performance worries) rather than just throwing an exception, since it's very common to have an arbitrary string generated by some other program or user input that needs to be written into an XML file (and a lot less common to be 100% sure in all cases what characters your string might contain). For those common use cases, the current situation where every python developer needs to implement their own workaround to sanitize strings isn't ideal, especially as it's not trivial to get it right and likely a lot of the community who end up 'rolling their own' are getting in wrong in some way. 

[On the other hand if you guys decide this really isn't going to be fixed, then at the very least I'd suggest that the API documentation should prominently state that it is up to the users of these libraries to implement their own sanitization of control characters, since I'm sure none of us want people using python to end up with buggy applications]

----------
nosy: +benspiller
versions: +Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Mon Sep 10 08:53:14 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 12:53:14 +0000
Subject: [issue34621] uuid.UUID objects can't be unpickled in older Python
 versions (<3.7)
In-Reply-To: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za>
Message-ID: <1536583994.85.0.56676864532.issue34621@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +8585
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34621>
_______________________________________

From report at bugs.python.org  Mon Sep 10 08:53:14 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 12:53:14 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536583994.94.0.665841612001.issue30977@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8586

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30977>
_______________________________________

From report at bugs.python.org  Mon Sep 10 09:11:09 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 13:11:09 +0000
Subject: [issue30977] reduce uuid.UUID() memory footprint
In-Reply-To: <1500570928.48.0.991848922118.issue30977@psf.upfronthosting.co.za>
Message-ID: <1536585069.07.0.56676864532.issue30977@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 54752533b2ed1c898ffe5ec2e795c6910ee46a39 by Tal Einat in branch 'master':
bpo-30977: rework code changes according to post-merge code review (GH-9106)
https://github.com/python/cpython/commit/54752533b2ed1c898ffe5ec2e795c6910ee46a39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30977>
_______________________________________

From report at bugs.python.org  Mon Sep 10 09:37:26 2018
From: report at bugs.python.org (William Grzybowski)
Date: Mon, 10 Sep 2018 13:37:26 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536586646.29.0.56676864532.issue34604@psf.upfronthosting.co.za>


William Grzybowski <william88 at gmail.com> added the comment:

I can do it if you feel the need.
Can this same issue be used? Will the new PR require another NEWS entry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34604>
_______________________________________

From report at bugs.python.org  Mon Sep 10 10:03:26 2018
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 10 Sep 2018 14:03:26 +0000
Subject: [issue34616] implement "Async exec"
In-Reply-To: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>
Message-ID: <1536588206.41.0.56676864532.issue34616@psf.upfronthosting.co.za>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

> I think the first thing is to add async "modes" to compile: in particular "async-exec" and "async-single". These would be like the current "exec" and "single" modes respectively, except that they act like the code is inside an "async def", so "await" is allowed, and executing the resulting code object produces a coroutine object that has to be iterated to actually run the code.

> This seems like a separate problem from the async stuff... I'm curious to hear how what distinction you want to make between 'exec' and a new 'multi-single' (?) mode, but maybe that should be a new issue?

Mell, in classical `exec` there is always a tension between "this is for a module" and "this is for REPL". We saw that close to 3.7 release where strings literal were moved into the AST Module `docstring` attribute.

In IPython[1] we also have to dance to trigger the display hook in a multi-line context by executing each top-level node one by one. So while we are designing a new `async-exec` while not tackle that issue at the same time and cover both use case ? That should let one category of user do the optimization they wish and get a `Module` object, without being slow down by the other. 

1: https://github.com/ipython/ipython/blob/869480ed70944ca70ad9ed70779b9c3e4320adb7/IPython/core/interactiveshell.py#L3179-L3190

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34616>
_______________________________________

From report at bugs.python.org  Mon Sep 10 11:43:17 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 15:43:17 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536594197.11.0.56676864532.issue34588@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d545869d084e70d4838310e79b52a25a72a1ca56 by Benjamin Peterson in branch 'master':
bpo-34588: Fix an off-by-one error in traceback formatting. (GH-9077)
https://github.com/python/cpython/commit/d545869d084e70d4838310e79b52a25a72a1ca56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34588>
_______________________________________

From report at bugs.python.org  Mon Sep 10 11:43:27 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 15:43:27 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536594207.58.0.56676864532.issue34588@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8587

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34588>
_______________________________________

From report at bugs.python.org  Mon Sep 10 11:43:35 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 15:43:35 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536594215.77.0.56676864532.issue34588@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8588

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34588>
_______________________________________

From report at bugs.python.org  Mon Sep 10 11:47:36 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 15:47:36 +0000
Subject: [issue34621] uuid.UUID objects can't be unpickled in older Python
 versions (<3.7)
In-Reply-To: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za>
Message-ID: <1536594456.15.0.56676864532.issue34621@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset d53f1cabe8837697df4acb70c9c6537461b5eeda by Tal Einat in branch '3.7':
[3.7] bpo-34621: fix uuid.UUID (un)pickling compatbility with older Python versions (<3.7) (GH-9133)
https://github.com/python/cpython/commit/d53f1cabe8837697df4acb70c9c6537461b5eeda


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34621>
_______________________________________

From report at bugs.python.org  Mon Sep 10 11:47:50 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 15:47:50 +0000
Subject: [issue34621] uuid.UUID objects can't be unpickled in older Python
 versions (<3.7)
In-Reply-To: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za>
Message-ID: <1536594470.44.0.56676864532.issue34621@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34621>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:00:13 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 16:00:13 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536595213.06.0.56676864532.issue34588@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 49020174305ca3dc90a811b03a05f44873297c61 by Miss Islington (bot) in branch '3.7':
bpo-34588: Fix an off-by-one error in traceback formatting. (GH-9077)
https://github.com/python/cpython/commit/49020174305ca3dc90a811b03a05f44873297c61


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34588>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:01:12 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 16:01:12 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536595272.05.0.56676864532.issue34588@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34588>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:05:49 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 16:05:49 +0000
Subject: [issue34598] How to fix? Error in Kali linux python 2.7 - Collecting
 pip From cffi callback <function _verify_callback at 0x7f9b12e56050>:
 Traceback (most recent call last): File
 "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in wrapper
In-Reply-To: <1536250143.3.0.56676864532.issue34598@psf.upfronthosting.co.za>
Message-ID: <1536595549.38.0.56676864532.issue34598@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This seems likely to be a bug in the Kali distribution.

----------
nosy: +benjamin.peterson
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34598>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:07:31 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 16:07:31 +0000
Subject: [issue24696] Don't use None as sentinel for traceback
In-Reply-To: <1437663140.05.0.49769295759.issue24696@psf.upfronthosting.co.za>
Message-ID: <1536595651.76.0.56676864532.issue24696@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

3.4 is out of bugfix support.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24696>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:10:14 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 16:10:14 +0000
Subject: [issue34068] traceback.clear_frames(): Objects/typeobject.c:3086:
 _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.
In-Reply-To: <1531031682.19.0.56676864532.issue34068@psf.upfronthosting.co.za>
Message-ID: <1536595814.7.0.56676864532.issue34068@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34068>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:10:25 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 16:10:25 +0000
Subject: [issue34588] traceback formatting can drop a frame
In-Reply-To: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>
Message-ID: <1536595825.51.0.56676864532.issue34588@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset afb25bc2b5767ac3a83bc8c4d2826e8fdcb6b0e7 by Miss Islington (bot) in branch '3.6':
bpo-34588: Fix an off-by-one error in traceback formatting. (GH-9077)
https://github.com/python/cpython/commit/afb25bc2b5767ac3a83bc8c4d2826e8fdcb6b0e7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34588>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:14:11 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 16:14:11 +0000
Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong
 traceback
In-Reply-To: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za>
Message-ID: <1536596051.13.0.56676864532.issue23354@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We would need to know what test.py was actually doing to fix this bug.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23354>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:39:54 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 16:39:54 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1536597594.13.0.56676864532.issue34282@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset c0d63bf73b35df374e6e66c08b0e297fb828d744 by Ethan Furman (orlnub123) in branch '3.7':
[3.7] bpo-34282: Fix Enum._convert method shadowing members named _convert (GH-9034)
https://github.com/python/cpython/commit/c0d63bf73b35df374e6e66c08b0e297fb828d744


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34282>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:41:16 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 16:41:16 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536597676.76.0.56676864532.issue23855@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f51a46631f8dcca596c08a934a766da9afe93c06 by Miss Islington (bot) in branch '2.7':
bpo-23855: Add missing NULL checks for malloc() in _msi.c (GH-9038)
https://github.com/python/cpython/commit/f51a46631f8dcca596c08a934a766da9afe93c06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23855>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:41:36 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 16:41:36 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536597696.22.0.56676864532.issue23855@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8a0c254fdd68cfafede168356fc5c5c3e372bc3f by Miss Islington (bot) in branch '3.6':
bpo-23855: Add missing NULL checks for malloc() in _msi.c (GH-9038)
https://github.com/python/cpython/commit/8a0c254fdd68cfafede168356fc5c5c3e372bc3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23855>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:42:56 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Sep 2018 16:42:56 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
 using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1536597776.23.0.56676864532.issue6531@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:44:02 2018
From: report at bugs.python.org (SoniEx2)
Date: Mon, 10 Sep 2018 16:44:02 +0000
Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong
 traceback
In-Reply-To: <1536596051.13.0.56676864532.issue23354@psf.upfronthosting.co.za>
Message-ID: <CA+-cKyPLXjBDz5CjnwBpnQ2K=1uK2Q0+E6eb9OH1jz_9B5X9iA@mail.gmail.com>


SoniEx2 <fakedme at gmail.com> added the comment:

test.py is the result of `"\n" * (2**31) + "assert False"`, written to a
file.

On Mon, Sep 10, 2018, 13:14 Benjamin Peterson <report at bugs.python.org>
wrote:

>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> We would need to know what test.py was actually doing to fix this bug.
>
> ----------
> resolution:  -> works for me
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue23354>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23354>
_______________________________________

From report at bugs.python.org  Mon Sep 10 12:45:53 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 16:45:53 +0000
Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong
 traceback
In-Reply-To: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za>
Message-ID: <1536597953.13.0.56676864532.issue23354@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23354>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:02:36 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Sep 2018 17:02:36 +0000
Subject: [issue26502] traceback.extract_tb breaks compatibility by returning
 FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536598956.36.0.56676864532.issue26502@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 9797b7ae4496627836c55333765e10201a9840e3 by Petr Viktorin (Berker Peksag) in branch 'master':
bpo-26502: Implement FrameSummary.__len__() (GH-8632)
https://github.com/python/cpython/commit/9797b7ae4496627836c55333765e10201a9840e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26502>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:29:28 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Mon, 10 Sep 2018 17:29:28 +0000
Subject: [issue34580] sqlite doc: clarify the scope of the context manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536600568.37.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <bpo at chown.me> added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34580>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:29:46 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 17:29:46 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536600586.34.0.56676864532.issue34525@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 78deb7f33227972987722bc3fed5bcb45fae869e by Benjamin Peterson (Sebastian Rittau) in branch 'master':
closes bpo-34525: Fix smtplib's authobject() documentation (GH-8965)
https://github.com/python/cpython/commit/78deb7f33227972987722bc3fed5bcb45fae869e


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:29:55 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 17:29:55 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536600595.47.0.56676864532.issue34525@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8589

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:30:05 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 17:30:05 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536600605.21.0.56676864532.issue34525@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8590

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:50:48 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 17:50:48 +0000
Subject: [issue34487] enum _sunder_ names mix metaclass and enum class
 attributes
In-Reply-To: <1535121871.11.0.56676864532.issue34487@psf.upfronthosting.co.za>
Message-ID: <1536601848.74.0.56676864532.issue34487@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34487>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:54:46 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Sep 2018 17:54:46 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536602086.84.0.56676864532.issue31577@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

We definitely can't make that change to PyNumber_Divmod in 3.7 at this point, I'm sure someone somewhere is relying on being able to get arbitrary information out of their objects with `divmod(crazy_object)`.  I don't know enough math to say whether there could be any legitimate mathematical use for arbitrary return values so I leave it to others to determine whether we could make that consider that change in 3.8 just to clean things up.

I've looked through _datetimemodule.c and I don't see how timedelta.__divmod__ could fail like this, since it actually creates new timedelta objects from its arguments to work from.

----------
nosy: +zach.ware
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Mon Sep 10 13:57:18 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Sep 2018 17:57:18 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536602238.8.0.56676864532.issue31577@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Adding Ned and marking as release blocker as this is a crasher in 3.7.0.

----------
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:10:04 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 10 Sep 2018 18:10:04 +0000
Subject: [issue33604] HMAC default to MD5 marked as to be removed in 3.6
In-Reply-To: <1527014760.1.0.682650639539.issue33604@psf.upfronthosting.co.za>
Message-ID: <1536603004.97.0.56676864532.issue33604@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 51a4743d19abd016f0772a57fb31df7af9220e18 by Gregory P. Smith (Matthias Bussonnier) in branch 'master':
bpo-33604: Remove deprecated HMAC default value marked for removal in 3.8 (GH-7063)
https://github.com/python/cpython/commit/51a4743d19abd016f0772a57fb31df7af9220e18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33604>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:12:24 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 10 Sep 2018 18:12:24 +0000
Subject: [issue33604] HMAC default to MD5 marked as to be removed in 3.6
In-Reply-To: <1527014760.1.0.682650639539.issue33604@psf.upfronthosting.co.za>
Message-ID: <1536603144.99.0.56676864532.issue33604@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
type:  -> behavior
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33604>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:13:17 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 18:13:17 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536603197.62.0.56676864532.issue34525@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 011141f312f11b35ac163d9d52fe48e4bb61a814 by Miss Islington (bot) in branch '3.7':
closes bpo-34525: Fix smtplib's authobject() documentation (GH-8965)
https://github.com/python/cpython/commit/011141f312f11b35ac163d9d52fe48e4bb61a814


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:16:15 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 18:16:15 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536603375.54.0.56676864532.issue34525@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c0db8177dc9a7f79941551576e1faea9724e027d by Miss Islington (bot) in branch '3.6':
closes bpo-34525: Fix smtplib's authobject() documentation (GH-8965)
https://github.com/python/cpython/commit/c0db8177dc9a7f79941551576e1faea9724e027d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:21:09 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 18:21:09 +0000
Subject: [issue33217] x in enum.Flag member is True when x is not a Flag
In-Reply-To: <1522786572.96.0.467229070634.issue33217@psf.upfronthosting.co.za>
Message-ID: <1536603669.1.0.56676864532.issue33217@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 9430652535f88125d8003f342a8884d34885d876 by Ethan Furman (Rahul Jha) in branch 'master':
bpo-33217: Raise TypeError for non-Enum lookups in Enums (GH-6651)
https://github.com/python/cpython/commit/9430652535f88125d8003f342a8884d34885d876


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33217>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:23:04 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Sep 2018 18:23:04 +0000
Subject: [issue34619] Typo in docs.python.jp
In-Reply-To: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>
Message-ID: <1536603784.76.0.56676864532.issue34619@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Karthikeyan is right that translation bugs should be reported on the GitHub project for the translation.

----------
nosy: +brett.cannon
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34619>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:25:18 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 18:25:18 +0000
Subject: [issue33217] x in enum.Flag member is True when x is not a Flag
In-Reply-To: <1522786572.96.0.467229070634.issue33217@psf.upfronthosting.co.za>
Message-ID: <1536603918.9.0.56676864532.issue33217@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thank you, Rahul!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33217>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:30:27 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 18:30:27 +0000
Subject: [issue31801] vars() manipulation encounters problems with Enum
In-Reply-To: <1508199715.37.0.213398074469.issue31801@psf.upfronthosting.co.za>
Message-ID: <1536604227.62.0.56676864532.issue31801@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31801>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:33:12 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Sep 2018 18:33:12 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1536604392.0.0.56676864532.issue20180@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 3286ce4adee85c5ce8ab3ee3089f3cd44a017fd7 by Raymond Hettinger (Tal Einat) in branch 'master':
bpo-20180: itertools.groupby Argument Clinic conversion (GH-4170)
https://github.com/python/cpython/commit/3286ce4adee85c5ce8ab3ee3089f3cd44a017fd7


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:36:59 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Sep 2018 18:36:59 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536604619.34.0.56676864532.issue34604@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I can do it if you feel the need. Can this same issue be used? Will the new PR require another NEWS entry?

Sure, reuse the same bpo number. You can modify the NEWS entry that you added ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34604>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:46:18 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Sep 2018 18:46:18 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1536605178.95.0.56676864532.issue25083@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset f64c813de84011a84ca21d75a294861a9cc2dfdc by Petr Viktorin (tzickel) in branch '2.7':
bpo-25083: Python can sometimes create incorrect .pyc files (GH-8449)
https://github.com/python/cpython/commit/f64c813de84011a84ca21d75a294861a9cc2dfdc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Mon Sep 10 14:49:57 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Sep 2018 18:49:57 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1536605397.39.0.56676864532.issue25083@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Mon Sep 10 15:06:49 2018
From: report at bugs.python.org (Eric Atkin)
Date: Mon, 10 Sep 2018 19:06:49 +0000
Subject: [issue33609] Document that dicts preserve insertion order
In-Reply-To: <1527023250.35.0.682650639539.issue33609@psf.upfronthosting.co.za>
Message-ID: <1536606409.24.0.56676864532.issue33609@psf.upfronthosting.co.za>


Eric Atkin <eatkin at omnisolutions.biz> added the comment:

It seems the note at the bottom for `object.__hash__(self)` [1] should be updated as well.

[1] https://docs.python.org/3/reference/datamodel.html#object.__hash__

----------
nosy: +Eric Atkin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33609>
_______________________________________

From report at bugs.python.org  Mon Sep 10 15:44:24 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 10 Sep 2018 19:44:24 +0000
Subject: [issue34622] Extract asyncio exceptions into a separate file
Message-ID: <1536608664.91.0.56676864532.issue34622@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Their public import paths are still the same, e.g. `asyncio.CancelledError`.

The change pursuits a better asyncio internal code structure.

----------
messages: 324952
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Extract asyncio exceptions into a separate file

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34622>
_______________________________________

From report at bugs.python.org  Mon Sep 10 15:44:34 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 10 Sep 2018 19:44:34 +0000
Subject: [issue34622] Extract asyncio exceptions into a separate file
In-Reply-To: <1536608664.91.0.56676864532.issue34622@psf.upfronthosting.co.za>
Message-ID: <1536608674.84.0.56676864532.issue34622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: +asyncio
nosy: +yselivanov
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34622>
_______________________________________

From report at bugs.python.org  Mon Sep 10 15:45:03 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 10 Sep 2018 19:45:03 +0000
Subject: [issue34622] Extract asyncio exceptions into a separate file
In-Reply-To: <1536608664.91.0.56676864532.issue34622@psf.upfronthosting.co.za>
Message-ID: <1536608703.17.0.56676864532.issue34622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +8591
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34622>
_______________________________________

From report at bugs.python.org  Mon Sep 10 15:50:01 2018
From: report at bugs.python.org (Jack Jansen)
Date: Mon, 10 Sep 2018 19:50:01 +0000
Subject: [issue27777] cgi.FieldStorage can't parse simple body with
 Content-Length and no Content-Disposition
In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>
Message-ID: <1536609001.41.0.56676864532.issue27777@psf.upfronthosting.co.za>


Change by Jack Jansen <jackjansen at users.sourceforge.net>:


----------
nosy: +jackjansen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27777>
_______________________________________

From report at bugs.python.org  Mon Sep 10 16:33:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 10 Sep 2018 20:33:10 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536611590.81.0.56676864532.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8592
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 10 17:10:22 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 10 Sep 2018 21:10:22 +0000
Subject: [issue34609] Idle Unitest
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1536613822.32.0.56676864532.issue34609@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Following up, I was able to recreate under 3.8 using pdb in powershell, so it's not just in IDLE.

Traceback (most recent call last):
  File "N:\projects\cpython\lib\pdb.py", line 1697, in main
    pdb._runscript(mainpyfile)
  File "N:\projects\cpython\lib\pdb.py", line 1566, in _runscript
    self.run(statement)
  File "N:\projects\cpython\lib\bdb.py", line 586, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "c:\users\onedrive\desktop\step.py", line 1, in <module>
    import unittest
  File "<frozen importlib._bootstrap>", line 980, in _find_and_load
  File "<frozen importlib._bootstrap>", line 149, in __enter__
  File "<frozen importlib._bootstrap>", line 101, in acquire
KeyError: 14104

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Mon Sep 10 18:43:33 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 10 Sep 2018 22:43:33 +0000
Subject: [issue34213] Frozen dataclass __init__ fails for "object" property"
In-Reply-To: <1532457260.21.0.56676864532.issue34213@psf.upfronthosting.co.za>
Message-ID: <1536619413.91.0.56676864532.issue34213@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.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/issue34213>
_______________________________________

From report at bugs.python.org  Mon Sep 10 18:47:44 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Sep 2018 22:47:44 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
Message-ID: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The pyexpat module calls XML_SetHashSalt(self->itself,                   (unsigned long)_Py_HashSecret.expat.hashsalt) to initialize the salt for hash randomization of the XML_Parser struct. The _elementree C accelerator doesn't call XML_SetHashSalt().

It's not a security issue with recent versions of libexpat. The library initializes the salt from a good entry source by default.

----------
components: XML
messages: 324954
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: _elementtree.c doesn't call XML_SetHashSalt()
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Mon Sep 10 18:52:40 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 22:52:40 +0000
Subject: [issue33437] Defining __init__ in enums
In-Reply-To: <1525687357.98.0.682650639539.issue33437@psf.upfronthosting.co.za>
Message-ID: <1536619960.0.0.56676864532.issue33437@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +8593
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33437>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:07:57 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Sep 2018 23:07:57 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1536620877.52.0.56676864532.issue34623@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +8594
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:08:18 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Sep 2018 23:08:18 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536620898.92.0.56676864532.issue34605@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, "master" in itself is used in a wide range of contexts and can have quite positive connotations (I master Python programming).

The word "slave" I agree with removing if used gratuitously. If its use reflects an established convention which we do not have power to change, then we should probably keep using it for the sake of clarity (for example in the openpty case, since we're merely exposing a glibc function).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:16:12 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Sep 2018 23:16:12 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536621372.4.0.56676864532.issue8110@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset 880d42a3b247306f67837aa95e23f7c3471a30a3 by Zachary Ware in branch 'master':
bpo-8110: Refactor platform detection in subprocess (GH-9053)
https://github.com/python/cpython/commit/880d42a3b247306f67837aa95e23f7c3471a30a3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:16:57 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Sep 2018 23:16:57 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536621417.03.0.56676864532.issue8110@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Do we want to bother backporting anything, or call it fixed in 3.8 and move on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:28:08 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 10 Sep 2018 23:28:08 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536622088.73.0.0269046726804.issue8110@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

lets call this fixed.  if and only if another Python implementation pipes up as happier if this exists in an older than 3.8 version we can consider backporting the same refactoring to that code.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:29:20 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Sep 2018 23:29:20 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1536622160.94.0.0269046726804.issue8110@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
versions:  -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:36:34 2018
From: report at bugs.python.org (=?utf-8?b?VGhvbWFzIEdsw6TDn2xl?=)
Date: Mon, 10 Sep 2018 23:36:34 +0000
Subject: [issue34624] -W option does not accept module regexes
Message-ID: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>


New submission from Thomas Gl??le <thomas at coldfix.de>:

Hi,

This command does not report a warning, while it should:

  python -c 'import warnings; warnings.warn("This should show up")' -Wi -W'default:::.*'

If the regex `.*` is replaced by `__main__` it works as expected.

Same applies for regexes in PYTHONWARNINGS and for the `message` part of the argument. 

The reason can be found in Lib/warnings.py:144 (def _setoption):

  module = re.escape(module)

This point-blank escape makes me think that it was intended that no regexes can be passed to message/module. On the other, the documentation reads as if it should be supported.

Specifically, the -W option is documented in [1]. While this page lists only basic examples, it refers to [2] and [3] for more details. [2] states that message/module are regexes. [3] seems to be written to specifically address the syntax of the PYTHONWARNINGS and the -W option and explicitly lists an example with a regex.

[1]: https://docs.python.org/3/using/cmdline.html#cmdoption-w
[2]: https://docs.python.org/3/library/warnings.html#warning-filter
[3]: https://docs.python.org/3/library/warnings.html#describing-warning-filters

I would welcome if we could remove `re.escape` to make the implementation fit the documentation, or are there any downsides to this?


Best regards, Thomas

----------
components: Library (Lib)
messages: 324959
nosy: coldfix
priority: normal
severity: normal
status: open
title: -W option does not accept module regexes
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:39:14 2018
From: report at bugs.python.org (=?utf-8?b?VGhvbWFzIEdsw6TDn2xl?=)
Date: Mon, 10 Sep 2018 23:39:14 +0000
Subject: [issue34624] -W option does not accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1536622754.45.0.0269046726804.issue34624@psf.upfronthosting.co.za>


Thomas Gl??le <thomas at coldfix.de> added the comment:

Very sorry, the example command above should read:

  python -Wi -W'default:::.*' -c 'import warnings; warnings.warn("This should show up")'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:48:17 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 23:48:17 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1536623297.28.0.0269046726804.issue34623@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Note we compile expat with -DXML_POOR_ENTROPY on the assumption that Python always initializes the entropy itself.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Mon Sep 10 19:56:15 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 10 Sep 2018 23:56:15 +0000
Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary
 mode
In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za>
Message-ID: <1536623775.62.0.0269046726804.issue32236@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

My problem with a warning is the standard one: People who see a warning are often end users of python applications (who don't even have to know what Python is, let alone know anything about the code).  For that reason, never add a warning to a stable branch - only new releases (meaning 3.8 here).

Given that this isn't not a deprecation of meaningful API behavior but is highlighting questionably undefined nonsense behavior, users complaining upon obtaining 3.8 should ultimately reach library and application developers who use the API wrong to update their call sites to explicitly ask for what they intended instead of being ambiguious.

FYI - the subprocess.py related changes in your PR are correct.

----------
nosy: +gregory.p.smith
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32236>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:09:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 00:09:37 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1536624577.44.0.0269046726804.issue34623@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Note we compile expat with -DXML_POOR_ENTROPY on the assumption that Python always initializes the entropy itself.

Oh. I forgot this thing. So it seems like we have to backport this change to 2.7, 3.6 and newer versions.

What about Python 3.4 and 3.5? Python 3.5 has a copy of libexpat 2.2.0, but setup.py doesn't build expat with XML_POOR_ENTROPY=1.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:28:56 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Sep 2018 00:28:56 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>
Message-ID: <1536625736.57.0.0269046726804.issue34586@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've discussed this with other core devs and spent a good deal of time evaluating this proposal.  I'm going to pass on the this one but do think it was a inspired suggestion.  Thank you for the proposal.

----------

Note, the original get_where() recipe has an issue.  Upon successful lookup, it returns a 2-tuple but on failure it calls __missing__ which typically returns a scalar (if it doesn't raise an exception).

The proposed use case is plausible but rare.  As Serhiy mentioned, it is also reasonable for the user to write their own loops over the *maps* attribute.  That loop can have subtleties but it is better to let the user choose between try/except semantics and if-else semantics according to the use case.

FWIW, I tried out several variants of the proposal including "cm.index(key) -> int" and "cm.search(key) -> mapping".  Each of the variants had some awkwardness when trying to use it there didn't seem to be a variant that was a net win.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34586>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:37:04 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 Sep 2018 00:37:04 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1536626224.28.0.0269046726804.issue18307@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So it sounds like that maybe we need to decide if we are going to replace zipimport with Serhiy's Python version. And if we do decide to go with the Python code then it should get updated to use _imp._fix_co_filename().

Regardless of the decision, obviously thanks to Vitaly for sparking this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:38:52 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Sep 2018 00:38:52 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1536626332.99.0.0269046726804.issue34623@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Dang, it's a security bug after all. :(

3.5 has 2.2.4, so it's fine. 2.2.2 had a bug in salt initialization.

----------
type: behavior -> security
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:44:23 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 00:44:23 +0000
Subject: [issue34625] update to expat 2.2.6
Message-ID: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

libexpat 2.2.6 has been released. We should update our vendorized version.

----------
components: XML
messages: 324967
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: update to expat 2.2.6
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:46:26 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 00:46:26 +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: <1536626786.18.0.0269046726804.issue32270@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset ce34410b8b67f49d8275c05d51b3ead50cf97f48 by Gregory P. Smith in branch 'master':
bpo-32270: Don't close stdin/out/err in pass_fds (GH-6242)
https://github.com/python/cpython/commit/ce34410b8b67f49d8275c05d51b3ead50cf97f48


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:46:37 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 00:46:37 +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: <1536626797.03.0.0269046726804.issue32270@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8595

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:46:47 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 00:46:47 +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: <1536626807.81.0.0269046726804.issue32270@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Mon Sep 10 20:47:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 00:47:27 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536626847.79.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8597
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:01:07 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 01:01:07 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1536627667.17.0.0269046726804.issue34465@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This isn't limited to just IPv4Address, the Network classes and the IPv6 classes that accept bytes should also be updated for consistency if we're going to do this.

(bytes, bytearray, memoryview) make sense to support, and explicitly test in unittests.

Until then, the workaround is to call bytes on the relevant slice of those.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:11:30 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Sep 2018 01:11:30 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536628290.66.0.0269046726804.issue34363@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
pull_requests: +8598

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:13:12 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 01:13:12 +0000
Subject: [issue33460] "..." is used to confusingly indicate many different
 things in chapter 3
In-Reply-To: <1525995197.73.0.682650639539.issue33460@psf.upfronthosting.co.za>
Message-ID: <1536628392.33.0.0269046726804.issue33460@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset f019579828ed62653e2d41c95278308fa076ccaf by Gregory P. Smith (Lew Kurtz) in branch 'master':
bpo-33460: remove ellipsis that look like continuation prompts (GH-7851)
https://github.com/python/cpython/commit/f019579828ed62653e2d41c95278308fa076ccaf


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33460>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:13:21 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 01:13:21 +0000
Subject: [issue33460] "..." is used to confusingly indicate many different
 things in chapter 3
In-Reply-To: <1525995197.73.0.682650639539.issue33460@psf.upfronthosting.co.za>
Message-ID: <1536628401.07.0.0269046726804.issue33460@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8599

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33460>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:14:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Sep 2018 01:14:22 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536628462.64.0.0269046726804.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I like GH-9151 better because it changes only the namedtuple case, not other classes that are derived from list or tuple.

But, I might copy some of the tests from 9151 before I'm done with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:15:02 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 01:15:02 +0000
Subject: [issue33487] BZ2File(buffering=None) does not emit deprecation
 warning, deprecation version not documented.
In-Reply-To: <1526247744.31.0.682650639539.issue33487@psf.upfronthosting.co.za>
Message-ID: <1536628502.77.0.0269046726804.issue33487@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33487>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:15:59 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 01:15:59 +0000
Subject: [issue33487] BZ2File(buffering=None) does not emit deprecation
 warning, deprecation version not documented.
In-Reply-To: <1526247744.31.0.682650639539.issue33487@psf.upfronthosting.co.za>
Message-ID: <1536628559.18.0.0269046726804.issue33487@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset ffa198c642f9c67b84ef192bf0f7016c4249e570 by Gregory P. Smith (Matthias Bussonnier) in branch 'master':
bpo-33487: improve BZ2File Deprecation and documentation. (GH-6785)
https://github.com/python/cpython/commit/ffa198c642f9c67b84ef192bf0f7016c4249e570


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33487>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:16:38 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 01:16:38 +0000
Subject: [issue33487] BZ2File(buffering=None) does not emit deprecation
 warning, deprecation version not documented.
In-Reply-To: <1526247744.31.0.682650639539.issue33487@psf.upfronthosting.co.za>
Message-ID: <1536628598.05.0.0269046726804.issue33487@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33487>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:21:40 2018
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 11 Sep 2018 01:21:40 +0000
Subject: [issue34082] EnumMeta.__new__ should use enum_class.__new__
In-Reply-To: <1531215826.62.0.56676864532.issue34082@psf.upfronthosting.co.za>
Message-ID: <1536628900.52.0.0269046726804.issue34082@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

The solution to 29577 will also fix this.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Enum: mixin classes don't mix well with already mixed Enums

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34082>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:33:17 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 01:33:17 +0000
Subject: [issue34626] PEP 384's PyType_Spec and PyType_Slot are not documented
Message-ID: <1536629597.33.0.0269046726804.issue34626@psf.upfronthosting.co.za>


New submission from Petr Viktorin <encukou at gmail.com>:

The documentation of PyType_FromSpec and PyType_FromSpecWithBases is currently not very useful. In particular, PyType_Spec and PyType_Slot are only documented in pep-0384, not in the Python docs.

----------
messages: 324975
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: PEP 384's PyType_Spec and PyType_Slot are not documented

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34626>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:35:25 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 01:35:25 +0000
Subject: [issue34626] PEP 384's PyType_Spec and PyType_Slot are not documented
In-Reply-To: <1536629597.33.0.0269046726804.issue34626@psf.upfronthosting.co.za>
Message-ID: <1536629725.42.0.0269046726804.issue34626@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
keywords: +patch
pull_requests: +8600
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34626>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:47:50 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 11 Sep 2018 01:47:50 +0000
Subject: [issue32027] argparse allow_abbrev option also controls short flag
 combinations
In-Reply-To: <1510680582.36.0.213398074469.issue32027@psf.upfronthosting.co.za>
Message-ID: <1536630470.35.0.0269046726804.issue32027@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

The PR 4396 should be closed.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32027>
_______________________________________

From report at bugs.python.org  Mon Sep 10 21:49:42 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 01:49:42 +0000
Subject: [issue33460] "..." is used to confusingly indicate many different
 things in chapter 3
In-Reply-To: <1525995197.73.0.682650639539.issue33460@psf.upfronthosting.co.za>
Message-ID: <1536630582.75.0.0269046726804.issue33460@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 037582eb7f4d61604ef2dcc72f896117588eeb3c by Miss Islington (bot) in branch '3.7':
bpo-33460: remove ellipsis that look like continuation prompts (GH-7851)
https://github.com/python/cpython/commit/037582eb7f4d61604ef2dcc72f896117588eeb3c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33460>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:04:11 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 04:04:11 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536638651.59.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 5033aa77aacaa5505636f150e8d54baac5bdca9c by Benjamin Peterson in branch 'master':
bpo-34625: Update vendorized expat version to 2.2.6. (GH-9150)
https://github.com/python/cpython/commit/5033aa77aacaa5505636f150e8d54baac5bdca9c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:04:13 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:04:13 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536638653.0.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8601

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:04:21 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:04:21 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536638661.53.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8602

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:04:35 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:04:35 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536638675.84.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:06:46 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 04:06:46 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536638806.97.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:26:46 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:26:46 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536640006.62.0.0269046726804.issue34625@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7a501def4fb98a1d6f15e4a5a006141d6027f948 by Miss Islington (bot) in branch '2.7':
bpo-34625: Update vendorized expat version to 2.2.6. (GH-9150)
https://github.com/python/cpython/commit/7a501def4fb98a1d6f15e4a5a006141d6027f948


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:36:24 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 04:36:24 +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: <1536640584.47.0.0269046726804.issue32270@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 9c4a63fc17efea31ad41f90d28825be37469e0e2 by Gregory P. Smith (Miss Islington (bot)) in branch '3.7':
bpo-32270: Don't close stdin/out/err in pass_fds (GH-6242) (GH-9148)
https://github.com/python/cpython/commit/9c4a63fc17efea31ad41f90d28825be37469e0e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:37:36 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 04:37:36 +0000
Subject: [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536640656.85.0.0269046726804.issue33032@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 3666b3c1f695a145adab1bf644c22e564e8eb0ee by Gregory P. Smith (Zackery Spytz) in branch 'master':
bpo-33032: Mention the implicit cache in struct.Struct() docs (GH-7700)
https://github.com/python/cpython/commit/3666b3c1f695a145adab1bf644c22e564e8eb0ee


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33032>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:37:45 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:37:45 +0000
Subject: [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536640665.74.0.0269046726804.issue33032@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8604

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33032>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:40:12 2018
From: report at bugs.python.org (Noah Haasis)
Date: Tue, 11 Sep 2018 04:40:12 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1536640812.0.0.0269046726804.issue21314@psf.upfronthosting.co.za>


Noah Haasis <haasis_noah at yahoo.de> added the comment:

Can I work on this?

----------
nosy: +noah.haasis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:50:46 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:50:46 +0000
Subject: [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536641446.48.0.0269046726804.issue33032@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2110f78d92522499836a928d268704fdc5f7a037 by Miss Islington (bot) in branch '3.7':
bpo-33032: Mention the implicit cache in struct.Struct() docs (GH-7700)
https://github.com/python/cpython/commit/2110f78d92522499836a928d268704fdc5f7a037


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33032>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:55:30 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:55:30 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536641730.78.0.0269046726804.issue34625@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2bc4eea8f6675b157adcaea4a59d982d58a5e7ae by Miss Islington (bot) in branch '3.7':
bpo-34625: Update vendorized expat version to 2.2.6. (GH-9150)
https://github.com/python/cpython/commit/2bc4eea8f6675b157adcaea4a59d982d58a5e7ae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:56:29 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 04:56:29 +0000
Subject: [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536641789.46.0.0269046726804.issue33032@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33032>
_______________________________________

From report at bugs.python.org  Tue Sep 11 00:56:53 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 04:56:53 +0000
Subject: [issue34625] update to expat 2.2.6
In-Reply-To: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>
Message-ID: <1536641813.87.0.0269046726804.issue34625@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b2260e59ff1eaf20de4738099005ddf507b7b27d by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
bpo-34625: Update vendorized expat version to 2.2.6. (GH-9158)
https://github.com/python/cpython/commit/b2260e59ff1eaf20de4738099005ddf507b7b27d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34625>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:09:24 2018
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 11 Sep 2018 05:09:24 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1536642564.39.0.0269046726804.issue4921@psf.upfronthosting.co.za>


Eric Wieser <wieser.eric+pybug at gmail.com> added the comment:

For anyone doing archaeology - this came up on python-dev about a year after this issue was filed: https://mail.python.org/pipermail/python-dev/2009-December/094439.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:12:45 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 05:12:45 +0000
Subject: [issue33883] doc Mention mypy, pyrex, pytype and PyAnnotate in FAQ
In-Reply-To: <1529196736.16.0.56676864532.issue33883@psf.upfronthosting.co.za>
Message-ID: <1536642765.01.0.0269046726804.issue33883@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a37825418649873a0fa971dc7e5e6d142c124574 by Benjamin Peterson (Andr?s Delfino) in branch 'master':
closes bpo-33883: Mention type checkers in the FAQ. (GH-7760)
https://github.com/python/cpython/commit/a37825418649873a0fa971dc7e5e6d142c124574


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33883>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:12:54 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 05:12:54 +0000
Subject: [issue33883] doc Mention mypy, pyrex, pytype and PyAnnotate in FAQ
In-Reply-To: <1529196736.16.0.56676864532.issue33883@psf.upfronthosting.co.za>
Message-ID: <1536642774.04.0.0269046726804.issue33883@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8605

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33883>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:27:05 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 05:27:05 +0000
Subject: [issue33883] doc Mention mypy, pyrex, pytype and PyAnnotate in FAQ
In-Reply-To: <1529196736.16.0.56676864532.issue33883@psf.upfronthosting.co.za>
Message-ID: <1536643625.31.0.0269046726804.issue33883@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c9ece5f4a961d4963ed42aefa934eb20f9a7222b by Miss Islington (bot) in branch '3.7':
closes bpo-33883: Mention type checkers in the FAQ. (GH-7760)
https://github.com/python/cpython/commit/c9ece5f4a961d4963ed42aefa934eb20f9a7222b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33883>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:44:42 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 11 Sep 2018 05:44:42 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1536644682.3.0.0269046726804.issue34569@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34569>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:45:07 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 11 Sep 2018 05:45:07 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1536644707.77.0.0269046726804.issue34579@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34579>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:45:27 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 11 Sep 2018 05:45:27 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>
Message-ID: <1536644727.36.0.0269046726804.issue34373@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:45:48 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 11 Sep 2018 05:45:48 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>
Message-ID: <1536644748.42.0.0269046726804.issue34373@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:47:21 2018
From: report at bugs.python.org (Ma Lin)
Date: Tue, 11 Sep 2018 05:47:21 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1536644841.33.0.0269046726804.issue34294@psf.upfronthosting.co.za>


Ma Lin <malincns at 163.com> added the comment:

This bug generates wrong results silently, so I suggest mark it as release blocker for 3.7.1

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Tue Sep 11 01:49:20 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 11 Sep 2018 05:49:20 +0000
Subject: [issue34194] test_ssl, AIX, and defaults for _ssl connections
In-Reply-To: <1532328016.0.0.56676864532.issue34194@psf.upfronthosting.co.za>
Message-ID: <1536644960.85.0.0269046726804.issue34194@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

When built against a less optimized OpenSSL library all tests pass. So, IMHO, not a bug, and closing.

The buildbots will (eventually) build against a less optimized library and the error messages will match. That was the cause of all these messages (no matching error message).

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34194>
_______________________________________

From report at bugs.python.org  Tue Sep 11 02:00:04 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 11 Sep 2018 06:00:04 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1536645604.95.0.0269046726804.issue11192@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
components: +Tests
type:  -> behavior
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Tue Sep 11 02:00:54 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 06:00:54 +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: <1536645654.48.0.0269046726804.issue32270@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 2173bb818c6c726d831b106ed0d3fad7825905dc by Gregory P. Smith (Miss Islington (bot)) in branch '3.6':
bpo-32270: Don't close stdin/out/err in pass_fds (GH-6242) (GH-9149)
https://github.com/python/cpython/commit/2173bb818c6c726d831b106ed0d3fad7825905dc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Tue Sep 11 02:04:23 2018
From: report at bugs.python.org (hongweipeng)
Date: Tue, 11 Sep 2018 06:04:23 +0000
Subject: [issue34315] Regex not evalauated correctly
In-Reply-To: <1533189179.81.0.56676864532.issue34315@psf.upfronthosting.co.za>
Message-ID: <1536645863.4.0.0269046726804.issue34315@psf.upfronthosting.co.za>


hongweipeng <hongweichen8888 at sina.com> added the comment:

In my test in win2012r2, it works well. Add a screenshot.

----------
nosy: +hongweipeng
Added file: https://bugs.python.org/file47794/win12r2py3.7.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34315>
_______________________________________

From report at bugs.python.org  Tue Sep 11 02:23:49 2018
From: report at bugs.python.org (Kay Hayen)
Date: Tue, 11 Sep 2018 06:23:49 +0000
Subject: [issue34615] subprocess.call wrong exit code
In-Reply-To: <1536519757.93.0.56676864532.issue34615@psf.upfronthosting.co.za>
Message-ID: <1536647029.26.0.0269046726804.issue34615@psf.upfronthosting.co.za>


Kay Hayen <kay.hayen at gmail.com> added the comment:

So I was confused indeed. 

Actually I am observing in other tests at least, that apparently Nuitka compiled execution in my tests can import _testcapi module, which normal execution of the test does not manage. 

Then there is the possibility that the exit code is indeed "0" and different.

The failure to import that module is old, and something I consider to raise as a separate issue. Closing this one as it's not worthy.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34615>
_______________________________________

From report at bugs.python.org  Tue Sep 11 02:33:15 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Sep 2018 06:33:15 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536647595.23.0.0269046726804.issue34605@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm closing this now. Three out of four of Victor's PRs have been merged. The fourth one should not be merged because it reflects the underlying terminology of UNIX ptys. There's a remaining quibble about "pliant children" -> "helpers" but that can be dealt with as a follow-up PR without keeping this discussion open.

----------
nosy: +gvanrossum
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Tue Sep 11 02:52:17 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 11 Sep 2018 06:52:17 +0000
Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c
In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za>
Message-ID: <1536648737.25.0.0269046726804.issue23855@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23855>
_______________________________________

From report at bugs.python.org  Tue Sep 11 03:33:30 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 11 Sep 2018 07:33:30 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
In-Reply-To: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>
Message-ID: <1536651210.44.0.0269046726804.issue32490@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8606
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Tue Sep 11 03:37:04 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 11 Sep 2018 07:37:04 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
In-Reply-To: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>
Message-ID: <1536651424.35.0.0269046726804.issue32490@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Tue Sep 11 04:15:25 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 08:15:25 +0000
Subject: [issue34624] -W option does not accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1536653725.8.0.0269046726804.issue34624@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Tue Sep 11 04:26:50 2018
From: report at bugs.python.org (badrussians)
Date: Tue, 11 Sep 2018 08:26:50 +0000
Subject: [issue34627] Python incorrect execution order
Message-ID: <1536654410.3.0.0269046726804.issue34627@psf.upfronthosting.co.za>


New submission from badrussians <oknaassortiment at gmail.com>:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
print('');
import sys, os, subprocess, re, ctypes, tempfile, shutil, tarfile, urllib.request;
argsCount=len(sys.argv);
scriptDir = os.path.dirname(os.path.abspath(sys.argv[0]));


def FindFullPaths(strPattern, *orderedSearchDirs, \
				  findFile=True, findDir=False, \
				  ignoreCase=False, returnFirst=True):
	print('#  FindFullPaths__In');
	result = [];
	def resultAppendUnique(item):
		if item not in result:
				result.append(item);
	pattern = re.compile(strPattern, \
			re.IGNORECASE | re.DOTALL if ignoreCase else re.DOTALL);
	isFound = False;
	for searchDir in orderedSearchDirs:
		print('#searchDir', searchDir, orderedSearchDirs, '\n');
		for leafName in os.listdir(searchDir):
			leafPath = os.path.join(searchDir, leafName);
			isDir = os.path.isdir(leafPath);
			isFound = (findDir and isDir or \
					   findFile and os.path.isfile(leafPath)) \
						and pattern.search(leafName) is not None;
			print('#leafPath:', leafPath, '\n'); #ERROR = output Last AND last time - no in output!
			print('#isFound:', isFound);         #ERROR = output First AND first time - no in output!
			if isFound:
				resultAppendUnique(leafPath);
			if isDir and not (returnFirst and isFound):
				for partLeafPath in FindFullPaths(strPattern, leafPath, \
						findFile=findFile, findDir=findDir, \
						ignoreCase=ignoreCase, returnFirst=returnFirst):
					resultAppendUnique(partLeafPath);
					isFound = True;
			if returnFirst and isFound:
				break;
		if returnFirst and isFound:
			break;
	print('#  FindFullPaths__Return');
	return result; 

FindFullPaths('^bat$', '/home/user/??????? ????/ttt');
print(sys.version);

#### OUTPUT: ####
'/home/user/??????? ????/test2.py' 

#  FindFullPaths__In
#searchDir /home/user/??????? ????/ttt ('/home/user/??????? ????/ttt',) 

#leafPath: /home/user/??????? ????/ttt/BackupRestore.py 

#isFound: False
#leafPath: /home/user/??????? ????/ttt/temp.py 

#isFound: False
#leafPath: /home/user/??????? ????/ttt/Create ISO.py 

#isFound: False
#  FindFullPaths__Return
3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0]
###### Environment ######
Russian Ubuntu 18.04.1 and Kali 2018.3
PS: Ru:'/home/user/??????? ????' == Eng'/home/user/Desktop'

----------
components: Interpreter Core
files: test2.py
messages: 324996
nosy: badrussians
priority: normal
severity: normal
status: open
title: Python incorrect execution order
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47795/test2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34627>
_______________________________________

From report at bugs.python.org  Tue Sep 11 04:42:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 08:42:50 +0000
Subject: [issue34624] -W option does not accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1536655370.47.0.0269046726804.issue34624@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The original escape was done with 2a862c614d6d3ff50dc644150670651fdc9f3a99 which was in 2000. The doc example you are referring to at [1] was added with https://bugs.python.org/issue31975 and there doesn't seem to be a test involving regular expression as I can see from the PR. Adding Nick to the issue since he had committed the doc and might help here.


[1] https://docs.python.org/3/library/warnings.html#describing-warning-filters

Thanks

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Tue Sep 11 05:15:55 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 09:15:55 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536657355.27.0.0269046726804.issue31577@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Tue Sep 11 05:38:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 09:38:41 +0000
Subject: [issue34627] Python incorrect execution order
In-Reply-To: <1536654410.3.0.0269046726804.issue34627@psf.upfronthosting.co.za>
Message-ID: <1536658721.28.0.0269046726804.issue34627@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please describe the problem and the output you are expecting so that we can determine if it's a bug in Python or the logic of the code which will get better help from sites stackoverflow ? It will be helpful if you can do `tree` on the search directory if it's small so that it will be helpful to replicate the structure for test too.

Please consider using 4 space instead of tabs as per PEP8 and semicolon is not needed at the end of statements. A little cleaned up version of the same program.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
print('')
import sys, os, subprocess, re, ctypes, tempfile, shutil, tarfile, urllib.request
argsCount=len(sys.argv)
scriptDir = os.path.dirname(os.path.abspath(sys.argv[0]))


def FindFullPaths(strPattern, *orderedSearchDirs, \
                  findFile=True, findDir=False, \
                  ignoreCase=False, returnFirst=True):
    print('#  FindFullPaths__In')
    result = []

    def resultAppendUnique(item):
        if item not in result:
            result.append(item)

    pattern = re.compile(strPattern, \
                         re.IGNORECASE | re.DOTALL if ignoreCase else re.DOTALL)
    isFound = False
    for searchDir in orderedSearchDirs:
        print('#searchDir', searchDir, orderedSearchDirs, '\n')
        for leafName in os.listdir(searchDir):
            leafPath = os.path.join(searchDir, leafName)
            isDir = os.path.isdir(leafPath)
            isFound = (findDir and isDir or \
                       findFile and os.path.isfile(leafPath)) \
                       and pattern.search(leafName) is not None
            print('#leafPath:', leafPath, '\n') #ERROR = output Last AND last time - no in output!
            print('#isFound:', isFound) #ERROR = output First AND first time - no in output!
            if isFound:
                resultAppendUnique(leafPath)
            if isDir and not (returnFirst and isFound):
                for partLeafPath in FindFullPaths(strPattern, leafPath, \
                                                  findFile=findFile, findDir=findDir, \
                                                  ignoreCase=ignoreCase, returnFirst=returnFirst):
                    resultAppendUnique(partLeafPath)
                    isFound = True;
            if returnFirst and isFound:
                break;
        if returnFirst and isFound:
            break;
    print('#  FindFullPaths__Return')
    return result

FindFullPaths('^bat$', '/tmp/')
print(sys.version)



Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34627>
_______________________________________

From report at bugs.python.org  Tue Sep 11 06:02:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 10:02:13 +0000
Subject: [issue30238] 2to3 doesn't detect or fix Exception indexing
In-Reply-To: <1493753516.03.0.383972145792.issue30238@psf.upfronthosting.co.za>
Message-ID: <1536660133.52.0.0269046726804.issue30238@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30238>
_______________________________________

From report at bugs.python.org  Tue Sep 11 06:53:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 10:53:13 +0000
Subject: [issue31535] configparser unable to write comment with a upper cas
 letter
In-Reply-To: <1505924902.42.0.843371526892.issue31535@psf.upfronthosting.co.za>
Message-ID: <1536663193.62.0.0269046726804.issue31535@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31535>
_______________________________________

From report at bugs.python.org  Tue Sep 11 07:11:47 2018
From: report at bugs.python.org (badrussians)
Date: Tue, 11 Sep 2018 11:11:47 +0000
Subject: [issue34627] Python incorrect execution order
In-Reply-To: <1536654410.3.0.0269046726804.issue34627@psf.upfronthosting.co.za>
Message-ID: <1536664307.29.0.0269046726804.issue34627@psf.upfronthosting.co.za>


badrussians <oknaassortiment at gmail.com> added the comment:

Big Sorry - it is my mistake. In terminal I execute same file, but in other location.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34627>
_______________________________________

From report at bugs.python.org  Tue Sep 11 07:15:23 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 11:15:23 +0000
Subject: [issue31535] configparser unable to write comment with a upper cas
 letter
In-Reply-To: <1505924902.42.0.843371526892.issue31535@psf.upfronthosting.co.za>
Message-ID: <1536664523.07.0.0269046726804.issue31535@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

All config options are converted to lowercase when they are stored. You can customise this with https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform. You can customize it more with https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour

>  Note also that keys in sections are case-insensitive and stored in lowercase 

>>> from configparser import ConfigParser
>>> c = ConfigParser()
>>> c["A"] = {'FOO': 'bar'}
>>> with open('example.ini', 'w') as configfile: c.write(configfile)
...
>>> with open('example.ini', 'r') as configfile: print(configfile.read())
...
[A]
foo = bar


# Don't convert to lower case

>>> d = ConfigParser()
>>> d.optionxform = str
>>> d["A"] = {'FOO': 'bar'}
>>> with open('example_case.ini', 'w') as configfile: d.write(configfile)
...
>>> with open('example_case.ini', 'r') as configfile: print(configfile.read())
...
[A]
FOO = bar


Hope this answers your question. Feel free to close this if it's clear.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31535>
_______________________________________

From report at bugs.python.org  Tue Sep 11 07:24:08 2018
From: report at bugs.python.org (Martijn Pieters)
Date: Tue, 11 Sep 2018 11:24:08 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1536665048.64.0.0269046726804.issue26832@psf.upfronthosting.co.za>


Martijn Pieters <mj at python.org> added the comment:

I'm trying to figure out why Windows won't let us do this. I think the reason is that sys.std(in|out) filehandles are not opened as pipes, and do not have the required OVERLAPPED flag set (see the CreateIoCompletionPort documentation at https://docs.microsoft.com/en-us/windows/desktop/fileio/createiocompletionport; it's that function that is used to handle pipes (via IocpProactor.recv -> IocpProactor._register_with_iocp -> overlapped.CreateIoCompletionPort).

The solution then would be to create a pipe for a stdio filehandle with the flag set.

And that's where my Windows-fu ends, and where I lack the VM and motivation to go try that out.

----------
nosy: +mjpieters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Tue Sep 11 07:34:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 11:34:27 +0000
Subject: [issue31535] configparser unable to write comment with a upper cas
 letter
In-Reply-To: <1505924902.42.0.843371526892.issue31535@psf.upfronthosting.co.za>
Message-ID: <1536665667.61.0.0269046726804.issue31535@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ah sorry, didn't notice it was about comments. It seems config.optionxform = str has no effect on comments.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31535>
_______________________________________

From report at bugs.python.org  Tue Sep 11 07:38:37 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 11:38:37 +0000
Subject: [issue31535] configparser unable to write comment with a upper cas
 letter
In-Reply-To: <1505924902.42.0.843371526892.issue31535@psf.upfronthosting.co.za>
Message-ID: <1536665917.33.0.0269046726804.issue31535@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ah my bad again. The config.optionxform = str does the trick. I was using an older object.

from configparser import ConfigParser

config = ConfigParser(allow_no_value=True)
config.optionxform = str
config.add_section('default_settings')
config.set('default_settings', '; comment HERE')

with open('example_case.ini', 'w') as configfile: config.write(configfile)
with open('example_case.ini', 'r') as configfile: print(configfile.read())


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31535>
_______________________________________

From report at bugs.python.org  Tue Sep 11 08:00:25 2018
From: report at bugs.python.org (Vijay)
Date: Tue, 11 Sep 2018 12:00:25 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1536667225.95.0.0269046726804.issue34553@psf.upfronthosting.co.za>


Vijay <vijay.ramdass at gmail.com> added the comment:

can someone please clarify, is it a pywin32 issue or python3.7 issue?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Tue Sep 11 09:39:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 13:39:51 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1536673191.26.0.0269046726804.issue21314@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Welcome, Noah! Feel free to work on this issue, but please note that there is no consensus on the best place to document / signatures, so you may need to move your changes between locations (e.g. from Doc/faq/programming.rst to Doc/gloassary.rst) before we merge your work.

----------
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/issue21314>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:03:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 14:03:43 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1536674623.46.0.0269046726804.issue34443@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Serhiy, why should __qualname__ always be used together with __module__?

Because what is the purpose of using __qualname__?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:15:18 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 11 Sep 2018 14:15:18 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1536675318.68.0.0269046726804.issue20180@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8607

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:18:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 14:18:14 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1536675494.75.0.0269046726804.issue34443@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think using more longer name in repr and/or str for *instances* of enum classes is not good idea. They are already verbose, and this will make them more verbose.

Actually in some cases when enum instances are exposed as module globals, I would want to make them including the module name instead of the enum class name. For example:

>>> import socket
>>> socket.AF_UNIX
<AddressFamily.AF_UNIX: 1>
>>> print(socket.AF_UNIX)
AddressFamily.AF_UNIX

"socket.AF_UNIX" instead of "AddressFamily.AF_UNIX" would look better to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:20:56 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Sep 2018 14:20:56 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536675656.27.0.0269046726804.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The entire change affecting the PEP 538 implementation in https://github.com/python/cpython/commit/9454060e84a669dde63824d9e2fcaf295e34f687#diff-8c018c3ada66d06c8e101e47a313c2c7 needs to be reverted: the locale should be coerced before *ANY* calls are made to Py_DecodeLocale, as the whole point of the architecture of the PEP implementation was to ensure that *nothing ever gets decoded incorrectly in the first place*.

I just initially missed that in Victor's enthusiasm for fixing the incorrect decodings that can arise in the absence of locale coercion he'd *introduced* incorrect decoding into the locale coercion case.

----------
nosy: +ncoghlan, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:25:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 14:25:21 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1536675921.39.0.0269046726804.issue14156@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:28:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Sep 2018 14:28:27 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536676107.55.0.0269046726804.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(The one exception to "nothing gets decoded incorrectly" is that PYTHONCOERCECLOCALE itself is always interpreted as an ASCII field: the values that it checks for are actually ASCII byte sequences, not Unicode code points.

The documentation could definitely be much clearer on that point though, as even in the PEP it's only implied by the final paragraph in https://www.python.org/dev/peps/pep-0538/#legacy-c-locale-coercion-in-the-standalone-python-interpreter-binary which is mostly talking about the fact that this particular environment variable is still checked, even if you pass the -I or -E command line options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:38:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Sep 2018 14:38:51 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536676731.95.0.0269046726804.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

FWIW, this is also why I don't want PEP 432 to expose any wstr fields in the configuration settings: it means embedding applications have to figure out which encoding Python is expecting to be used for those fields.

Everything should be much cleaner if the public API requires those settings to be provided as Py_Unicode objects, and the core configuration step takes care of getting the C API to the point where the embedding application can create Py_Unicode objects for passing to later steps.

The fact that CPython itself currently uses wstr to configure these settings should be considered a legacy implementation detail that we do our best to hide from the public API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:38:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 14:38:56 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1536676736.35.0.0269046726804.issue14156@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The solution with fileno() is clever, but as was mentioned before, it doesn't work if stdin or stdout are not real files, but something like StringIO. It is not that in common use of argparse for parsing arguments in scripts they are redefined, but argparse can be used in uncommon environments, for example for emulating command line in the environment like IDLE which redefines standard streams. And I'm sure this will break third-party tests which main() with patched stdin/stdout for testing CLI. The initial solution proposed by Moritz is more reliable, although it doesn't fix an issues with closing stdin/stdout. But this is a different issue at all.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:43:05 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 11 Sep 2018 14:43:05 +0000
Subject: [issue4921] Object lifetime and inner recursive function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1536676985.76.0.0269046726804.issue4921@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4921>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:45:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 14:45:12 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
In-Reply-To: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>
Message-ID: <1536677112.45.0.0269046726804.issue32490@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This code was added in issue4925. Is the original problem gone?

----------
nosy: +benjamin.peterson, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:50:32 2018
From: report at bugs.python.org (William Grzybowski)
Date: Tue, 11 Sep 2018 14:50:32 +0000
Subject: [issue34604] Possible mojibake in pwd.getpwnam and grp.getgrnam
In-Reply-To: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>
Message-ID: <1536677432.38.0.0269046726804.issue34604@psf.upfronthosting.co.za>


Change by William Grzybowski <william88 at gmail.com>:


----------
pull_requests: +8608

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34604>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:52:40 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 11 Sep 2018 14:52:40 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1536677560.37.0.0269046726804.issue34569@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for bringing this up, Michael.  I'll give you a review on the PR sometime this week (while at the core sprint).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34569>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:53:47 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 11 Sep 2018 14:53:47 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1536677627.91.0.0269046726804.issue34579@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34579>
_______________________________________

From report at bugs.python.org  Tue Sep 11 10:59:35 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 11 Sep 2018 14:59:35 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1536677975.9.0.0269046726804.issue34553@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There's not enough information in the issue to be sure, but I'm inclined to say this is a 3th-party problem.  To be sure someone will have to reproduce the problem in a debugger, or provide a stack trace of the crash.

The initial message says there's a crash when using pywin32 to access particular COM APIs, and msg324713 says that the same thing can happen when using PyQt.

Either project is 3th-party, as is the actual COM dispatch machinery in Windows. And the past has shown that crashes that happen when 3th-party extensions are involved are almost never due to bugs in CPython.

@erikjanss: I'm assuming that you mean that using PyQt to access and outlook COM API can cause a crash, is that correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:04:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 15:04:47 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536678287.61.0.0269046726804.issue28617@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think that "types that are :term:`iterable` or implement the :meth:`__contains__` method" is too low-level for this section.

In this section we tell about builtin types. From those the types that support `in` and `not in` are list, tuple, dict, set, frozenset, str, bytes, bytearray, memoryview, and iterator types. We can just enumerate them or use general word. Calling the "sequence types" is not correct, but fortunately all of them are iterable, so that we can say just "iterable types described below". Or enumerate categories of types, as they are named in the below subsections: "iterator types, sequence types, str, binary sequence types, set types and dict", with links to corresponding subsections.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:25:09 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 15:25:09 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
In-Reply-To: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>
Message-ID: <1536679509.34.0.0269046726804.issue32490@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The builtin exception is better now, so I don't see a problem with reverting the original patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:32:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 15:32:58 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1536679978.7.0.0269046726804.issue34465@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See issue27572 for moving in opposite direction. Supporting the buffer protocol rather of just bytes and bytearray complicates the code, and can be considered as a feature creep, especially if an input is a text encoded as bytes.

But in this case the bytes argument of IPv4Address() is not a text representation like b'127.0.0.1', but a packed array of bytes like bytes([127, 0, 0, 1]). Accepting bytearray and memoryview makes more sense for it. Yet I'm not sure that supporting them is worth adding an overhead. This will affect every call of the IPv4Address constructor, and I think that this is not the most common case.

Maybe add a special purposed named constructor IPv4Address.from_bytes() that will accept any objects supporting the buffer protocol?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:33:27 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Sep 2018 15:33:27 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536680007.5.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +8609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:52:43 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Sep 2018 15:52:43 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536681163.35.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 3102e24d83315eee42a94c460956fbcb92ac510f by Ned Deily in branch 'master':
bpo-34405: Update to OpenSSL 1.1.0i for macOS installer builds (GH-9166)
https://github.com/python/cpython/commit/3102e24d83315eee42a94c460956fbcb92ac510f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:53:01 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 15:53:01 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536681181.03.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8610

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 11:54:10 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 15:54:10 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
In-Reply-To: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>
Message-ID: <1536681250.81.0.0269046726804.issue32490@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 73870bfeb9cf350d84ee88bd25430c104b3c6191 by Benjamin Peterson (Zackery Spytz) in branch 'master':
closes bpo-32490: Fix filename duplication in subprocess exception message. (GH-9163)
https://github.com/python/cpython/commit/73870bfeb9cf350d84ee88bd25430c104b3c6191


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:00:40 2018
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 11 Sep 2018 16:00:40 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1536681640.48.0.0269046726804.issue34443@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Serhiy said:
-----------
> I think using more longer name in repr and/or str for *instances* of
> enum classes is not good idea. They are already verbose, and this
> will make them more verbose.

I'm okay with verbose reprs, as debugging is the primary feature for those (at least for me).  I'm not okay with __str__ being other than what it is now (but see below).

Serhiy also said:
----------------
> Actually in some cases when enum instances are exposed as module
> globals, I would want to make them including the module name instead
> of the enum class name. For example:
> 
> >>> import socket
> >>> socket.AF_UNIX
> <AddressFamily.AF_UNIX: 1>
> >>> print(socket.AF_UNIX)
> AddressFamily.AF_UNIX
>
> "socket.AF_UNIX" instead of "AddressFamily.AF_UNIX" would look better
> to me.

Since AddressFamily, and other stdlib converted constants, are created user `_convert`, I have no problem with that method also changing the __str__ to be `module.member' instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:07:16 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Sep 2018 16:07:16 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536682036.67.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 3235fac0d7d94ad6464a162261c18a424829d2e5 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-34405: Update to OpenSSL 1.1.0i for macOS installer builds (GH-9166) (GH-9167)
https://github.com/python/cpython/commit/3235fac0d7d94ad6464a162261c18a424829d2e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:33:16 2018
From: report at bugs.python.org (Niklas Sombert)
Date: Tue, 11 Sep 2018 16:33:16 +0000
Subject: [issue34628] urllib.request.urlopen fails when userinfo is present in
 URL
Message-ID: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>


New submission from Niklas Sombert <niklas at ytvwld.de>:

Today I tried to access URLs like this one: http://user:1234 at example.net:8080.

The result was this:
>>> import urllib.request
>>> urllib.request.urlopen("http://user:1234 at example.net:1234/")
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/urllib/request.py", line 1317, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/local/lib/python3.7/http/client.py", line 1229, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/local/lib/python3.7/http/client.py", line 1275, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/local/lib/python3.7/http/client.py", line 1224, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/local/lib/python3.7/http/client.py", line 1016, in _send_output
    self.send(msg)
  File "/usr/local/lib/python3.7/http/client.py", line 956, in send
    self.connect()
  File "/usr/local/lib/python3.7/http/client.py", line 928, in connect
    (self.host,self.port), self.timeout, self.source_address)
  File "/usr/local/lib/python3.7/socket.py", line 707, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/local/lib/python3.7/socket.py", line 748, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name does not resolve

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/local/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1345, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1319, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno -2] Name does not resolve>


At first, I checked my network connection, but that turned out to be okay. Even funnier:

>>> urllib.request.urlopen("http://user:1234 at example.net/")     
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/http/client.py", line 877, in _get_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int() with base 10: '1234 at example.net'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/local/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1345, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1285, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
  File "/usr/local/lib/python3.7/http/client.py", line 841, in __init__
    (self.host, self.port) = self._get_hostport(host, port)
  File "/usr/local/lib/python3.7/http/client.py", line 882, in _get_hostport
    raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
http.client.InvalidURL: nonnumeric port: '1234 at example.net'

So, urllib seems to have problems parsing HTTP URLs which contain a userinfo part. (Requests works.)

----------
components: Library (Lib)
messages: 325022
nosy: ytvwld
priority: normal
severity: normal
status: open
title: urllib.request.urlopen fails when userinfo is present in URL
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34628>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:34:16 2018
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 11 Sep 2018 16:34:16 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1536683656.32.0.0269046726804.issue34443@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Okay, I might be changing my mind.  In most cases I suspect the difference would be minimal, but when it isn't, it really isn't.  Take this example from a pydoc test:

  class Color(enum.Enum)
   |  Color(value, names=None, *, module=None, qualname=None, type=None, start=1)
   |  
   |  An enumeration.
   |  
   |  Method resolution order:
   |      Color
   |      enum.Enum
   |      builtins.object
   |  
   |  Data and other attributes defined here:
   |  
-  |  blue = <test.test_enum.TestStdLib.Color.blue: 3>
+  |  blue = <Color.blue: 3>
   |  
-  |  green = <test.test_enum.TestStdLib.Color.green: 2>
+  |  green = <Color.green: 2>
   |  
-  |  red = <test.test_enum.TestStdLib.Color.red: 1>
+  |  red = <Color.red: 1>

It feels like the important information is completely lost in the noise.

Okay, I'm rejecting the __repr__ changes.  Besides the potential verbosity, there should usually only be one of any particular Enum, __module__ and __qualname__ are both readily available when there are more than one (either on accident or by design), and users can modify their own __repr__s if they like.

I'm still thinking about the change in _convert_ to modify __str__ to use the module name instead of the class name....  Here are my questions about that:

- Modify just __str__ or __repr__ as well?
    socket.AF_UNIX instead of AddressFamily.AF_UNIX
    <socket.AddressFamily.AF_UNIX: 1> instead of <AddressFamily.AF_UNIX: 1>

- potential confusion that actual instances of Enum in the stdlib appear
  differently than "regular" Enums?  Or perhaps call out those differences
  in the documentation as examples of customization?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:35:00 2018
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Tue, 11 Sep 2018 16:35:00 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1536683700.34.0.0269046726804.issue34465@psf.upfronthosting.co.za>


J?rn Heissler <launchpad at joern.heissler.de> added the comment:

> Maybe add a special purposed named constructor IPv4Address.from_bytes() that will accept any objects supporting the buffer protocol?

That would work for me.
I wonder if there should be something like ipaddress.ip_address_from_bytes too that can construct IPv4Adress or IPv6Address.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:36:09 2018
From: report at bugs.python.org (Thibault Kruse)
Date: Tue, 11 Sep 2018 16:36:09 +0000
Subject: [issue34629] Python3 regression for urllib(2).urlopen(...).fp for
 chunked http responses
Message-ID: <1536683769.28.0.0269046726804.issue34629@psf.upfronthosting.co.za>


New submission from Thibault Kruse <pandora1234 at mt2015.com>:

We had a problem running code that downloads files from github when porting from python2.7 to python3.[3-7]. Not sure if a bug or not.

With the given code, in python3 a file downloaded in chunks will contain the size of chunks when using the undocumented fp from urlopen(...).fp. In python2, only the chunk payload would make it into the file.

We assume that we can just use the urlopen response directly as a fix (without '.fp'), but though it might still be nice to report the difference.

Short code:
resp = urlopen('http://someurl')
fhand = os.fdopen(fdesc, "wb")
shutil.copyfileobj(resp.fp, fhand)   # using .fp here is the dodgy part
fhand.close()

The attached script demonstrates the difference:

$ python --version
Python 2.7.15rc1
$ python urllib_issue.py 
127.0.0.1 - - [12/Sep/2018 01:27:28] "GET /downloads/1.0.tar.gz HTTP/1.1" 200 -

$ python3 --version
Python 3.6.5
$ python3 urllib_issue.py 
127.0.0.1 - - [12/Sep/2018 01:27:37] "GET /downloads/1.0.tar.gz HTTP/1.1" 200 -
Traceback (most recent call last):
  File "urllib_issue.py", line 87, in <module>
    assert data == FILE_CONTENT, '%s, %s'%(len(FILE_CONTENT), len(data))
AssertionError: 100000, 100493
!!! BASH reports ERROR: shell returned 1

----------
components: Library (Lib)
files: urllib_issue.py
messages: 325025
nosy: tkruse
priority: normal
severity: normal
status: open
title: Python3 regression for urllib(2).urlopen(...).fp for chunked http responses
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47796/urllib_issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34629>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:37:45 2018
From: report at bugs.python.org (Erik Janssens)
Date: Tue, 11 Sep 2018 16:37:45 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1536683865.44.0.0269046726804.issue34553@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

@ronaldoussoren In my case it was not Outlook, it was a third party line of business application,
but as in the case of the OP, as mentioned in the StackOverflow link, the crashing only happens using certain Python version.

I'm not suggesting the issue of the OP (nor mine) is in CPython.  But it's strange at least that it depends on the Python version, and that it does not crash when using the REPL (I did try to compensate for delays etc.).

I took the PyQt route to 'proof' the issue is not related to pywin32.

When running it in a debugger, the crash happens in an MFC dll, after the Invoke of the COM method.

So my guess is the issue is related to some incompatibility in MSVC libraries between CPython and the line of business application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:40:52 2018
From: report at bugs.python.org (Erik Janssens)
Date: Tue, 11 Sep 2018 16:40:52 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1536684052.13.0.0269046726804.issue34553@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

@vijay may I suggest you try to investigate your issue in more detail :

- does it depend on the Python version ?  If so which versions work, which dont.

- does the crash happen as well when using the REPL ?

- if you use PyQt instead of pywin32, does it still crash ?

Not that any of these suggestions will lead to a clear solution, but it might at least rule out some things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:51:32 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 16:51:32 +0000
Subject: [issue29832] Don't refer to getsockaddrarg in error messages
In-Reply-To: <1489732997.44.0.201686346308.issue29832@psf.upfronthosting.co.za>
Message-ID: <1536684692.73.0.0269046726804.issue29832@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 735171e33486131d93865cf851c0c3d63fffd364 by Benjamin Peterson (Oren Milman) in branch 'master':
closes bpo-29832: Remove "getsockaddrarg" from error messages. (GH-3163)
https://github.com/python/cpython/commit/735171e33486131d93865cf851c0c3d63fffd364


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29832>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:54:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Sep 2018 16:54:44 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536684884.68.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 7c7605ff1133cf757cac428c483827f666c7c827 by Yury Selivanov in branch 'master':
bpo-33649: First asyncio docs improvement pass (GH-9142)
https://github.com/python/cpython/commit/7c7605ff1133cf757cac428c483827f666c7c827


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:58:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Sep 2018 16:58:02 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536685082.23.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The first PR has been just landed.

The plan is to work in 'master' branch and when the docs are ready we backport them to 3.7 in one big PR.

So far the following files were updated/reviewed:

     Doc/library/asyncio-eventloop.rst
     Doc/library/asyncio-eventloops.rst -> Doc/library/asyncio-policy.rst
     Doc/library/asyncio-exceptions.rst
     Doc/library/asyncio-platforms.rst 
     Doc/library/asyncio-policy.rst    
     Doc/library/asyncio-protocol.rst  
     Doc/library/asyncio-queue.rst     
     Doc/library/asyncio-stream.rst    
     Doc/library/asyncio-subprocess.rst 

Please feel free to submit PR to fix/improve the above (but not other files as I'm going to be making some heavy edit passes on them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:58:11 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 16:58:11 +0000
Subject: [issue33986] asyncio: Typo in documentation: BaseSubprocessTransport
 -> SubprocessTransport
In-Reply-To: <1530139574.74.0.56676864532.issue33986@psf.upfronthosting.co.za>
Message-ID: <1536685091.28.0.0269046726804.issue33986@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Superseded by #33649

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> asyncio docs overhaul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33986>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:59:29 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 16:59:29 +0000
Subject: [issue34630] Don't log ssl cert errors in asyncio
Message-ID: <1536685169.66.0.0269046726804.issue34630@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

It is reported as a regular exception, not need to log it (as we skip logging of connection errors already).

----------
messages: 325032
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Don't log ssl cert errors in asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34630>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:04:37 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 17:04:37 +0000
Subject: [issue34630] Don't log ssl cert errors in asyncio
In-Reply-To: <1536685169.66.0.0269046726804.issue34630@psf.upfronthosting.co.za>
Message-ID: <1536685477.63.0.0269046726804.issue34630@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +8611
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34630>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:13:08 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 17:13:08 +0000
Subject: [issue34622] Extract asyncio exceptions into a separate file
In-Reply-To: <1536608664.91.0.56676864532.issue34622@psf.upfronthosting.co.za>
Message-ID: <1536685988.0.0.0269046726804.issue34622@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 0baa72f4b2e7185298d09cf64c7b591efcd22af0 by Andrew Svetlov in branch 'master':
bpo-34622: Extract asyncio exceptions into a separate module (GH-9141)
https://github.com/python/cpython/commit/0baa72f4b2e7185298d09cf64c7b591efcd22af0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34622>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:13:30 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 17:13:30 +0000
Subject: [issue34622] Extract asyncio exceptions into a separate file
In-Reply-To: <1536608664.91.0.56676864532.issue34622@psf.upfronthosting.co.za>
Message-ID: <1536686010.55.0.0269046726804.issue34622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34622>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:13:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Sep 2018 17:13:46 +0000
Subject: [issue34631] Upgrade to OpenSSL 1.1.1
Message-ID: <1536686026.27.0.0269046726804.issue34631@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL 1.1.1 was released today. The blog post https://www.openssl.org/blog/blog/2018/09/11/release111/ lists all major improvements.

Highlights:
* TLS 1.3
* API and ABI compatible with OpenSSL 1.1.0
* LTS release (support schedule TBD)

All tests on master are passing with OpenSSL 1.1.1. I still want to hold off and wait a couple of patch releases, before we start to ship Windows and macOS builds with 1.1.1. Some aspects of the TLS 1.3 handshake are different to TLS 1.2. I might have to implement some additional APIs for post handshake authentication.

----------
assignee: christian.heimes
components: SSL
messages: 325034
nosy: alex, christian.heimes, dstufft, janssen
priority: normal
severity: normal
status: open
title: Upgrade to OpenSSL 1.1.1
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34631>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:29:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 17:29:52 +0000
Subject: [issue29386] select.epoll.poll may behave differently if timeout = -1
 vs timeout = None
In-Reply-To: <1485671321.44.0.0475790676768.issue29386@psf.upfronthosting.co.za>
Message-ID: <1536686992.66.0.0269046726804.issue29386@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset b690b9b04729ba3d91c59bff1bb11c3dcc1b50fc by Berker Peksag in branch 'master':
bpo-29386: Pass -1 to epoll_wait() when timeout is < -1 (GH-9040)
https://github.com/python/cpython/commit/b690b9b04729ba3d91c59bff1bb11c3dcc1b50fc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29386>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:30:58 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 17:30:58 +0000
Subject: [issue29386] select.epoll.poll may behave differently if timeout = -1
 vs timeout = None
In-Reply-To: <1485671321.44.0.0475790676768.issue29386@psf.upfronthosting.co.za>
Message-ID: <1536687058.22.0.0269046726804.issue29386@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29386>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:33:43 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 17:33:43 +0000
Subject: [issue26502] traceback.extract_tb breaks compatibility by returning
 FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536687223.95.0.0269046726804.issue26502@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for merging this, Petr. What do you think about backporting to 3.7?

----------
components:  -Documentation
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26502>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:44:56 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 17:44:56 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536687896.67.0.0269046726804.issue28617@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 08bcf647d8a92e4bd47531588b284c6820b7a7ef by Miss Islington (bot) (wim glenn) in branch 'master':
bpo-28617 Fixed docs inaccuracies about the types that support membership tests (GH-9086)
https://github.com/python/cpython/commit/08bcf647d8a92e4bd47531588b284c6820b7a7ef


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:45:41 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 17:45:41 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536687941.38.0.0269046726804.issue28617@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8612

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:45:51 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 17:45:51 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536687951.55.0.0269046726804.issue28617@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8613

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:49:10 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 17:49:10 +0000
Subject: [issue26502] traceback.extract_tb breaks compatibility by returning
 FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536688150.43.0.0269046726804.issue26502@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

I don't think I have a good enough feel for what should, generally, go to 3.7. So take my opinion with a grain of salt.

But honestly, I don't think the issue is important enough -- I've only seen one codebase affected by it, which wasn't hard to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26502>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:52:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 17:52:22 +0000
Subject: [issue34629] Python3 regression for urllib(2).urlopen(...).fp for
 chunked http responses
In-Reply-To: <1536683769.28.0.0269046726804.issue34629@psf.upfronthosting.co.za>
Message-ID: <1536688342.01.0.0269046726804.issue34629@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34629>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:52:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 17:52:41 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536688361.49.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:53:47 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 17:53:47 +0000
Subject: [issue31704] HTTP check lowercase response from proxy
In-Reply-To: <1507211520.07.0.213398074469.issue31704@psf.upfronthosting.co.za>
Message-ID: <1536688427.66.0.0269046726804.issue31704@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The spec, https://tools.ietf.org/html/rfc7230#section-2.6, is quite clear that the HTTP version is case sensitive. In practice, not every client is lax. Firefox does a case-insensitive comparison, but libcurl requires uppercase. That makes me think we can safely stay strict.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31704>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:54:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 17:54:09 +0000
Subject: [issue34628] urllib.request.urlopen fails when userinfo is present in
 URL
In-Reply-To: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>
Message-ID: <1536688449.96.0.0269046726804.issue34628@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34628>
_______________________________________

From report at bugs.python.org  Tue Sep 11 13:54:10 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 17:54:10 +0000
Subject: [issue26502] traceback.extract_tb breaks compatibility by returning
 FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536688450.83.0.0269046726804.issue26502@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Ok, let's close this issue then.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26502>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:00:57 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 11 Sep 2018 18:00:57 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536688857.23.0.0269046726804.issue34600@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

lxml supports "comment" and "pi" as event types in iterparse (or, more specifically, in the XMLPullParser). If someone wants to implement this for (c)ElementTree, I'd be happy to review the PR.

https://lxml.de/api/lxml.etree.XMLPullParser-class.html

----------
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34600>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:13:38 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:13:38 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536689618.22.0.0269046726804.issue28617@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3e648f8371e342ccfa663ad77e82a538fcc8c9fb by Miss Islington (bot) in branch '3.7':
bpo-28617 Fixed docs inaccuracies about the types that support membership tests (GH-9086)
https://github.com/python/cpython/commit/3e648f8371e342ccfa663ad77e82a538fcc8c9fb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:16:43 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 11 Sep 2018 18:16:43 +0000
Subject: [issue34632] Port importlib_metadata to Python 3.8
Message-ID: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

https://importlib_metadata.rtfd.org

We're fleshing out the API and implementation in the standalone library, but once we're confident of the API and semantics, we will want to port this into Python 3.8.

----------
assignee: barry
components: Library (Lib)
messages: 325043
nosy: barry, brett.cannon, jason.coombs
priority: normal
severity: normal
status: open
title: Port importlib_metadata to Python 3.8
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34632>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:18:19 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:18:19 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536689899.76.0.0269046726804.issue28617@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 889f080a4d5cdb1cfb901b953f4b89f3ea806bbe by Miss Islington (bot) in branch '3.6':
bpo-28617 Fixed docs inaccuracies about the types that support membership tests (GH-9086)
https://github.com/python/cpython/commit/889f080a4d5cdb1cfb901b953f4b89f3ea806bbe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:34:52 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 18:34:52 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536690892.38.0.0269046726804.issue34595@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

> The PEP 399 requires that C accelerator behaves exactly as Python, [...]

It does not. PEP 399 requires that that the C code must pass the same *test suite*. And error messages in particular tend to not be checked in tests.

Anyway, I don't see how that applies to replacing `Py_TYPE(obj)->tp_name` by `%T`. The real reason for *that* change is removing borrowed references, right?
I have not yet seen a good reason why Py_TYPE(obj) is bad. The reasons you give in https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references are about tagged pointers and PyList_GetItem(), but Py_TYPE() is very different.

I don't think the reasons are strong enough to add new API to PyUnicode_FromFormat().

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:36:03 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Sep 2018 18:36:03 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536690963.87.0.0269046726804.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

The question here is: what should asdict() return if the dataclass contains a namedtuple? What the code is trying to do (but currently failing!) is to return another namedtuple, but with the values returned by recursively calling in to asdict() (or rather, its helper function) for each field in the namedtuple.

I think this is the correct behavior. Specifically, I do not want to call the namedtuple's _asdict() method. There are two problems with _asdict():

1. It doesn't recurse in to the fields, like asdict() normally does with a dict, list, or tuple.

2. It returns a dict! This is a problem because if a dataclass field contains a dict which has a key which is a namedtuple, then asdict() would fail.

Here's an example of #2 above, if asdict() on a namedtuple field returns a dict:

@dataclass
class C:
    f: 'Any'

T = namedtuple('T', 'a')

c = C({T('an a'): 0})
print('c:', c)
print(asdict(c))   # <- error here

prints:

c: C(f={T(a='an a'): 0})
Traceback (most recent call last):
...
  File "/home/eric/python/lib/dataclasses.py", line 1019, in asdict
    return _asdict_inner(obj, dict_factory)
  File "/home/eric/python/lib/dataclasses.py", line 1026, in _asdict_inner
    value = _asdict_inner(getattr(obj, f.name), dict_factory)
  File "/home/eric/python/lib/dataclasses.py", line 1059, in _asdict_inner
    for k, v in obj.items())
TypeError: unhashable type: 'collections.OrderedDict'

So, although it's unfortunate, I think the only reasonable thing to do in this case is to have asdict() on a namedtuple return another namedtuple. Here's how that looks using the above code:

c: C(f={T(a='an a'): 0})
{'f': {T(a='an a'): 0}}

Admittedly, this can't be used with json.dumps() (you get "TypeError: keys must be str, int, float, bool or None, not T"), but I think it's the best we can do. It's consistent with any other class derived from tuple or list: asdict() will convert it to a copy of the class, recursing into each item that's in the tuple or list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:38:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 18:38:28 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536691108.09.0.0269046726804.issue28617@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Humm, why the bot merges in the master branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:45:31 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:45:31 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536691531.19.0.0269046726804.issue34613@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b4ec36200a959da70eba94c19826446a8efdffdd by Miss Islington (bot) (Bram) in branch 'master':
bpo-34613: document the correct value of limit argument of asyncio.StreamReader (GH-9121)
https://github.com/python/cpython/commit/b4ec36200a959da70eba94c19826446a8efdffdd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34613>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:45:46 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:45:46 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536691546.74.0.0269046726804.issue34613@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8614

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34613>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:45:58 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:45:58 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536691558.46.0.0269046726804.issue34613@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8615

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34613>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:46:58 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 18:46:58 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1536691618.9.0.0269046726804.issue31608@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 24bd50bdcc97d65130c07d6cd26085fd06c3e972 by Benjamin Peterson (Oren Milman) in branch 'master':
closes bpo-31608: Fix a crash in methods of a subclass of _collections.deque with a bad __new__(). (GH-3788)
https://github.com/python/cpython/commit/24bd50bdcc97d65130c07d6cd26085fd06c3e972


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:47:08 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:47:08 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1536691628.27.0.0269046726804.issue31608@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8616

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:57:51 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:57:51 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536692271.63.0.0269046726804.issue34613@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cb51dd7cac6a6e2a7ba67fa4cd328a68f630095b by Miss Islington (bot) in branch '3.6':
bpo-34613: document the correct value of limit argument of asyncio.StreamReader (GH-9121)
https://github.com/python/cpython/commit/cb51dd7cac6a6e2a7ba67fa4cd328a68f630095b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34613>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:58:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 18:58:13 +0000
Subject: [issue34600] python3 regression ElementTree.iterparse() unable to
 capture comments
In-Reply-To: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>
Message-ID: <1536692293.59.0.0269046726804.issue34600@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Than your for your example Martin. Now I see what is not working. Indeed, using the TreeBuilder subclass is recommended way, but iterparse() was designed to accept only exact TreeBuilder. Actually there is an intention to consider the parser parameter of iterparse() as internal and remove it from the public API (also the deprecation warning is not emitted yet).

I don't see a way to fix this. Since this feature never worked in Python 3, and the Python 2 way looks as using implementation details, I think we should consider adding it as a new feature rather of a buf fix. Adding support of "comment" and "pi" as event types in iterparse looks reasonable to me. Eli, what are your thoughts?

I agree with you Marting that using your own copy from the source code is the best way of solving your problem on current Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34600>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:59:25 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 18:59:25 +0000
Subject: [issue31636] test_locale failure on OpenBSD
In-Reply-To: <1506677973.45.0.213398074469.issue31636@psf.upfronthosting.co.za>
Message-ID: <1536692365.41.0.0269046726804.issue31636@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8617
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31636>
_______________________________________

From report at bugs.python.org  Tue Sep 11 14:59:33 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:59:33 +0000
Subject: [issue34613] asyncio.StreamReader initialization documentation
 incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536692373.88.0.0269046726804.issue34613@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e02ca4270ef258162215e345c23025bec27f9eb0 by Miss Islington (bot) in branch '3.7':
bpo-34613: document the correct value of limit argument of asyncio.StreamReader (GH-9121)
https://github.com/python/cpython/commit/e02ca4270ef258162215e345c23025bec27f9eb0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34613>
_______________________________________

From report at bugs.python.org  Tue Sep 11 15:01:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 19:01:38 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1536692498.84.0.0269046726804.issue31608@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8618

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Sep 11 15:01:53 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Sep 2018 19:01:53 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1536692513.71.0.0269046726804.issue34409@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I've been thinking about this, but I don't have a suggestion on how to improve the API. Maybe some sort of visitor pattern? I'm open to concrete ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Tue Sep 11 15:08:15 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 19:08:15 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1536692895.1.0.0269046726804.issue31608@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 536e45accf8f05355dd943a6966b9968cdb15f5a by Miss Islington (bot) in branch '3.7':
closes bpo-31608: Fix a crash in methods of a subclass of _collections.deque with a bad __new__(). (GH-3788)
https://github.com/python/cpython/commit/536e45accf8f05355dd943a6966b9968cdb15f5a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Sep 11 15:12:46 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 19:12:46 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1536693166.39.0.0269046726804.issue31608@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset ccbbdd0a1e00ecad6f0005438dd6ff6d84fd9ceb by Benjamin Peterson in branch '3.6':
[3.6] closes bpo-31608: Fix a crash in methods of a subclass of _collections.deque with a bad __new__(). (GH-9178)
https://github.com/python/cpython/commit/ccbbdd0a1e00ecad6f0005438dd6ff6d84fd9ceb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:21:27 2018
From: report at bugs.python.org (Zahari Dim)
Date: Tue, 11 Sep 2018 20:21:27 +0000
Subject: [issue34586] collections.ChainMap should have a get_where method
In-Reply-To: <1536625736.57.0.0269046726804.issue34586@psf.upfronthosting.co.za>
Message-ID: <CANx7HSZSXmK0BZVA+J81OfmhpuhuQSUdB4H4QxXpKvOKZce5gg@mail.gmail.com>


Zahari Dim <zaharid at gmail.com> added the comment:

>
> I've discussed this with other core devs and spent a good deal of time evaluating this proposal.  I'm going to pass on the this one but do think it was a inspired suggestion.  Thank you for the proposal.

Thank you for taking the time to consider it. I understand that there
are many proposals.

>
> ----------
>
> Note, the original get_where() recipe has an issue.  Upon successful lookup, it returns a 2-tuple but on failure it calls __missing__ which typically returns a scalar (if it doesn't raise an exception).

FWIW this was intended to work when `__missing__` was subclassed to
raise a more specific exception. The case where it is made to return a
value clearly doesn't play well with the proposed method, and would
likely need to be subclassed as well. I consider this an acceptable
trade off because I find this use case rather esoteric: the same
functionality could be achieved in an arguably clearer way by passing
a mapping with the desired missing semantics as the outermost scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34586>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:42:01 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 20:42:01 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1536698521.48.0.0269046726804.issue31608@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 253279c616d4f34287c5749df15e20eb2eb988d6 by Benjamin Peterson in branch '2.7':
[2.7] closes bpo-31608: Fix a crash in methods of a subclass of _collections.deque with a bad __new__(). (GH-9179)
https://github.com/python/cpython/commit/253279c616d4f34287c5749df15e20eb2eb988d6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:55:01 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 20:55:01 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1536699301.58.0.0269046726804.issue32502@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d919c60e6936f853ad15040017f2c0bce0f027f8 by Benjamin Peterson (Chih-Hsuan Yen) in branch '2.7':
[2.7] bpo-32502: Discard 64-bit (and other invalid) hardware addresses (GH-9125)
https://github.com/python/cpython/commit/d919c60e6936f853ad15040017f2c0bce0f027f8


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:55:58 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 20:55:58 +0000
Subject: [issue15727] PyType_FromSpecWithBases tp_new bugfix
In-Reply-To: <1345391866.4.0.54341725267.issue15727@psf.upfronthosting.co.za>
Message-ID: <1536699358.22.0.0269046726804.issue15727@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Converting static types to heap ones is just one of the reasons to use PyType_FromSpec*. Another ones are writing such classes from scratch, and converting pure-Python classes to C. I don't think PyObject_FailingNew is a good default for either of those.

I think Sehriy's solution in bpo-26979 is better: document this, and allow setting a slot to NULL explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15727>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:59:28 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 20:59:28 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699568.16.0.0269046726804.issue34365@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9c223794c754408644c16349b85dd27fdba8a926 by Miss Islington (bot) (Danish Prakash) in branch 'master':
bpo-34365: Update date object documentation (GH-8814)
https://github.com/python/cpython/commit/9c223794c754408644c16349b85dd27fdba8a926


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:59:47 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 20:59:47 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699587.31.0.0269046726804.issue34365@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8619

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Tue Sep 11 16:59:58 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 20:59:58 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699598.03.0.0269046726804.issue34365@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:00:37 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 21:00:37 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536699637.23.0.0269046726804.issue26979@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

I don't think PEP 384 should be updated. It documents the feature as it was added, and shouldn't be used as documentation now.
Instead, Python documentation should be improved to cover all of PEP 389.
I submitted a pull request for that (GH-9154).

For this issue, the fix should be updating C API documentation and, for Pyhon 3.8+, making {*, NULL} slots override the inherited value.

I think the PyType_Spec/PyType_Slot copying should have its own issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:03:41 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 11 Sep 2018 21:03:41 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699821.53.0.0269046726804.issue34365@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

----------
nosy: +Mariatta
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:17:51 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 11 Sep 2018 21:17:51 +0000
Subject: [issue34633] Simplify __reduce__ for ordered dict.
Message-ID: <1536700671.8.0.0269046726804.issue34633@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

The code for __reduce__ in ordered dictionaries can be simplified in the similar way issue34573 is treating dict and set objects.

----------
components: Interpreter Core
messages: 325063
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Simplify __reduce__ for ordered dict.
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34633>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:18:02 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 21:18:02 +0000
Subject: [issue34634] New asyncio streams API
Message-ID: <1536700682.14.0.0269046726804.issue34634@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Currently, we have separate classes: reader and writer.

It is very inconvenient: these classes are tightly coupled internally, there is no sense to have two objects to the single logical entity.

The second problem is `writer.write()` synchronous API. To support flow control user should call `await writer.drain()` after every `writer.write()` call. But he/she can forget about drain() easy.

`writer.write()` should be softly deprecated in favor of `await writer.send()`. `writer.writelines()` is not very useful, better to merge all buffers before `await stream.send(data)` call. `writelines` should be softly deprecated as well without async replacement.

The last issue is `writer.close()` which should always be used in conjunction with `await writer.wait_closed()`. Let's return a future from `writer.close()`. The encouraged usage becomes `await writer.close()`. 
To immediate closing let's add `writer.abort()` sync function which cleans up resources without waiting for actual closing.

----------
messages: 325064
nosy: asvetlov
priority: normal
severity: normal
status: open
title: New asyncio streams API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34634>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:18:48 2018
From: report at bugs.python.org (mkurnikov)
Date: Tue, 11 Sep 2018 21:18:48 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1536700728.42.0.0269046726804.issue34409@psf.upfronthosting.co.za>


mkurnikov <maxim.kurnikov at gmail.com> added the comment:

Cleanest thing I could think of is:

1. Extract dataclass_to_dict function from _asdict_inner as:

def dataclass_asdict(obj, dict_factory):
    result = []
    for f in fields(obj):
        value = _asdict_inner(getattr(obj, f.name), dict_factory)
        result.append((f.name, value))
    return dict_factory(result)

2. Add "asdict" parameter to the dataclass decorator (with default value of dataclass_to_dict function)

@dataclass(asdict=specific_dcls_dict_factory)
class MyDataclass:
    pass

3. Change check to 

def _asdict_inner(obj, dict_factory):
    if _is_dataclass_instance(obj):
        return getattr(obj, _PARAMS).asdict(obj) 

    # ... other code


Other solution could be to add parameter "directly_serializable"(smth like that), add check for this parameter

def _asdict_inner(obj, dict_factory):
    if _is_dataclass_instance(obj):
        if getattr(obj, _PARAMS).directly_serializable: 
            return dict_factory(obj)

    # ... other code

and force user to process everything in dict_factory function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:18:54 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 21:18:54 +0000
Subject: [issue34634] New asyncio streams API
In-Reply-To: <1536700682.14.0.0269046726804.issue34634@psf.upfronthosting.co.za>
Message-ID: <1536700734.91.0.0269046726804.issue34634@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +8621
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34634>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:19:17 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 11 Sep 2018 21:19:17 +0000
Subject: [issue34633] Simplify __reduce__ for ordered dict.
In-Reply-To: <1536700671.8.0.0269046726804.issue34633@psf.upfronthosting.co.za>
Message-ID: <1536700757.22.0.0269046726804.issue34633@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8622
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34633>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:24:56 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 21:24:56 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536701096.46.0.0269046726804.issue34365@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e2b40f4ce954ea3d35a73541029b2253abd9d245 by Miss Islington (bot) in branch '3.7':
bpo-34365: Update date object documentation (GH-8814)
https://github.com/python/cpython/commit/e2b40f4ce954ea3d35a73541029b2253abd9d245


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:27:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 21:27:09 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536701229.89.0.0269046726804.issue34365@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8a2c2d4e1b6b46a9a982e5c064ca4399ec28d55d by Miss Islington (bot) in branch '3.6':
bpo-34365: Update date object documentation (GH-8814)
https://github.com/python/cpython/commit/8a2c2d4e1b6b46a9a982e5c064ca4399ec28d55d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:35:42 2018
From: report at bugs.python.org (Benjamin Mintz)
Date: Tue, 11 Sep 2018 21:35:42 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
Message-ID: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>


New submission from Benjamin Mintz <benjabean1 at gmail.com>:

Adds inspect.getsubclasses, inspect.getallsubclasses (recursive), and inspect.getsubclasstree (recursive, maintains structure).

See documentation for more details.

----------
components: Library (Lib)
messages: 325068
nosy: bmintz
priority: normal
severity: normal
status: open
title: inspect: add tools for inspecting subclasses
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:36:23 2018
From: report at bugs.python.org (Benjamin Mintz)
Date: Tue, 11 Sep 2018 21:36:23 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
In-Reply-To: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>
Message-ID: <1536701783.5.0.0269046726804.issue34635@psf.upfronthosting.co.za>


Change by Benjamin Mintz <benjabean1 at gmail.com>:


----------
keywords: +patch
pull_requests: +8623
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:36:26 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Tue, 11 Sep 2018 21:36:26 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1536701786.83.0.0269046726804.issue34538@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

I?d like to try to steer this conversation back toward what I think is the actionable question: ?does the exemplification of this practice in the Errors and Exceptions portion of The Python Tutorial bring about a net benefit or a net cost to its intended audience??.

What is the benefit? It is that when an author happens to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type* the author is led to define an intermediate class between Exception and the directly-used user-defined Exception subclasses capturing that type in a usable code element.

What readers of the tutorial enjoy this benefit? Pretty much only those authors (who happen to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type*) who are still learning about classes and inheritance. That?s a doubly slim population, isn?t it? Maybe also those who kind of know, but aren?t so sure and could use some reinforcement from seeing in the tutorial something that they independently did on their own in their own code. I wouldn?t think that authors who already know with confidence and from experience about classes and inheritance would benefit from the example in the tutorial, so ?In my experience as a teacher, the possibility doesn't usually occur to people without it having been suggested? comes as a surprise to me. But? okay, them too - but again, only when they happen to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type*.

What is the cost? It is that when an author happens to be authoring a module that does *not* have the property that all user-defined Exception subclasses satisfy some more-specific-than-Exception type, the common intermediate class is just bloat. It?s noise disrupting the signal. It undermines the API design advice ?when in doubt, leave it out?. It unnecessarily widens the module?s API. It undermines the API design advice ?classes are the most complex kind of code element in common use so they have the highest value proposition to satisfy to justify their existence?. It violates the Liskov Substitution Principle. Maybe most importantly, it obscures other relationships among the user-defined Exception subclasses in the module such as a superclass shared by some-but-not-all of the module?s user-defined Exception subclasses, if such other relationships exist.

What readers of the tutorial pay this cost? Those who are still learning the language. And those who are following pattern and convention - note that the tutorial contains only one example of user-defined Exception subclasses, and? an unfortunate fact of life of tutorials is that readers are invited to generalize from single examples. And, as I think we?ve seen in this conversation, those who just picked up the practice at one point and have kept it going.

The Exception subclass hierarchy of sqlite3 that was mentioned earlier in this conversation demonstrates exactly this bloat and misapplication - there?s Warning, which is a direct subclass of Exception, and there?s Error, which is also a direct subclass of Exception and has the erroneous specification ?The base class of the other exceptions in this module?, and there?s DatabaseError, which is a subclass of Error, and then there are IntegrityError, ProgrammingError, OperationalError, and NotSupportedError, which inherit from DatabaseError. What?s the use of Error? There are no code elements in the module specified as raising Error. There?s example code in the module showing ?except sqlite3.Error?, but why shouldn?t that be ?except sqlite3.DatabaseError??

It?s a red herring is that the practice appears widely applied in existing Python code - well of course; it?s been exemplified in the tutorial for seventeen years! :-P

One last thing to consider: look at the example specifically - InputError and TransitionError. There?s no elsewhere-in-the-module example code showing a function that has ?Error? in its ?Raises:? specification and could raise either an InputError or a TransitionError, and there?s no outside-of-the-module example code showing a user of the module calling a module function and saving duplicated lines of code because they want to respond to InputErrors and TransitionErrors in exactly the same way.

We should remove the ?Base class for exceptions in this module? Error class from the tutorial?s example because it just isn?t beneficial enough, in enough applicable modules, to enough authors, and it?s more than costly enough, in enough modules to which it doesn?t apply, and to enough authors, even just as noise and API bloat. I don?t know that this could have been calculated from first principles seventeen years ago; I think perhaps it took the experience of having the guidance out there, so rarely merited and so widely implemented, to see it being a net drag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:38:49 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 11 Sep 2018 21:38:49 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
In-Reply-To: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>
Message-ID: <1536701929.45.0.0269046726804.issue34635@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:40:00 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 21:40:00 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536702000.67.0.0269046726804.issue26979@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Christian, do you have a specific example of the default tp_dealloc doing the wrong thing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:40:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 11 Sep 2018 21:40:41 +0000
Subject: [issue34633] Simplify __reduce__ for ordered dict iterators
In-Reply-To: <1536700671.8.0.0269046726804.issue34633@psf.upfronthosting.co.za>
Message-ID: <1536702041.51.0.0269046726804.issue34633@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
title: Simplify __reduce__ for ordered dict. -> Simplify __reduce__ for ordered dict iterators

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34633>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:45:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 21:45:47 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536702347.71.0.0269046726804.issue34595@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8625

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:45:49 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 21:45:49 +0000
Subject: [issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef,
 AsyncWith
Message-ID: <1536702349.38.0.0269046726804.issue31902@psf.upfronthosting.co.za>


New submission from miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


New changeset 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b by Miss Islington (bot) (guoci) in branch 'master':
closes bpo-31902: Fix the col_offset attribute for ast.Async* nodes to point to the "async" keyword. (GH-4175)
https://github.com/python/cpython/commit/90fc8980bbcc5c7dcced3627fe172b0bfd193a3b


----------
nosy: +miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31902>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:45:59 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 21:45:59 +0000
Subject: [issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef,
 AsyncWith
In-Reply-To: <1536702349.38.0.0269046726804.issue31902@psf.upfronthosting.co.za>
Message-ID: <1536702359.23.0.0269046726804.issue31902@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8626

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31902>
_______________________________________

From report at bugs.python.org  Tue Sep 11 17:49:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Sep 2018 21:49:17 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1536702557.5.0.0269046726804.issue20180@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c4bccd3c7617018b1ce16f95840ffe1a890d44df by Raymond Hettinger (Tal Einat) in branch 'master':
bpo-20180: convert most of itertoolsmodule.c to use Argument Clinic (GH-9164)
https://github.com/python/cpython/commit/c4bccd3c7617018b1ce16f95840ffe1a890d44df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:00:58 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 22:00:58 +0000
Subject: [issue34636] re module microoptimization: speed up bytes \w \s \d
 matching
Message-ID: <1536703258.1.0.0269046726804.issue34636@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

filing this issue to track https://github.com/python/cpython/pull/9170

----------
assignee: gregory.p.smith
messages: 325073
nosy: gregory.p.smith
priority: normal
pull_requests: 8627
severity: normal
status: open
title: re module microoptimization: speed up bytes \w \s \d matching
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34636>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:01:28 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 22:01:28 +0000
Subject: [issue34636] re module microoptimization: speed up bytes \w \s \d
 matching
In-Reply-To: <1536703258.1.0.0269046726804.issue34636@psf.upfronthosting.co.za>
Message-ID: <1536703288.87.0.0269046726804.issue34636@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Confirming the microoptimization here with a non-debug (opt) build:

~/oss/cpython$ sre-before/python -m timeit -s "import re; s = (b'~' * 1000000); f = re.compile(b'\s\w\d').search" "f(s)"
20 loops, best of 5: 11 msec per loop
~/oss/cpython$ sre-after/python -m timeit -s "import re; s = (b'~' * 1000000); f = re.compile(b'\s\w\d').search" "f(s)"
20 loops, best of 5: 10.1 msec per loop

Those results are consistent across reruns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34636>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:02:55 2018
From: report at bugs.python.org (Lisa Roach)
Date: Tue, 11 Sep 2018 22:02:55 +0000
Subject: [issue24412] setUpClass equivalent for addCleanup
In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za>
Message-ID: <1536703375.65.0.0269046726804.issue24412@psf.upfronthosting.co.za>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
pull_requests: +8628
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24412>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:06:33 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 22:06:33 +0000
Subject: [issue33714] module can set an exception in tp_clear
In-Reply-To: <1527769305.39.0.682650639539.issue33714@psf.upfronthosting.co.za>
Message-ID: <1536703593.88.0.0269046726804.issue33714@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

I'm not sure what tp_clear should do in this situation.
Other than propagating the exception to the GC, the most reasonable behavior seems to be to write the exception to stderr and ignore it -- but I think having the GC do that would be more robust.

IOW, I think raising an exception from tp_clear is reasonable, and if that caused (causes?) a crash, it's a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33714>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:09:48 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Sep 2018 22:09:48 +0000
Subject: [issue32055] Reconsider comparison chaining for containment tests
In-Reply-To: <1510904597.47.0.213398074469.issue32055@psf.upfronthosting.co.za>
Message-ID: <1536703788.56.0.0269046726804.issue32055@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I agree that it would be less confusing if `in`/`not in` did not allow chaining, the occasional (surely very rare) useful example notwithstanding.

Then again if we're going to forbid (or even discourage) unusual combinations we might also want to frown at `a < b > c` -- surely in mathematical circles the chaining always goes in one direction only, e.g. `a < b <= c` or `a >= b ==c > d`.

Finally as long as we're refining the terminology, maybe we could strive to distinguish "comparison" (`==` and `!=`) from "ordering" (`<`, `<=`, `>`, `>=`)?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32055>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:09:49 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Sep 2018 22:09:49 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536703789.53.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +8629

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:12:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Sep 2018 22:12:05 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536703925.83.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8630

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:21:14 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 22:21:14 +0000
Subject: [issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef,
 AsyncWith
In-Reply-To: <1536702349.38.0.0269046726804.issue31902@psf.upfronthosting.co.za>
Message-ID: <1536704474.96.0.0269046726804.issue31902@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d8bc7a666b1309aa5669980e35e7429071f3f7d3 by Miss Islington (bot) in branch '3.7':
closes bpo-31902: Fix the col_offset attribute for ast.Async* nodes to point to the "async" keyword. (GH-4175)
https://github.com/python/cpython/commit/d8bc7a666b1309aa5669980e35e7429071f3f7d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31902>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:23:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 22:23:28 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536704608.28.0.0269046726804.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 998b80636690ffbdb0a278810d9c031fad38631d by Victor Stinner in branch 'master':
Revert "bpo-34595: Add %T format to PyUnicode_FromFormatV() (GH-9080)" (GH-9187)
https://github.com/python/cpython/commit/998b80636690ffbdb0a278810d9c031fad38631d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:24:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 22:24:39 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536704679.57.0.0269046726804.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Petr Viktorin asked me to open a wider discussion about this issue on python-dev. I just reverted my first change and posted:
https://mail.python.org/pipermail/python-dev/2018-September/155150.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:28:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 22:28:36 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1536704916.18.0.0269046726804.issue34579@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

What is the output of "./Programs/_testembed init_default_config"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34579>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:29:00 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Sep 2018 22:29:00 +0000
Subject: [issue29051] Improve error reporting involving f-strings (PEP 498)
In-Reply-To: <1482494461.91.0.191852219403.issue29051@psf.upfronthosting.co.za>
Message-ID: <1536704940.19.0.0269046726804.issue29051@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Because this issue describes two different problems, I'm going to close it.

The part of it that involves errors during the evaluation of a syntactically valid expression was at least partially fixed in #30465. I will probably re-work how this fix was implemented.

I'm working on the syntax error part of it in #34364.

----------
dependencies:  -Tracebacks should contain the first line of continuation lines
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29051>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:29:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 22:29:18 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1536704958.8.0.0269046726804.issue34579@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum, you should run "env -i ./Programs/_testembed init_default_config" to run the program in an empty environment. test_embed modifies os.environ to remove all PYTHON* env vars.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34579>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:31:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 22:31:32 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1536705092.75.0.0269046726804.issue26832@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:40:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 22:40:34 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536705634.17.0.0269046726804.issue34605@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8631

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:42:43 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 11 Sep 2018 22:42:43 +0000
Subject: [issue34633] Simplify __reduce__ for ordered dict iterators
In-Reply-To: <1536700671.8.0.0269046726804.issue34633@psf.upfronthosting.co.za>
Message-ID: <1536705763.84.0.0269046726804.issue34633@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34633>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:45:39 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Sep 2018 22:45:39 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536705939.04.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 31912b43c903aafad09350899ed6a9dec7c43421 by Ned Deily in branch '3.6':
bpo-34405: Update to OpenSSL 1.0.2p for macOS installer builds (GH-9191)
https://github.com/python/cpython/commit/31912b43c903aafad09350899ed6a9dec7c43421


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:46:24 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 22:46:24 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536705984.29.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8632

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:48:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 22:48:03 +0000
Subject: [issue34636] re module microoptimization: speed up bytes \w \s \d
 matching
In-Reply-To: <1536703258.1.0.0269046726804.issue34636@psf.upfronthosting.co.za>
Message-ID: <1536706083.04.0.0269046726804.issue34636@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ec014a101a7f6243b95dfc08acfe1542b9fa5d39 by Miss Islington (bot) (Sergey Fedoseev) in branch 'master':
bpo-34636: Use fast path for more chars in SRE category macros. (GH-9170)
https://github.com/python/cpython/commit/ec014a101a7f6243b95dfc08acfe1542b9fa5d39


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34636>
_______________________________________

From report at bugs.python.org  Tue Sep 11 18:52:35 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 11 Sep 2018 22:52:35 +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: <1536706355.7.0.0269046726804.issue32270@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you, Gregory!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32270>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:03:14 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 11 Sep 2018 23:03:14 +0000
Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary
 mode
In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za>
Message-ID: <1536706994.71.0.0269046726804.issue32236@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you, Gregory. I didn't intend to add the warning to stable branches -- it's just that 3.7 hasn't been released yet when this report was submitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32236>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:03:47 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Sep 2018 23:03:47 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1536707027.06.0.0269046726804.issue26832@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:04:35 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 Sep 2018 23:04:35 +0000
Subject: [issue30576] http.server should support HTTP compression (gzip)
In-Reply-To: <1496691724.59.0.955308322691.issue30576@psf.upfronthosting.co.za>
Message-ID: <1536707075.91.0.0269046726804.issue30576@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm agreeing with all the other core devs (other than Victor ;) that I don't quite think this should go in. While I appreciate the work Pierre put into the PR, I just can't find myself to want to deal with future bug reports for this while http.server is meant for really simple testing scenarios.

My suggestion would be to toss it up on PyPI and if there is major uptake then we can revisit this, but right now I just don't think the long-term support costs are worth the benefit the new feature brings.

----------
nosy: +brett.cannon
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30576>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:14:03 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 23:14:03 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536707643.36.0.0269046726804.issue31903@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 4859ba0d2ce4506fddc3f55f90f8dce031b3804f by Benjamin Peterson (Max B?langer) in branch 'master':
closes bpo-31903: Release the GIL when calling into SystemConfiguration (GH-4178)
https://github.com/python/cpython/commit/4859ba0d2ce4506fddc3f55f90f8dce031b3804f


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:18:04 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 23:18:04 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536707884.73.0.0269046726804.issue1621@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6c7d67ce83a62b5f0fe5c53a6df602827451bf7f by Miss Islington (bot) (Sergey Fedoseev) in branch 'master':
bpo-1621: Avoid signed integer overflow in set_table_resize(). (GH-9059)
https://github.com/python/cpython/commit/6c7d67ce83a62b5f0fe5c53a6df602827451bf7f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:18:13 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 23:18:13 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536707893.68.0.0269046726804.issue1621@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8633

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:18:25 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 23:18:25 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536707905.04.0.0269046726804.issue1621@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8634

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:34:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Sep 2018 23:34:59 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
Message-ID: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently, we can write:

    >>> sum(range(10), 50)
    95

What we want to allow:

    >>> sum(range(10), start=50)
    95

The positional form would still be allowed.

----------
assignee: rhettinger
components: Library (Lib)
messages: 325092
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make *start* usable as a keyword argument for sum().
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:37:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 23:37:18 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536709038.77.0.0269046726804.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> (...) the locale should be coerced before *ANY* calls are made to Py_DecodeLocale, as the whole point of the architecture of the PEP implementation was to ensure that *nothing ever gets decoded incorrectly in the first place*.

See my comment:
https://github.com/python/cpython/pull/9073#issuecomment-420461537

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:40:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 23:40:09 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536709209.68.0.0269046726804.issue34605@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fa7dfae3171914f91d629a64c6e829788b485b06 by Miss Islington (bot) (Victor Stinner) in branch 'master':
bpo-34605: Replace "pliant children" with "helpers" (GH-9195)
https://github.com/python/cpython/commit/fa7dfae3171914f91d629a64c6e829788b485b06


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:47:26 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 23:47:26 +0000
Subject: [issue34638] Avoid circular references in asyncio streams
Message-ID: <1536709646.23.0.0269046726804.issue34638@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Now we have a cross-reference between asyncio stream reader and protocol.

It prevents objects deletion on ref-counting and requires a garbage collector run to destroy the stream.

----------
components: asyncio
messages: 325095
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Avoid circular references in asyncio streams
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34638>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:47:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 23:47:42 +0000
Subject: [issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option
Message-ID: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

I modified Py_Main() to ignore the PYTHONCOERCECLOCALE environment variable if -E or -I command line option is used. But Nick asks to always read PYTHONCOERCECLOCALE.

We should either update the PEP or change the code.

I am not sure why PYTHONCOERCECLOCALE should be handled differently than other PYTHON* variable like PYTHONWARNINGS or PYTHONUTF8. Is it because it impacts the encodings? Is it because there was a chicken-and-egg issue before I reworked Py_Main() code? (PYTHONCOERCECLOCALE env var was read before reading command line arguments.)

--

Copy of Nick Coghlan's msg325009:

(The one exception to "nothing gets decoded incorrectly" is that PYTHONCOERCECLOCALE itself is always interpreted as an ASCII field: the values that it checks for are actually ASCII byte sequences, not Unicode code points.

The documentation could definitely be much clearer on that point though, as even in the PEP it's only implied by the final paragraph in https://www.python.org/dev/peps/pep-0538/#legacy-c-locale-coercion-in-the-standalone-python-interpreter-binary which is mostly talking about the fact that this particular environment variable is still checked, even if you pass the -I or -E command line options.

----------
components: Interpreter Core
messages: 325096
nosy: vstinner
priority: normal
severity: normal
status: open
title: PYTHONCOERCECLOCALE is ignored when using -E or -I option
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34639>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:47:52 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 23:47:52 +0000
Subject: [issue34638] Avoid circular references in asyncio streams
In-Reply-To: <1536709646.23.0.0269046726804.issue34638@psf.upfronthosting.co.za>
Message-ID: <1536709672.78.0.0269046726804.issue34638@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +8635
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34638>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:48:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 23:48:06 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536709686.29.0.0269046726804.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> (...) The documentation could definitely be much clearer on that point though, as even in the PEP it's only implied by the final paragraph in https://www.python.org/dev/peps/pep-0538/#legacy-c-locale-coercion-in-the-standalone-python-interpreter-binary which is mostly talking about the fact that this particular environment variable is still checked, even if you pass the -I or -E command line options.

That's a separated issue: I created bpo-34639.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:51:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 23:51:13 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536709873.13.0.0269046726804.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Example of C locale coercion with Python 3.7:

$ env -i PYTHONCOERCECLOCALE=0 ./python -X utf8=0 -c 'import sys; print(ascii(sys.argv[1]))' 'h?'
'h\udcc3\udca9'

$ env -i PYTHONCOERCECLOCALE=1 ./python -X utf8=0 -c 'import sys; print(ascii(sys.argv[1]))' 'h?'
'h\xe9'

It works as expected no? What's wrong with the current implementation according to you, Nick?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:53:24 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 23:53:24 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536710004.72.0.0269046726804.issue34405@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset aa02ab15aed9d0b70f619c186326594c0d50bdd6 by Miss Islington (bot) in branch '2.7':
[2.7] bpo-34405: Update to OpenSSL 1.0.2p for macOS installer builds (GH-9191) (GH-9196)
https://github.com/python/cpython/commit/aa02ab15aed9d0b70f619c186326594c0d50bdd6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:54:35 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 23:54:35 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536710075.85.0.0269046726804.issue34637@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

+1 agreed.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Tue Sep 11 19:57:25 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Sep 2018 23:57:25 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536710245.64.0.0269046726804.issue34637@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Woo! Thanks Raymond!

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:00:08 2018
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Sep 2018 00:00:08 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1536710408.95.0.0269046726804.issue34536@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +8636
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:00:12 2018
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Sep 2018 00:00:12 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1536710412.9.0.0269046726804.issue34536@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch, patch
pull_requests: +8636, 8637
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:00:13 2018
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Sep 2018 00:00:13 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1536710413.01.0.0269046726804.issue34536@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch, patch, patch
pull_requests: +8636, 8637, 8638
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:07:01 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Sep 2018 00:07:01 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536710821.5.0.0269046726804.issue34405@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8639

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:10:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 12 Sep 2018 00:10:41 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536711041.15.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 8be876e44b2dffb96b551029454cbfb16d697992 by Yury Selivanov in branch 'master':
bpo-33649: Cleanup asyncio/streams and asyncio/synchronization docs (GH-9192)
https://github.com/python/cpython/commit/8be876e44b2dffb96b551029454cbfb16d697992


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:11:03 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 00:11:03 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536711063.28.0.0269046726804.issue34637@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I suggest also allowing the first argument to be a keyword named sequence= as well.  (along the philosophy of positional only arguments on APIs that happen to be implemented in C in CPython are a bad legacy)

pypy already uses these names:
 https://bitbucket.org/pypy/pypy/src/4cbeaa8bf545332c36ae277019772aa432693e4c/pypy/module/__builtin__/app_functional.py?at=default&fileviewer=file-view-default#app_functional.py-41

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:14:20 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 00:14:20 +0000
Subject: [issue34636] re module microoptimization: speed up bytes \w \s \d
 matching
In-Reply-To: <1536703258.1.0.0269046726804.issue34636@psf.upfronthosting.co.za>
Message-ID: <1536711260.25.0.0269046726804.issue34636@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage:  -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34636>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:21:04 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 00:21:04 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536711664.95.0.0269046726804.issue31903@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks, Benjamin!

Ronald, do you think this should be backported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:26:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Sep 2018 00:26:22 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536711982.01.0.0269046726804.issue1621@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> newsize <<= 1; // The largest possible value is PY_SSIZE_T_MAX + 1. 

Previously, there was a explicitly check for error raising  PyErr_NoMemory() on overflow. Now you rely on PyMem_Malloc() to detect the overflow. I'm not sure that it's a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:26:31 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:26:31 +0000
Subject: [issue34640] remove the configure check TANH_PRESERVES_ZERO_SIGN
Message-ID: <1536711991.62.0.0269046726804.issue34640@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

configure.ac currently has to check for a bug in FreeBSD 6.2:

# On FreeBSD 6.2, it appears that tanh(-0.) returns 0. instead of
# -0. on some architectures.
AC_MSG_CHECKING(whether tanh preserves the sign of zero)
...

FreeBSD 6.2 is nearing 12 years old. It looks like the FreeBSD 10 bot is passing this check. So, I think we should remove this configure check.

----------
messages: 325106
nosy: benjamin.peterson, mark.dickinson
priority: normal
severity: normal
status: open
title: remove the configure check TANH_PRESERVES_ZERO_SIGN

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34640>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:28:13 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:28:13 +0000
Subject: [issue34640] remove the configure check TANH_PRESERVES_ZERO_SIGN
In-Reply-To: <1536711991.62.0.0269046726804.issue34640@psf.upfronthosting.co.za>
Message-ID: <1536712093.35.0.0269046726804.issue34640@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8640
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34640>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:31:54 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Sep 2018 00:31:54 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
Message-ID: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Emily and I just discovered that f((a)=1) is accepted and compiled the same as f(a=1). This goes against the intention that keyword arguments have the syntax f(NAME=expr).

I suspect that this behavior was introduced at the time we switched from generating from the (concrete) parse tree to first converting to an ast and then generating code from there. I.e. in the distant past (long before 2.7 even).

But I still think it ought to be fixed. Thoughts? Anyone have an idea *where* to fix it?

----------
messages: 325107
nosy: emilyemorehouse, gvanrossum
priority: normal
severity: normal
status: open
title: Curiosity: f((a)=1) is not a syntax error -- why?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:32:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:32:18 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536712338.88.0.0269046726804.issue25041@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 731ff68eeef58babdf2b32dc9a73b141760c2be9 by Benjamin Peterson (Cheryl Sabella) in branch 'master':
closes bpo-25041: Document AF_PACKET socket address format. (GH-4092)
https://github.com/python/cpython/commit/731ff68eeef58babdf2b32dc9a73b141760c2be9


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:33:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:33:38 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536712418.3.0.0269046726804.issue25041@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8641

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:34:32 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Sep 2018 00:34:32 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536712472.56.0.0269046726804.issue34637@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +8642
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:36:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:36:08 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536712568.86.0.0269046726804.issue25041@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8643

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Tue Sep 11 20:53:34 2018
From: report at bugs.python.org (Jeffrey Walton)
Date: Wed, 12 Sep 2018 00:53:34 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1536711982.01.0.0269046726804.issue1621@psf.upfronthosting.co.za>
Message-ID: <CAH8yC8n4eALjVon0VxHLV+y5hoqnLr+ohsMSCeHkVPZcoFXSpQ@mail.gmail.com>


Jeffrey Walton <noloader at gmail.com> added the comment:

On Tue, Sep 11, 2018 at 8:26 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <vstinner at redhat.com> added the comment:
>
>> newsize <<= 1; // The largest possible value is PY_SSIZE_T_MAX + 1.
>
> Previously, there was a explicitly check for error raising  PyErr_NoMemory() on overflow. Now you rely on PyMem_Malloc() to detect the overflow. I'm not sure that it's a good idea.

+1. It will probably work as expected on Solaris and other OSes that
don't oversubscribe memory. It will probably fail in unexpected ways
on Linux when the allocation succeeds but then the OOM killer hits a
random process.

Jeff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue Sep 11 21:02:44 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 01:02:44 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536714164.7.0.0269046726804.issue34405@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e351fe241c1fcb8cd739b08e21d2bb2f2b4c8c89 by Miss Islington (bot) (Steve Dower) in branch '2.7':
[2.7] bpo-34405: Updated to OpenSSL 1.0.2p for Windows builds. (GH-8776) (GH-9202)
https://github.com/python/cpython/commit/e351fe241c1fcb8cd739b08e21d2bb2f2b4c8c89


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 21:08:42 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 01:08:42 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1536714522.52.0.0269046726804.issue34405@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/issue34405>
_______________________________________

From report at bugs.python.org  Tue Sep 11 21:21:33 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 01:21:33 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536715293.47.0.0269046726804.issue34641@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I expect you'd have to make the check of test nodes in ast.c stricter. Here's a slightly gross implementation of that:

diff --git a/Python/ast.c b/Python/ast.c
index 94962e00c7..b7cebf4777 100644
--- a/Python/ast.c
+++ b/Python/ast.c
@@ -2815,15 +2815,22 @@ ast_for_call(struct compiling *c, const node *n, expr_ty func, bool allowgen)
                 identifier key, tmp;
                 int k;
 
-                /* chch is test, but must be an identifier? */
-                e = ast_for_expr(c, chch);
-                if (!e)
+                static const int chain[] = {test, or_test, and_test, not_test, comparison, expr, xor_expr, and_expr, shift_expr, arith_expr, term, factor, power, atom_expr, atom, 0};
+
+                node *expr_node = chch;
+                for (int i = 0; chain[i]; i++) {
+                    if (TYPE(expr_node) != chain[i])
+                        break;
+                    if (NCH(expr_node) != 1)
+                        break;
+                    expr_node = CHILD(expr_node, 0);
+                }
+                if (TYPE(expr_node) != NAME) {
+                    ast_error(c, chch,
+                            "keyword can't be an expression");
                     return NULL;
-                /* f(lambda x: x[0] = 3) ends up getting parsed with
-                 * LHS test = lambda x: x[0], and RHS test = 3.
-                 * SF bug 132313 points out that complaining about a keyword
-                 * then is very confusing.
-                 */
+                }
+                e = ast_for_expr(c, chch);
                 if (e->kind == Lambda_kind) {
                     ast_error(c, chch,
                             "lambda cannot contain assignment");

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Tue Sep 11 21:46:39 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 01:46:39 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536716799.24.0.956365154283.issue25041@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset cadb66e173ded86ebc85b54889db48f66e7af592 by Benjamin Peterson in branch '3.7':
[3.7] closes bpo-25041: Document AF_PACKET socket address format. (GH-9207)
https://github.com/python/cpython/commit/cadb66e173ded86ebc85b54889db48f66e7af592


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Tue Sep 11 22:18:31 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Wed, 12 Sep 2018 02:18:31 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536718711.32.0.956365154283.issue1621@psf.upfronthosting.co.za>


Sergey Fedoseev <fedoseev.sergey at gmail.com> added the comment:

> Now you rely on PyMem_Malloc() to detect the overflow.

Now overflow is not possible or am I missing something?

----------
nosy: +sir-sigurd

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue Sep 11 23:01:23 2018
From: report at bugs.python.org (William Chaseling)
Date: Wed, 12 Sep 2018 03:01:23 +0000
Subject: [issue34642] time.ctime() uses %3d instead of %.2d to format.
Message-ID: <1536721283.17.0.956365154283.issue34642@psf.upfronthosting.co.za>


New submission from William Chaseling <williamchaseling2000 at gmail.com>:

time.ctime() returns _asctime from a C module.
_asctime returns a PyUnicode_FromFormat() result using "%s %s%3d %.2d:%.2d:%.2d %d" as the string formatter.

This works: 'Wed Sep 12 22:30:00 2018'
Except when day <10, because it uses %3d instead of %.2d
'Wed Sep  2 22:30:00 2018'

This seems like it might be intended behavior for some reason, but I don't see the reason.

----------
components: Library (Lib)
messages: 325114
nosy: William Chaseling
priority: normal
severity: normal
status: open
title: time.ctime() uses %3d instead of %.2d to format.
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34642>
_______________________________________

From report at bugs.python.org  Tue Sep 11 23:03:09 2018
From: report at bugs.python.org (William Chaseling)
Date: Wed, 12 Sep 2018 03:03:09 +0000
Subject: [issue34642] time.ctime() uses %3d instead of %.2d to format.
In-Reply-To: <1536721283.17.0.956365154283.issue34642@psf.upfronthosting.co.za>
Message-ID: <1536721389.6.0.956365154283.issue34642@psf.upfronthosting.co.za>


William Chaseling <williamchaseling2000 at gmail.com> added the comment:

It's easy to get around using .replace('  ', ' '), but it's still a bit annoying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34642>
_______________________________________

From report at bugs.python.org  Tue Sep 11 23:42:45 2018
From: report at bugs.python.org (Valentin Zhao)
Date: Wed, 12 Sep 2018 03:42:45 +0000
Subject: [issue34643] How to build Release Version of Python in Windows?
Message-ID: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>


New submission from Valentin Zhao <jmsqzzl at gmail.com>:

I am going to build a Python.exe to migrate it to another PC, in order to build a seemingly virtual *environment* of Python which could run python files. What I do to implement this is to *COPY* \win32 folder to another pc then execute python.exe with specific python file path tagged along.

For now, it works well, however, I met with a strange problem that I cannot find *tcl* under current file hierarchy and this library is generated very deeply so I have to extract it to the root directory manually. 

Surprisingly, I found that I can directly *COPY* all the folders generated by *msi installer* to another pc then use it. Nevertheless, I fret about there could be some registration thing during installation.

So how could I compile the source and make it generate folder hierarchy like the release version(like the snapshot I attached below)? I have read README.md in the \PCBuild yet it helps little.

----------
components: Windows
files: build???.png
messages: 325116
nosy: Valentin Zhao, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: How to build Release Version of Python in Windows?
type: compile error
versions: Python 3.6
Added file: https://bugs.python.org/file47797/build???.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34643>
_______________________________________

From report at bugs.python.org  Tue Sep 11 23:47:50 2018
From: report at bugs.python.org (Martin Panter)
Date: Wed, 12 Sep 2018 03:47:50 +0000
Subject: [issue34642] time.ctime() uses %3d instead of %.2d to format.
In-Reply-To: <1536721283.17.0.956365154283.issue34642@psf.upfronthosting.co.za>
Message-ID: <1536724070.31.0.956365154283.issue34642@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I think "ctime" and "asctime" are supposed to wrap or imitate the standard C functions: <https://port70.net/~nsz/c/c11/n1570.html#7.27.3.2>, so I think this is intended behaviour. But see Issue 13927 about improving the documentation.

For a single-digit day of the month, there is supposed to be two spaces. Using "%.2d" would produce "Sep02" or "Sep 02", with a leading zero. On the other hand, changing the double space to a single space would produce "Sep 2", without a leading zero.

----------
nosy: +martin.panter
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
superseder:  -> Extra spaces in the output of time.ctime

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34642>
_______________________________________

From report at bugs.python.org  Tue Sep 11 23:50:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 03:50:15 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536724215.82.0.956365154283.issue34641@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Tue Sep 11 23:51:37 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 03:51:37 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536724297.95.0.956365154283.issue34637@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Wed Sep 12 00:31:31 2018
From: report at bugs.python.org (Valentin Zhao)
Date: Wed, 12 Sep 2018 04:31:31 +0000
Subject: [issue34643] How to build Release Version of Python in Windows?
In-Reply-To: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>
Message-ID: <1536726691.29.0.956365154283.issue34643@psf.upfronthosting.co.za>


Valentin Zhao <jmsqzzl at gmail.com> added the comment:

Sorry I posted a wrong pic.

----------
Added file: https://bugs.python.org/file47798/build?.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34643>
_______________________________________

From report at bugs.python.org  Wed Sep 12 00:33:37 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Wed, 12 Sep 2018 04:33:37 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536726817.32.0.956365154283.issue34606@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

In this particular case looks like a crux of the problem was in the fact that compression encodes extra fields only if either zip64 is set or length of the field is larger than threshold but decompression always tries to decode it. Attached PR switches decoding to be conditioned on the presence of zip64 end of central directory record.

----------
nosy: +v2m

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34606>
_______________________________________

From report at bugs.python.org  Wed Sep 12 00:50:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Sep 2018 04:50:22 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536727822.79.0.956365154283.issue34641@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Wed Sep 12 00:53:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Sep 2018 04:53:33 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536728013.31.0.956365154283.issue34637@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is not this a duplicate of issue31141?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Wed Sep 12 01:31:04 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 12 Sep 2018 05:31:04 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1536730264.16.0.956365154283.issue20180@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Now just the collections module is left from this group.

Raymond, what would you like done with it WRT AC conversion, if at all?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Wed Sep 12 01:36:14 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 05:36:14 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536730574.05.0.956365154283.issue25041@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a00de685c11cf8bdca1f8efa7aab80552d80ddfb by Benjamin Peterson in branch '3.6':
[3.6] closes bpo-25041: Document AF_PACKET socket address format. (GH-9209)
https://github.com/python/cpython/commit/a00de685c11cf8bdca1f8efa7aab80552d80ddfb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Wed Sep 12 01:37:31 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 05:37:31 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536730651.64.0.956365154283.issue34641@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There seems to be some of the similar cases that have tests added as part of c960f26044edaea6669e60859ecf590c63c65e62 and the original error message added at 3e0055f8c65c407e74ce476b8e2b1fb889723514.

Existing tests : 

>>> f(x()=2)
Traceback (most recent call last):
SyntaxError: keyword can't be an expression
>>> f(a or b=1)
Traceback (most recent call last):
SyntaxError: keyword can't be an expression
>>> f(x.y=1)
Traceback (most recent call last):
SyntaxError: keyword can't be an expression


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Wed Sep 12 01:59:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 05:59:58 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536731998.48.0.956365154283.issue34637@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There doesn't seem to be any performance regression hoping that I am doing the benchmarks correctly. Some numbers for the PR.

# Master

git checkout master
git clean -xdf && ./configure && make -s -j4

$ cpython git:(master) ./python.exe
Python 3.8.0a0 (heads/master:731ff68eee, Sep 12 2018, 11:19:46)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

$ cpython git:(master) repeat 10 ./python.exe -m timeit "sum(range(10), 50)"
500000 loops, best of 5: 635 nsec per loop
500000 loops, best of 5: 682 nsec per loop
500000 loops, best of 5: 637 nsec per loop
500000 loops, best of 5: 648 nsec per loop
500000 loops, best of 5: 618 nsec per loop
500000 loops, best of 5: 621 nsec per loop
500000 loops, best of 5: 653 nsec per loop
500000 loops, best of 5: 624 nsec per loop
500000 loops, best of 5: 671 nsec per loop
500000 loops, best of 5: 659 nsec per loop

git fetch upstream pull/9208/head:sum-start-keyword
git checkout sum-start-keyword
git clean -xdf && ./configure && make -s -j4

$ cpython git:(sum-start-keyword) ./python.exe
Python 3.8.0a0 (heads/sum-start-keyword:71b890cd56, Sep 12 2018, 11:23:02)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

$ cpython git:(sum-start-keyword) repeat 10 ./python.exe -m timeit "sum(range(10), 50)"
500000 loops, best of 5: 655 nsec per loop
500000 loops, best of 5: 662 nsec per loop
500000 loops, best of 5: 669 nsec per loop
500000 loops, best of 5: 656 nsec per loop
500000 loops, best of 5: 666 nsec per loop
500000 loops, best of 5: 642 nsec per loop
500000 loops, best of 5: 638 nsec per loop
500000 loops, best of 5: 628 nsec per loop
500000 loops, best of 5: 684 nsec per loop
500000 loops, best of 5: 648 nsec per loop

$ cpython git:(sum-start-keyword) repeat 10 ./python.exe -m timeit "sum(range(10), start=50)"
500000 loops, best of 5: 637 nsec per loop
500000 loops, best of 5: 677 nsec per loop
500000 loops, best of 5: 649 nsec per loop
500000 loops, best of 5: 660 nsec per loop
500000 loops, best of 5: 692 nsec per loop
500000 loops, best of 5: 704 nsec per loop
500000 loops, best of 5: 638 nsec per loop
500000 loops, best of 5: 659 nsec per loop
500000 loops, best of 5: 637 nsec per loop
500000 loops, best of 5: 699 nsec per loop

I haven't tested the other PR serhiy mentioned since it has merge conflicts and I think it uses the same approach with argument clinic.


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Wed Sep 12 02:04:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Sep 2018 06:04:00 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536732240.36.0.956365154283.issue34641@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Could you please create a PR Benjamin? And please keep the comment about special casing lambda.

See also issue30858 about the wording of the error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Wed Sep 12 02:13:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 06:13:33 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536732813.0.0.956365154283.issue34641@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Tested the patch.

?  cpython git:(master) ? ./python.exe
Python 3.8.0a0 (heads/master-dirty:731ff68eee, Sep 12 2018, 11:40:16)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(a): pass
...
>>> foo((a)=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression

?  cpython git:(master) ? ./python.exe -m unittest -v test.test_syntax
test_assign_call (test.test_syntax.SyntaxTestCase) ... ok
test_assign_del (test.test_syntax.SyntaxTestCase) ... ok
test_bad_outdent (test.test_syntax.SyntaxTestCase) ... ok
test_break_outside_loop (test.test_syntax.SyntaxTestCase) ... ok
test_global_param_err_first (test.test_syntax.SyntaxTestCase) ... ok
test_kwargs_last (test.test_syntax.SyntaxTestCase) ... ok
test_kwargs_last2 (test.test_syntax.SyntaxTestCase) ... ok
test_kwargs_last3 (test.test_syntax.SyntaxTestCase) ... ok
test_no_indent (test.test_syntax.SyntaxTestCase) ... ok
test_nonlocal_param_err_first (test.test_syntax.SyntaxTestCase) ... ok
test_unexpected_indent (test.test_syntax.SyntaxTestCase) ... ok

----------------------------------------------------------------------
Ran 11 tests in 0.006s

OK



Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Wed Sep 12 02:13:48 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 06:13:48 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536732828.38.0.956365154283.issue34641@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8644
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Wed Sep 12 03:34:42 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 12 Sep 2018 07:34:42 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1536737682.92.0.956365154283.issue20182@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8645

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Wed Sep 12 03:35:53 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 12 Sep 2018 07:35:53 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1536737753.1.0.956365154283.issue20182@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

See new updated PR9213 for completing the _hashopenssl.c conversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Wed Sep 12 03:52:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Sep 2018 07:52:57 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536738777.18.0.956365154283.issue1621@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I asked if there is an issue. In fact, all Python memory allocators start by checking if the size is larger than PY_SSIZE_T_MAX. Example:

void *
PyMem_RawMalloc(size_t size)
{
    /*
     * Limit ourselves to PY_SSIZE_T_MAX bytes to prevent security holes.
     * Most python internals blindly use a signed Py_ssize_t to track
     * things without checking for overflows or negatives.
     * As size_t is unsigned, checking for size < 0 is not required.
     */
    if (size > (size_t)PY_SSIZE_T_MAX)
        return NULL;
    return _PyMem_Raw.malloc(_PyMem_Raw.ctx, size);
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Wed Sep 12 04:25:40 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 12 Sep 2018 08:25:40 +0000
Subject: [issue28994] Misc fixes and cleanups in error handling C code
In-Reply-To: <1481931496.89.0.341758339319.issue28994@psf.upfronthosting.co.za>
Message-ID: <1536740740.86.0.956365154283.issue28994@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8646

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28994>
_______________________________________

From report at bugs.python.org  Wed Sep 12 04:27:38 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 12 Sep 2018 08:27:38 +0000
Subject: [issue28994] Misc fixes and cleanups in error handling C code
In-Reply-To: <1481931496.89.0.341758339319.issue28994@psf.upfronthosting.co.za>
Message-ID: <1536740858.55.0.956365154283.issue28994@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

In PR 2123, it was reported that the Modules/atexitmodule.c file was backported to 2.7. PR 9214 addresses this.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28994>
_______________________________________

From report at bugs.python.org  Wed Sep 12 04:31:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Sep 2018 08:31:46 +0000
Subject: [issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option
In-Reply-To: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>
Message-ID: <1536741106.04.0.956365154283.issue34639@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34639>
_______________________________________

From report at bugs.python.org  Wed Sep 12 06:26:54 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 10:26:54 +0000
Subject: [issue34628] urllib.request.urlopen fails when userinfo is present in
 URL
In-Reply-To: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>
Message-ID: <1536748014.65.0.956365154283.issue34628@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems like this is an explicit choice that there is also a test with the URL "user:password at www.python.org" . Ref : https://github.com/python/cpython/blob/731ff68eeef58babdf2b32dc9a73b141760c2be9/Lib/test/test_httplib.py#L640 . You can try basic auth example in https://docs.python.org/3/library/urllib.request.html#examples

Adding the developer here who might have more info on adding this support for urllib .

Thanks

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34628>
_______________________________________

From report at bugs.python.org  Wed Sep 12 06:47:26 2018
From: report at bugs.python.org (Niklas Sombert)
Date: Wed, 12 Sep 2018 10:47:26 +0000
Subject: [issue34628] urllib.request.urlopen fails when userinfo is present in
 URL
In-Reply-To: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>
Message-ID: <1536749246.22.0.956365154283.issue34628@psf.upfronthosting.co.za>


Niklas Sombert <niklas at ytvwld.de> added the comment:

Thank you for your response.

But if this is an explicit choice, I would like to have better exceptions:

>>> from http.client import HTTPConnection
>>> h = HTTPConnection("user:1234 at example.net")
    raises http.client.InvalidURL: nonnumeric port: '1234 at example.n
et'
>>> h = HTTPConnection("user:1234 at example.net:1234")
    doesn't raise any exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34628>
_______________________________________

From report at bugs.python.org  Wed Sep 12 07:24:30 2018
From: report at bugs.python.org (Kyle Altendorf)
Date: Wed, 12 Sep 2018 11:24:30 +0000
Subject: [issue34606] Unable to read zip file with extra
In-Reply-To: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>
Message-ID: <1536751470.32.0.956365154283.issue34606@psf.upfronthosting.co.za>


Kyle Altendorf <sda at fstab.net> added the comment:

Vladimir, if compression were the cause wouldn't the extra bytes I added (signature and length) not have any effect?  If you've found an issue it seems like it would be a different one than I was triggering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34606>
_______________________________________

From report at bugs.python.org  Wed Sep 12 07:28:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Sep 2018 11:28:24 +0000
Subject: [issue28994] Misc fixes and cleanups in error handling C code
In-Reply-To: <1481931496.89.0.341758339319.issue28994@psf.upfronthosting.co.za>
Message-ID: <1536751704.27.0.956365154283.issue28994@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b36567bef80202f53ebe924dd183270c276497f8 by Serhiy Storchaka (Zackery Spytz) in branch '2.7':
[2.7] bpo-28994: Remove mistakenly backported atexitmodule.c (GH-9214)
https://github.com/python/cpython/commit/b36567bef80202f53ebe924dd183270c276497f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28994>
_______________________________________

From report at bugs.python.org  Wed Sep 12 08:06:37 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Sep 2018 12:06:37 +0000
Subject: [issue34640] remove the configure check TANH_PRESERVES_ZERO_SIGN
In-Reply-To: <1536711991.62.0.0269046726804.issue34640@psf.upfronthosting.co.za>
Message-ID: <1536753997.84.0.956365154283.issue34640@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So, I think we should remove this configure check.

+1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34640>
_______________________________________

From report at bugs.python.org  Wed Sep 12 08:10:47 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Sep 2018 12:10:47 +0000
Subject: [issue32055] Reconsider comparison chaining for containment tests
In-Reply-To: <1510904597.47.0.213398074469.issue32055@psf.upfronthosting.co.za>
Message-ID: <1536754247.5.0.956365154283.issue32055@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/issue32055>
_______________________________________

From report at bugs.python.org  Wed Sep 12 08:33:27 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 12 Sep 2018 12:33:27 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536755607.89.0.956365154283.issue31903@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Yes it should, the same problem has been present from the start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Wed Sep 12 08:55:12 2018
From: report at bugs.python.org (Rajesh)
Date: Wed, 12 Sep 2018 12:55:12 +0000
Subject: [issue34644] Bug in reverse method
Message-ID: <1536756911.75.0.956365154283.issue34644@psf.upfronthosting.co.za>


New submission from Rajesh <rajesh99div99 at gmail.com>:

List.reverse()    .... this is working in reverse order 
List.reverse      ....this is not giving syntax error and printing the list as it is.

Can you consider this as bug and fix it in further versions ?

----------
messages: 325136
nosy: rajesh99div99
priority: normal
severity: normal
status: open
title: Bug in reverse method
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34644>
_______________________________________

From report at bugs.python.org  Wed Sep 12 09:25:13 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 12 Sep 2018 13:25:13 +0000
Subject: [issue34644] Bug in reverse method
In-Reply-To: <1536756911.75.0.956365154283.issue34644@psf.upfronthosting.co.za>
Message-ID: <1536758713.98.0.956365154283.issue34644@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is not a bug or a syntax error, and the behaviour goes back to at least Python 1.5 if not older.

List.reverse returns a reference to the method object itself. List.reverse() *calls* the method. This is standard behaviour in Python, all methods and functions are first-class values, anything you can do with an object, you can do with a function or method too. For example:

py> list.reverse.__name__
'reverse'
py> print(len)
<built-in function len>
py> alist = [1, "a", chr]
py> print(alist)
[1, 'a', <built-in function chr>]

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34644>
_______________________________________

From report at bugs.python.org  Wed Sep 12 09:51:28 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 13:51:28 +0000
Subject: [issue34640] remove the configure check TANH_PRESERVES_ZERO_SIGN
In-Reply-To: <1536711991.62.0.0269046726804.issue34640@psf.upfronthosting.co.za>
Message-ID: <1536760288.05.0.956365154283.issue34640@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 865c17fb28f8c3275fd94da6ee4ac51472ec874a by Benjamin Peterson in branch 'master':
closes bpo-34640: Remove the TANH_PRESERVES_ZERO_SIGN configure check. (GH-9206)
https://github.com/python/cpython/commit/865c17fb28f8c3275fd94da6ee4ac51472ec874a


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34640>
_______________________________________

From report at bugs.python.org  Wed Sep 12 10:27:30 2018
From: report at bugs.python.org (Floris van Manen)
Date: Wed, 12 Sep 2018 14:27:30 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
Message-ID: <1536762450.41.0.956365154283.issue34645@psf.upfronthosting.co.za>


New submission from Floris van Manen <vm at klankschap.nl>:

when using numpy defined values i get nan results.
when using math defined values, no nan errors occur.

check2 bb [5.0, 2.285379077161093, nan, nan, 2.285379077161092]

check2 cc [5.0, 2.285379077161093, 4.341186402706317, 4.341186402706317, 2.285379077161092]

how to get identical results?

----------
files: nan-test.py
messages: 325139
nosy: klankschap
priority: normal
severity: normal
status: open
title: math and numpy yield different results  (nan)
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47799/nan-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 11:19:03 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Sep 2018 15:19:03 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <1536762450.41.0.956365154283.issue34645@psf.upfronthosting.co.za>
Message-ID: <1536765543.37.0.956365154283.issue34645@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 11:20:37 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 15:20:37 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536765637.29.0.956365154283.issue31903@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8647

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Wed Sep 12 11:20:47 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 15:20:47 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536765647.31.0.956365154283.issue31903@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8648

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Wed Sep 12 11:37:43 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 15:37:43 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536766663.43.0.956365154283.issue31903@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 72c34cf6dd5fb206fe4d407ff603468af466fd2e by Miss Islington (bot) in branch '3.7':
closes bpo-31903: Release the GIL when calling into SystemConfiguration (GH-4178)
https://github.com/python/cpython/commit/72c34cf6dd5fb206fe4d407ff603468af466fd2e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Wed Sep 12 11:38:39 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 15:38:39 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1536766719.93.0.956365154283.issue31903@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset aa12534acff4868f6dce9e2364a66fbb0ebcb3ca by Miss Islington (bot) in branch '3.6':
closes bpo-31903: Release the GIL when calling into SystemConfiguration (GH-4178)
https://github.com/python/cpython/commit/aa12534acff4868f6dce9e2364a66fbb0ebcb3ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Wed Sep 12 12:10:12 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 12 Sep 2018 16:10:12 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <1536762450.41.0.956365154283.issue34645@psf.upfronthosting.co.za>
Message-ID: <1536768612.0.0.956365154283.issue34645@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Your code gives runtime warnings of invalid values. You should fix that. If your values are invalid, there's probably a bug in your code.

RuntimeWarning: invalid value encountered in double_scalars

Your code is also very complex. You ought to simplify the example so that it is easier to understand, all the business with linspace and duplicated code just adds complexity and makes it hard to understand.

I simplified your code to this:

import numpy as np
n=2.758
n2 = 2.0 / n
ct = np.cos(2 * np.pi * 2.0 / 5)
print("numpy", ct, abs(ct ** n2) * 5.0)


which gives this output:

__main__:1: RuntimeWarning: invalid value encountered in double_scalars
('numpy', -0.80901699437494734, nan)

So there's a problem. You're trying to raise a negative number to a positive value, and numpy doesn't like it and returns a NAN.

But using the standard math library, raising a negative number to a positive value gives you a complex number:

ct = math.cos(2 * math.pi * 2.0 / 5)
print(ct**n2)
print("math", ct, abs(ct ** n2) * 5.0)


which gives this output:

(-0.5572617094280153+0.6517928032447587j)
math -0.8090169943749473 4.287698890886272

So the behaviour is correct and this is not a bug in either math nor numpy. They're just doing different things.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 12:12:21 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 12 Sep 2018 16:12:21 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <1536762450.41.0.956365154283.issue34645@psf.upfronthosting.co.za>
Message-ID: <1536768741.05.0.956365154283.issue34645@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oops, sorry, I mistyped. I said:

    So there's a problem. You're trying to raise a negative number
    to a positive value


I meant to say a *fractional* value. Sorry for the confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 12:21:40 2018
From: report at bugs.python.org (Floris van Manen)
Date: Wed, 12 Sep 2018 16:21:40 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <1536768741.05.0.956365154283.issue34645@psf.upfronthosting.co.za>
Message-ID: <26EDB398-2063-45D0-A493-D4F4AD647A33@klankschap.nl>


Floris van Manen <vm at klankschap.nl> added the comment:

Well, the thing is that i pass two (apparent) identical values into the same function, and get two different results.
Apparent as in one value generated via np.linspace() and one directly retrieved from a list.

> On 12 Sep 2018, at 18:12, Steven D'Aprano <report at bugs.python.org> wrote:
> 
> 
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
> 
> Oops, sorry, I mistyped. I said:
> 
>    So there's a problem. You're trying to raise a negative number
>    to a positive value
> 
> 
> I meant to say a *fractional* value. Sorry for the confusion.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34645>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 12:26:27 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 12 Sep 2018 16:26:27 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1536769587.84.0.956365154283.issue17239@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8649
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Wed Sep 12 12:27:47 2018
From: report at bugs.python.org (Floris van Manen)
Date: Wed, 12 Sep 2018 16:27:47 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <1536768612.0.0.956365154283.issue34645@psf.upfronthosting.co.za>
Message-ID: <FD657422-28D2-472E-BADA-BA230FBAA458@klankschap.nl>


Floris van Manen <vm at klankschap.nl> added the comment:

Well, the thing is that i pass two (apparent) identical values into the same function, and get two different results.
Apparent as in one value generated via np.linspace() and one directly retrieved from a list.
If i pass the np variable into to function, it will generate an NAN error.
If i pass the non np variable into the function, it will work.

.F

> On 12 Sep 2018, at 18:10, Steven D'Aprano <report at bugs.python.org> wrote:
> 
> 
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
> 
> Your code gives runtime warnings of invalid values. You should fix that. If your values are invalid, there's probably a bug in your code.
> 
> RuntimeWarning: invalid value encountered in double_scalars
> 
> Your code is also very complex. You ought to simplify the example so that it is easier to understand, all the business with linspace and duplicated code just adds complexity and makes it hard to understand.
> 
> I simplified your code to this:
> 
> import numpy as np
> n=2.758
> n2 = 2.0 / n
> ct = np.cos(2 * np.pi * 2.0 / 5)
> print("numpy", ct, abs(ct ** n2) * 5.0)
> 
> 
> which gives this output:
> 
> __main__:1: RuntimeWarning: invalid value encountered in double_scalars
> ('numpy', -0.80901699437494734, nan)
> 
> So there's a problem. You're trying to raise a negative number to a positive value, and numpy doesn't like it and returns a NAN.
> 
> But using the standard math library, raising a negative number to a positive value gives you a complex number:
> 
> ct = math.cos(2 * math.pi * 2.0 / 5)
> print(ct**n2)
> print("math", ct, abs(ct ** n2) * 5.0)
> 
> 
> which gives this output:
> 
> (-0.5572617094280153+0.6517928032447587j)
> math -0.8090169943749473 4.287698890886272
> 
> So the behaviour is correct and this is not a bug in either math nor numpy. They're just doing different things.
> 
> ----------
> nosy: +steven.daprano
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34645>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:00:42 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 17:00:42 +0000
Subject: [issue33437] Defining __init__ in enums
In-Reply-To: <1525687357.98.0.682650639539.issue33437@psf.upfronthosting.co.za>
Message-ID: <1536771642.66.0.956365154283.issue33437@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f52237400b9960d434c5d0676a3479b8c1e8c869 by Miss Islington (bot) (Ethan Furman) in branch 'master':
bpo-33437: add __new__ vs __init__ example (GH-9145)
https://github.com/python/cpython/commit/f52237400b9960d434c5d0676a3479b8c1e8c869


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33437>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:22:24 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 17:22:24 +0000
Subject: [issue34646] remove PyAPI_* from function definitions
Message-ID: <1536772944.12.0.956365154283.issue34646@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

It suffices to have PyAPI_FUNC and PyAPI_DATA on the forward declaration in a header file. We should remove the usages we have in .c files.

----------
components: Interpreter Core
messages: 325147
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: remove PyAPI_* from function definitions
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34646>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:28:57 2018
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Sep 2018 17:28:57 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1536773337.74.0.956365154283.issue34282@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 0fb9fadd3b3e9e3698647e0b92d49b0b7aacd979 by Ethan Furman (orlnub123) in branch 'master':
bpo-34282: Fix Enum._convert shadowing members named _convert (GH-8568)
https://github.com/python/cpython/commit/0fb9fadd3b3e9e3698647e0b92d49b0b7aacd979


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34282>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:34:28 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 17:34:28 +0000
Subject: [issue34646] remove PyAPI_* from function definitions
In-Reply-To: <1536772944.12.0.956365154283.issue34646@psf.upfronthosting.co.za>
Message-ID: <1536773668.18.0.956365154283.issue34646@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8650
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34646>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:49:26 2018
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 12 Sep 2018 17:49:26 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536774566.67.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

Hi Petr,

yes I have that what generated the wrong thing, but it is inside
a specific PySide repository in a big project. Before I try to extract
and simulate that, let me just show it.

All types which had been no heaptypes before were already quite complicated
types which had their own deallocators before, or a 0 if they did not
need one, or better "should not have one".

When switching to the new interface, those deallocators which were 0 were
turned into the default deallocator, which crashed most of the time.

By replacing it by a dummy function fixed the problem. Example:

static PyType_Slot PySideSignalMetaType_slots[] = {
    {Py_tp_methods, (void *)Signal_methods},
    {Py_tp_base, (void *)&PyType_Type},
    {Py_tp_free, (void *)PyObject_GC_Del},
    {Py_tp_dealloc, (void *)SbkDummyDealloc},
    {0, 0}
};
static PyType_Spec PySideSignalMetaType_spec = {
    "PySide2.QtCore.MetaSignal",
    0,
    // sizeof(PyHeapTypeObject) is filled in by PyType_FromSpecWithBases
    // which calls PyType_Ready which calls inherit_special.
    0,
    Py_TPFLAGS_DEFAULT,
    PySideSignalMetaType_slots,
};

You can find the checkins here. This branch contains everything relevant in small steps.

https://github.com/pyside/pyside2-setup/commit/2f0658be36107097810985f2190fe0f2acfba178

The first working transformation was in the commit
"PEP 384-8-HT-4: Successful Restart using PyType_FromSpec".

I have yet no idea how to extract a minimum example that produces this problem.

Summary: 
In a way, without being heaptypes, the old types were dynamic, too, and inserting
something that was not there before was a bad idea.

(sorry, there is more...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:54:10 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Sep 2018 17:54:10 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536774850.59.0.956365154283.issue34637@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 9dfa0fe587eae3626ffc973680c6a17f35de3864 by Raymond Hettinger in branch 'master':
bpo-34637: Make the *start* argument for *sum()* visible as a keyword argument. (GH-9208)
https://github.com/python/cpython/commit/9dfa0fe587eae3626ffc973680c6a17f35de3864


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:57:52 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Sep 2018 17:57:52 +0000
Subject: [issue34637] Make *start* usable as a keyword argument for sum().
In-Reply-To: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>
Message-ID: <1536775072.71.0.956365154283.issue34637@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Discussed exposure of the first argument with GPS and agreed that we don't want people writing API sum(iterable=[10,20,30], start=0).

Serhiy, yes this is a duplicate/superseder of issue31141.   Will close that at well.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34637>
_______________________________________

From report at bugs.python.org  Wed Sep 12 13:59:37 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Sep 2018 17:59:37 +0000
Subject: [issue31141] Start should be a keyword argument of the built-in sum
In-Reply-To: <1502193168.16.0.095124886528.issue31141@psf.upfronthosting.co.za>
Message-ID: <1536775177.51.0.956365154283.issue31141@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> Make *start* usable as a keyword argument for sum().

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31141>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:19:04 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 12 Sep 2018 18:19:04 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <26EDB398-2063-45D0-A493-D4F4AD647A33@klankschap.nl>
Message-ID: <20180912181855.GA19437@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Well, the thing is that i pass two (apparent) identical values into the same function,

Even if they have the same *numeric* value, they aren't the same kind of 
value, and they aren't the same function.

One is <type 'numpy.float64'> and the other is <class 'float'>. When you 
call ** (exponentiation), that calls two different methods. One raises 
a warning and returns NAN, the other converts to complex.

This has nothing to do with linspace. See my simplifed example code 
which doesn't use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:21:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Sep 2018 18:21:08 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1536776468.4.0.956365154283.issue34409@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I recommend passing on this feature request as being too specialized and beyond the scope of what data classes are intended to do.  

FWIW, the information needed by a user to write their own customized iteration patterns is publicly available.  One of the reasons for having a general purpose programming language is to enable users to write customizations that best fit their particular use cases.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:25:02 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Wed, 12 Sep 2018 18:25:02 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536776702.49.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Bumsik Kim <kbumsik at gmail.com>:


----------
pull_requests: +8651

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:25:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 18:25:10 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536776710.46.0.956365154283.issue31577@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

@Serihy, @Mark, others, any suggestions for what to do for 3.7.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:28:08 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 12 Sep 2018 18:28:08 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1536776888.73.0.956365154283.issue34409@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, Raymond. I agree that this request is too specialized to add to dataclasses. Any proposal here or that I've been able to think of complicate the API for the much more common use case of not needing asdict() specialization.

To the original poster: I suggest you just implement the functionality you need in a custom version of asdict() yourself. As noted, all of the information needed for a custom asdict() are publicly available.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:32:01 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 12 Sep 2018 18:32:01 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536777121.2.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset aca819fb494d4801b3e5b5b507b17cab772c1b40 by Yury Selivanov (Bumsik Kim) in branch 'master':
bpo-33649: Fix doc to reflect changes in 47cd10d (or bpo-23347) (GH-9219)
https://github.com/python/cpython/commit/aca819fb494d4801b3e5b5b507b17cab772c1b40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:32:01 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 12 Sep 2018 18:32:01 +0000
Subject: [issue23347] asyncio: fix and refactor creation of subprocess
 transports
In-Reply-To: <1422532609.81.0.0177270416952.issue23347@psf.upfronthosting.co.za>
Message-ID: <1536777121.43.0.249678724859.issue23347@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset aca819fb494d4801b3e5b5b507b17cab772c1b40 by Yury Selivanov (Bumsik Kim) in branch 'master':
bpo-33649: Fix doc to reflect changes in 47cd10d (or bpo-23347) (GH-9219)
https://github.com/python/cpython/commit/aca819fb494d4801b3e5b5b507b17cab772c1b40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23347>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:32:03 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 18:32:03 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1536777123.46.0.956365154283.issue26544@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

This is now only open and a release blocker for 2.7, correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:32:42 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 18:32:42 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536777162.27.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This is consistent for me, not random.  run -m test.regrtest in -v mode and it passes.  remove the -v and it fails.

run Lib/test/test_pkg.py directly and it fails with the details mentioned here.

this prevents CI builds from succeeding for me now.

(confirmed on actual master at rev 9dfa0fe587)

----------
nosy: +gregory.p.smith
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:35:21 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Wed, 12 Sep 2018 18:35:21 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536777321.16.0.956365154283.issue33649@psf.upfronthosting.co.za>


Bumsik Kim <kbumsik at gmail.com> added the comment:

Hi, I came from #33986. I noticed that the new doc still does not reflect a design change on SubprocessTransport.close() done in #23347. I made a PR to fix that.

BTW this is opposed to the original PEP 3156: https://www.python.org/dev/peps/pep-3156/#subprocess-transports . I don't know if it is commonly happens.

----------
nosy: +kbumsik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:37:35 2018
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Sep 2018 18:37:35 +0000
Subject: [issue29577] Enum: mixin classes don't mix well with already mixed
 Enums
In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za>
Message-ID: <1536777455.02.0.956365154283.issue29577@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
versions: +Python 3.8 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29577>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:38:59 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 18:38:59 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536777539.51.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

confirmed that this is present in 3.7 rev 72c34cf6dd as well.

----------
nosy: +ned.deily
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:39:03 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Wed, 12 Sep 2018 18:39:03 +0000
Subject: [issue33986] asyncio: Typo in documentation: BaseSubprocessTransport
 -> SubprocessTransport
In-Reply-To: <1530139574.74.0.56676864532.issue33986@psf.upfronthosting.co.za>
Message-ID: <1536777543.01.0.956365154283.issue33986@psf.upfronthosting.co.za>


Bumsik Kim <kbumsik at gmail.com> added the comment:

#33649 does not solve a problem of SubprocessTransport.close() done in #23347. I made a PR #33649 directly to fix that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33986>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:42:18 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 18:42:18 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536777738.97.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

marking release blocker solely because this prevents CI runs from succeeding.

I'm surprised how long this issue has been here though, i don't know what caused it to start happening consistently but as with many such heisenbugs changes at a distance could be related. :/

----------
title: importlib: python -m test test_pkg -m test_7 fails randomly -> importlib: python -m test test_pkg fails

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:43:07 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 12 Sep 2018 18:43:07 +0000
Subject: [issue34638] Avoid circular references in asyncio streams
In-Reply-To: <1536709646.23.0.0269046726804.issue34638@psf.upfronthosting.co.za>
Message-ID: <1536777787.21.0.956365154283.issue34638@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset a5d1eb8d8b7add31b5f5d9bbb31cee1a491b2c08 by Andrew Svetlov in branch 'master':
bpo-34638: Store a weak reference to stream reader to break strong references loop (GH-9201)
https://github.com/python/cpython/commit/a5d1eb8d8b7add31b5f5d9bbb31cee1a491b2c08


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34638>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:43:37 2018
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Sep 2018 18:43:37 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1536777817.38.0.956365154283.issue34536@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 019f0a0cb85ebc234356415f3638b9bd77528e55 by Ethan Furman in branch 'master':
bpo-34536: raise error for invalid _missing_ results (GH-9147)
https://github.com/python/cpython/commit/019f0a0cb85ebc234356415f3638b9bd77528e55


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:43:38 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 12 Sep 2018 18:43:38 +0000
Subject: [issue34638] Avoid circular references in asyncio streams
In-Reply-To: <1536709646.23.0.0269046726804.issue34638@psf.upfronthosting.co.za>
Message-ID: <1536777818.93.0.956365154283.issue34638@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34638>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:46:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Sep 2018 18:46:13 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536777973.17.0.956365154283.issue31577@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 3752 LGTM. I have reran CI tests, if they will be passed, the PR can be merged. This PR was not merged only because we discussed possible alternate solutions and lost an opportunity to merge it for 3.7.0.

I agree that timedelta.__divmod__ doesn't have such issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:56:33 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Sep 2018 18:56:33 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1536778593.83.0.956365154283.issue20180@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Now just the collections module is left from this group.
> Raymond, what would you like done with it WRT AC conversion,
> if at all?

I would like to pass on the collections module.  Having looked at the patch, I think the code is currently better as is.

That bring this one Derby to a close.  Congratulations :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Wed Sep 12 14:58:20 2018
From: report at bugs.python.org (Floris van Manen)
Date: Wed, 12 Sep 2018 18:58:20 +0000
Subject: [issue34645] math and numpy yield different results  (nan)
In-Reply-To: <20180912181855.GA19437@ando.pearwood.info>
Message-ID: <86D78733-0BE2-46D1-AE1F-86F202657D32@klankschap.nl>


Floris van Manen <vm at klankschap.nl> added the comment:

I know it has nothing todo with linspace.
But there seems to be a link to using numpy generated variables and not using them.
>From a naive point of view i?d expect the same results.
But it does not.
There is two functions, and two variables.
And from the four combinations, only one gives a non NAN error.

> On 12 Sep 2018, at 20:19, Steven D'Aprano <report at bugs.python.org> wrote:
> 
> 
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
> 
>> Well, the thing is that i pass two (apparent) identical values into the same function,
> 
> Even if they have the same *numeric* value, they aren't the same kind of
> value, and they aren't the same function.
> 
> One is <type 'numpy.float64'> and the other is <class 'float'>. When you
> call ** (exponentiation), that calls two different methods. One raises
> a warning and returns NAN, the other converts to complex.
> 
> This has nothing to do with linspace. See my simplifed example code
> which doesn't use it.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34645>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34645>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:06:46 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 19:06:46 +0000
Subject: [issue34646] remove PyAPI_* from function definitions
In-Reply-To: <1536772944.12.0.956365154283.issue34646@psf.upfronthosting.co.za>
Message-ID: <1536779206.06.0.956365154283.issue34646@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset e5024517811ee990b770fca0ba7058742d00e032 by Benjamin Peterson in branch 'master':
closes bpo-34646: Remove PyAPI_* macros from declarations. (GH-9218)
https://github.com/python/cpython/commit/e5024517811ee990b770fca0ba7058742d00e032


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34646>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:08:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 19:08:22 +0000
Subject: [issue34647] print sys.thread_info in regrtest header
Message-ID: <1536779302.68.0.956365154283.issue34647@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

It might be useful to see the thread implementation info in the header.

----------
components: Tests
messages: 325170
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: print sys.thread_info in regrtest header
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34647>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:09:30 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 19:09:30 +0000
Subject: [issue34647] print sys.thread_info in regrtest header
In-Reply-To: <1536779302.68.0.956365154283.issue34647@psf.upfronthosting.co.za>
Message-ID: <1536779370.17.0.956365154283.issue34647@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8652
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34647>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:14:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Sep 2018 19:14:38 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536779678.66.0.956365154283.issue31577@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0bd1a2dcfdf36b181385ae61361e7692f4ebb0fd by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-31577: Fix a crash in os.utime() in case of a bad ns argument. (GH-3752)
https://github.com/python/cpython/commit/0bd1a2dcfdf36b181385ae61361e7692f4ebb0fd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:14:59 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 19:14:59 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536779699.62.0.956365154283.issue31577@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8653

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:23:47 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 19:23:47 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536780227.42.0.956365154283.issue34247@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +8654
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:26:49 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 19:26:49 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536780409.58.0.956365154283.issue34247@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

PR 9223 adds Nick's proposed wording to the 3.7 What's News.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:28:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 19:28:18 +0000
Subject: [issue34647] print sys.thread_info in regrtest header
In-Reply-To: <1536779302.68.0.956365154283.issue34647@psf.upfronthosting.co.za>
Message-ID: <1536780498.11.0.956365154283.issue34647@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, this is already in "make pythoninfo", which is enough, I think.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34647>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:46:33 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 19:46:33 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536781593.46.0.956365154283.issue31577@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 329ea4ef7cc3a907a64c6f0702fc93206b6744de by Miss Islington (bot) in branch '3.7':
bpo-31577: Fix a crash in os.utime() in case of a bad ns argument. (GH-3752)
https://github.com/python/cpython/commit/329ea4ef7cc3a907a64c6f0702fc93206b6744de


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Wed Sep 12 15:48:37 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 19:48:37 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536781717.13.0.956365154283.issue34004@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8655
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:03:24 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 12 Sep 2018 20:03:24 +0000
Subject: [issue34648] Confirm the type of traceback.format_list post-3.5
Message-ID: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

So I'm fixing a bug in typeshed's accounting of the traceback module (https://github.com/python/typeshed/pull/2436) and the documented semantics of traceback.format_list don't quite smell to me what I think they might be intended to be:

1) I know it has the name "format_list", but is it really intended to require a list? Why not a sequence, or a collection, or an iterable? I would think it would be fine to pass an iterable to traceback.format_list. Is it fine?

2) What is the desired component type for the aggregate passed to format_list? In 3.4-and-earlier it was Tuple[str, int, str, Optional[str]], and that still works in 3.5-through-3.8, but is that just backwards compatibility or is that something that users of traceback.format_list should feel encouraged to continue passing into the future?

Sorry for filing a bug just to ask "huh; really?" but... please confirm?

----------
assignee: docs at python
components: Documentation
messages: 325175
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: Confirm the type of traceback.format_list post-3.5
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:29:15 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 12 Sep 2018 20:29:15 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1536784155.39.0.956365154283.issue34648@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

... and while we're here, how about StackSummary.from_list's "a_list" parameter as well:

3) Can it be Iterable? It looks like it can be Iterable? Is it fine for it to be Iterable?

4) Should the component type of "a_list" be FrameSummary? Is the support for Tuple[str, int, str, Optional[str]] merely backward-looking, or is new code encouraged to pass Tuple[str, int, str, Optional[str]] objects?

----------
title: Confirm the type of traceback.format_list post-3.5 -> Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:42:59 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 12 Sep 2018 20:42:59 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
Message-ID: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyUnicode_InternFromString() is not checked for NULL and then dereferenced at three places in https://github.com/python/cpython/blob/0bd1a2dcfdf36b181385ae61361e7692f4ebb0fd/Modules/_json.c#L1369

Reported by Svace static analyzer.

----------
components: Extension Modules
messages: 325177
nosy: benjamin.peterson, berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Modules/_json.c: Missing NULL checks in _encoded_const()
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/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:45:31 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 12 Sep 2018 20:45:31 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536785131.68.0.956365154283.issue34649@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8656
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:48:07 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 20:48:07 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536785287.6.0.956365154283.issue34004@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 5b10d5111d7a855297654af9045f8907b7d3dd08 by Benjamin Peterson in branch 'master':
closes bpo-34004: Skip lock interruption tests on musl. (GH-9224)
https://github.com/python/cpython/commit/5b10d5111d7a855297654af9045f8907b7d3dd08


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:48:15 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 20:48:15 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536785295.32.0.956365154283.issue34004@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8657

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:48:22 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 20:48:22 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536785302.87.0.956365154283.issue34004@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8658

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:51:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 20:51:22 +0000
Subject: [issue34650] test_posix fails with musl
Message-ID: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_posix.py", line 1280, in test_get_and_set_scheduler_and_param
    mine = posix.sched_getscheduler(0)
OSError: [Errno 38] Function not implemented
======================================================================
ERROR: test_setscheduler_only_param (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_posix.py", line 1651, in test_setscheduler_only_param
    policy = os.sched_getscheduler(0)
OSError: [Errno 38] Function not implemented
======================================================================
ERROR: test_setscheduler_with_policy (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_posix.py", line 1669, in test_setscheduler_with_policy
    policy = os.sched_getscheduler(0)
OSError: [Errno 38] Function not implemented
----------------------------------------------------------------------

----------
components: Tests
messages: 325179
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_posix fails with musl
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:54:35 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 20:54:35 +0000
Subject: [issue34650] test_posix fails with musl
In-Reply-To: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>
Message-ID: <1536785675.71.0.956365154283.issue34650@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8659
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:03:57 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 12 Sep 2018 21:03:57 +0000
Subject: [issue34630] Don't log ssl cert errors in asyncio
In-Reply-To: <1536685169.66.0.0269046726804.issue34630@psf.upfronthosting.co.za>
Message-ID: <1536786237.24.0.956365154283.issue34630@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 0dd71807a98c4a86ece2aea869ea99f09204b16b by Andrew Svetlov in branch 'master':
bpo-34630: Skip logging SSL certificate errors by asyncio code (GH-9169)
https://github.com/python/cpython/commit/0dd71807a98c4a86ece2aea869ea99f09204b16b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34630>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:04:23 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 12 Sep 2018 21:04:23 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
Message-ID: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

os.fork() potentially has some problematic behavior when called from a subinterpreter.  In additional to the normal fork+threads madness, there's the question of what to do with existing subinterpreters.  The simplest solution is to simply disallow fork in a subinterpreter and then wipe out all subinterpreters in the child process post-fork (if os.fork() called in the main interpreter).

----------
assignee: eric.snow
components: Interpreter Core
messages: 325181
nosy: eric.snow, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Disallow fork in a subinterpreter.
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:04:24 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 21:04:24 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1536786264.96.0.956365154283.issue34282@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8660

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34282>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:05:23 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 21:05:23 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536786323.86.0.956365154283.issue34649@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 6f82bffd2df63a4072b3f0483cdbe93ddedb87e9 by Berker Peksag (Alexey Izbyshev) in branch 'master':
bpo-34649: Add missing NULL checks to _encoded_const() (GH-9225)
https://github.com/python/cpython/commit/6f82bffd2df63a4072b3f0483cdbe93ddedb87e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:05:33 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 21:05:33 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536786333.43.0.956365154283.issue34649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8661

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:05:41 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 21:05:41 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536786341.44.0.956365154283.issue34649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8662

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:05:52 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 21:05:52 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536786352.29.0.956365154283.issue34649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8663

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:11:00 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 21:11:00 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536786660.01.0.956365154283.issue34004@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b608fcd444c00ff37a19d34e4eeadb1221fb6436 by Miss Islington (bot) in branch '3.7':
closes bpo-34004: Skip lock interruption tests on musl. (GH-9224)
https://github.com/python/cpython/commit/b608fcd444c00ff37a19d34e4eeadb1221fb6436


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:11:48 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 21:11:48 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536786708.86.0.956365154283.issue34004@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a435eac1b83f080c9dfceff0de0d639541e4bcb by Miss Islington (bot) in branch '3.6':
closes bpo-34004: Skip lock interruption tests on musl. (GH-9224)
https://github.com/python/cpython/commit/5a435eac1b83f080c9dfceff0de0d639541e4bcb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:16:19 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 12 Sep 2018 21:16:19 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536786979.04.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8664

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:43:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 21:43:38 +0000
Subject: [issue34652] never enable lchmod on Linux
Message-ID: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

You can't modify the mode of symbolic links on Linux. Thus, lchmod is a useless function. libc may, however, define a lchmod stub that always returns an error. autoconf has a check that detects the dummy stub for glibc, but it detects lchmod as working on musl. I propose we simply always disable lchmod if the target system is Linux.

----------
components: Build
messages: 325185
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: never enable lchmod on Linux
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:46:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 21:46:44 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536788804.02.0.956365154283.issue34649@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset ec4d099b9f1951b08d1a53181c278173ff6a0cc1 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-34649: Add missing NULL checks to _encoded_const() (GH-9225)
https://github.com/python/cpython/commit/ec4d099b9f1951b08d1a53181c278173ff6a0cc1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:47:16 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 21:47:16 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536788836.67.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8665
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:50:55 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 21:50:55 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536789055.8.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

this also happens in 3.6.  whatever the problem is, it has been around a long time.

----------
priority: release blocker -> deferred blocker
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:54:21 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 21:54:21 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536789261.92.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

and I do agree that it is somewhat random.  while i have some situations where I can reproduce this, i have others where I can rerun exactly the same binary and single process single thread process running just test_pkg.py and nothing else where the behavior differs between runs in terms of which of test_4 and test_7 fail or not.

----------
title: importlib: python -m test test_pkg fails -> importlib: python -m test test_pkg fails semi-randomly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:58:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 12 Sep 2018 21:58:05 +0000
Subject: [issue34653] PyParser_SimpleParseStringFilename should be deleted
Message-ID: <1536789485.93.0.956365154283.issue34653@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

There are 6 PyParser_SimpleParse* functions in pythonrun.c. 5 of them are documented in c-api/veryhigh.rst and appear in pythonrun.h. But PyParser_SimpleParseStringFilename is not documented and is not in any .h file.

I propose we delete PyParser_SimpleParseStringFilename. It's not documented, it's not in a .h file, and it's not called from within Python's source. It's also trivial to implement in terms of PyParser_SimpleParseStringFlagsFilename.

----------
assignee: eric.smith
components: Interpreter Core
messages: 325189
nosy: eric.smith
priority: normal
severity: normal
status: open
title: PyParser_SimpleParseStringFilename should be deleted
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34653>
_______________________________________

From report at bugs.python.org  Wed Sep 12 17:58:43 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 12 Sep 2018 21:58:43 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536789523.85.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8666

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:00:14 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 22:00:14 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536789614.49.0.956365154283.issue34649@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 6d726868cd1743623a28b8e048e31b9c3c52a399 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-34649: Add missing NULL checks to _encoded_const() (GH-9225)
https://github.com/python/cpython/commit/6d726868cd1743623a28b8e048e31b9c3c52a399


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:00:59 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 22:00:59 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536789659.75.0.956365154283.issue34649@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 669429fb583031c7c87392e30b065e99a2d8ccda by Berker Peksag (Miss Islington (bot)) in branch '2.7':
bpo-34649: Add missing NULL checks to _encoded_const() (GH-9225)
https://github.com/python/cpython/commit/669429fb583031c7c87392e30b065e99a2d8ccda


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:01:10 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Sep 2018 22:01:10 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1536789670.29.0.956365154283.issue34455@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The crash can also be reproduced with a Spanish keyboard selected and using the Tcl/Tk wish shell edit text demo.  So it's definitely not a Python (tkinter or IDLE) issue.  I see that Kevin Walzer, the primary maintainer for Tk on macOS, is CC here.  If anyone wants this issue to be addressed, someone should probably check the Tck/Tk issue tracker and, if the problem hasn't already been reported, open an issue there:

https://core.tcl.tk/tk/ticket

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:01:37 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 22:01:37 +0000
Subject: [issue34649] Modules/_json.c: Missing NULL checks in _encoded_const()
In-Reply-To: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>
Message-ID: <1536789697.26.0.956365154283.issue34649@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks, Alexey!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:03:53 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 22:03:53 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536789833.71.0.956365154283.issue34200@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:09:01 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 22:09:01 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536790141.51.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

kinda poking at ideas here, but from a lunch conversation could this be related to the filesystem iteration order within the temp directories.

assigned to me while i investigate possibilities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:12:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:12:27 +0000
Subject: [issue34650] test_posix fails with musl
In-Reply-To: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>
Message-ID: <1536790347.66.0.956365154283.issue34650@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset c7042224b8a67748f125c22836862483f81a87a6 by Benjamin Peterson in branch 'master':
closes bpo-34650: Check if sched_getscheduler returns ENOSYS before declaring it supported. (GH-9228)
https://github.com/python/cpython/commit/c7042224b8a67748f125c22836862483f81a87a6


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:17:56 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:17:56 +0000
Subject: [issue34650] test_posix fails with musl
In-Reply-To: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>
Message-ID: <1536790676.13.0.956365154283.issue34650@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8667

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:20:00 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:20:00 +0000
Subject: [issue34650] test_posix fails with musl
In-Reply-To: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>
Message-ID: <1536790800.1.0.956365154283.issue34650@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8668

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:21:02 2018
From: report at bugs.python.org (Anthony Flury)
Date: Wed, 12 Sep 2018 22:21:02 +0000
Subject: [issue21258] Add __iter__ support for mock_open
In-Reply-To: <1397671005.18.0.0743040241878.issue21258@psf.upfronthosting.co.za>
Message-ID: <1536790862.15.0.956365154283.issue21258@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

The lack of dunder_iter support on mock_open has been resolved in Issue 32933 (Git Hub 5974).

Can I suggest that once the above PR is merged into 3.8 (due imminently allegedly <smile>), that we should then backport that fix into 3.5, 3.6 & 3.7 as a minimum ?

I am by no means an expert though.

----------
nosy: +anthony-flury

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21258>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:21:19 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 22:21:19 +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: <1536790879.54.0.956365154283.issue32933@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 2087023fdec2c89070bd14f384a3c308c548a94a by Berker Peksag (Tony Flury) in branch 'master':
bpo-32933: Implement __iter__ method on mock_open() (GH-5974)
https://github.com/python/cpython/commit/2087023fdec2c89070bd14f384a3c308c548a94a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:24:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 22:24:40 +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: <1536791080.8.0.956365154283.issue32933@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the patch, Anthony.I consider this a new feature, so I removed 3.6 and 3.7 from the versions field. We can backport to 3.7 if other core developers think that it's worth to fix in the latest maintenance branch.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: behavior -> enhancement
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:27:20 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Sep 2018 22:27:20 +0000
Subject: [issue21258] Add __iter__ support for mock_open
In-Reply-To: <1397671005.18.0.0743040241878.issue21258@psf.upfronthosting.co.za>
Message-ID: <1536791240.34.0.956365154283.issue21258@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Closing this as a duplicate of issue 32933. Let's discuss backporting to maintenance branches there.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> mock_open does not support iteration around text files.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21258>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:29:46 2018
From: report at bugs.python.org (Joseph Sible)
Date: Wed, 12 Sep 2018 22:29:46 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536791386.55.0.956365154283.issue34004@psf.upfronthosting.co.za>


Joseph Sible <josephcsible at gmail.com> added the comment:

How is this considered "fixed"? Why couldn't this be actually fixed by using eventfd instead of semaphores when they're available, for example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:34:52 2018
From: report at bugs.python.org (Anthony Flury)
Date: Wed, 12 Sep 2018 22:34:52 +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: <1536791692.69.0.956365154283.issue32933@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

Berker,
Thanks for your work on getting this complete.

I would strongly support backporting if possible.

3.5 and 3.6 will be in common use for a while (afaik 3.6 has only now got delivered to Ubuntu as the default Python 3), and this does fix does allow full testing of what would be considered pythonic code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:36:44 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:36:44 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536791804.63.0.956365154283.issue34004@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Reimplementing locks with eventfd can be another issue. Such a change can only land in a new Python version, though. We'll just have to consider musl unsupported for interrupting locks in our current maintenance releases as I have done.

How likely is it that musl will change to allow returning EINTR from sem_timedwait given that the only stated reason not to is very old kernel versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:39:41 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:39:41 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
Message-ID: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

POSIX allows the '%Y' format in strftime to start with a '+' sign for years with more than 4 digits. test_time is not tolerant of that, which leads to failures like this with musl:

======================================================================
FAIL: test_large_year (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 683, in test_large_year
    return super().test_large_year()
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 706, in test_large_year
    self.assertEqual(self.yearstr(12345), '12345')
AssertionError: '+12345' != '12345'
- +12345
? -
+ 12345

----------
components: Tests
messages: 325203
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_time needs to handle '+' at the beginning of large years
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:47:58 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:47:58 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
In-Reply-To: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>
Message-ID: <1536792478.72.0.956365154283.issue34654@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8669
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:52:43 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:52:43 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536792763.52.0.956365154283.issue34652@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 40caa05fa4d1810a1a6bfc34e0ec930c351089b7 by Benjamin Peterson in branch 'master':
closes bpo-34652: Always disable lchmod on Linux. (GH-9234)
https://github.com/python/cpython/commit/40caa05fa4d1810a1a6bfc34e0ec930c351089b7


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:52:52 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 22:52:52 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536792772.87.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8670

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:53:00 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 22:53:00 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536792780.01.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8671

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:56:11 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:56:11 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536792971.8.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8672

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:57:34 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:57:34 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536793054.47.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8673

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:58:51 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 22:58:51 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536793131.29.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 18:58:59 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 22:58:59 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536793139.56.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8675

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:00:09 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 23:00:09 +0000
Subject: [issue34650] test_posix fails with musl
In-Reply-To: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>
Message-ID: <1536793209.9.0.956365154283.issue34650@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 0aef909d630ff40614cde0c58796a8bdf66c67eb by Benjamin Peterson in branch '3.7':
[3.7] closes bpo-34650: Check if sched_getscheduler returns ENOSYS before declaring it supported. (GH-9236)
https://github.com/python/cpython/commit/0aef909d630ff40614cde0c58796a8bdf66c67eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:00:30 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 23:00:30 +0000
Subject: [issue34650] test_posix fails with musl
In-Reply-To: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>
Message-ID: <1536793230.33.0.956365154283.issue34650@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset e105e551dbf072d773aaa1fd6f8cbda218c273f0 by Benjamin Peterson in branch '3.6':
[3.6] closes bpo-34650: Check if sched_getscheduler returns ENOSYS before declaring it supported. (GH-9237)
https://github.com/python/cpython/commit/e105e551dbf072d773aaa1fd6f8cbda218c273f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34650>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:03:18 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Wed, 12 Sep 2018 23:03:18 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1536793398.95.0.956365154283.issue34603@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

I think the problem is that FFI layer assumes that MSVC compiler will try to pass any structure less than 8 bytes in registers whereis it is not always true: 
To be returned by value in RAX, user-defined types must have a length of 1, 2, 4, 8, 16, 32, or 64 bits (from https://msdn.microsoft.com/en-us/library/7572ztz4.aspx).
I have a fix, now adding tests.

----------
nosy: +v2m

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:03:35 2018
From: report at bugs.python.org (Joseph Sible)
Date: Wed, 12 Sep 2018 23:03:35 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1530308617.47.0.56676864532.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536793415.61.0.956365154283.issue34004@psf.upfronthosting.co.za>


Joseph Sible <josephcsible at gmail.com> added the comment:

Re musl changing their behavior, see https://www.openwall.com/lists/musl/2018/09/07/1 and the resulting thread.

In addition to the old kernel version issue, two other issues were raised:
1. EINTR makes programming mistakes more likely, as people won't think to handle it. I don't give much weight to this point.
2. Most of the time, counting on receiving an EINTR results in race conditions. Our code seems to be affected by this too. Even on glibc, a signal at just the "right" time could result in it not being interrupted. This is why I think moving to an eventfd or something would be better, since we could then use pselect/ppoll/etc. to avoid the signal blocking race.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:21:43 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 23:21:43 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
In-Reply-To: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>
Message-ID: <1536794503.02.0.956365154283.issue34654@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset e1a34ceb541ef87e03bb428630097dacc9c658e5 by Benjamin Peterson in branch 'master':
closes bpo-34654: Tolerate + at the beginning of large years. (GH-9238)
https://github.com/python/cpython/commit/e1a34ceb541ef87e03bb428630097dacc9c658e5


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:21:49 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 23:21:49 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
In-Reply-To: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>
Message-ID: <1536794509.87.0.956365154283.issue34654@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8676

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:21:56 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 23:21:56 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
In-Reply-To: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>
Message-ID: <1536794516.79.0.956365154283.issue34654@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8677

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:31:21 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 23:31:21 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536795081.93.0.956365154283.issue34652@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 69e96910153219b0b15a18323b917bd74336d229 by Benjamin Peterson in branch '2.7':
[2.7] closes bpo-34652: Always disable lchmod on Linux. (GH-9242)
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:33:39 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 23:33:39 +0000
Subject: [issue34004] Acquiring locks not interrupted by signals on musl libc
In-Reply-To: <1536793415.61.0.956365154283.issue34004@psf.upfronthosting.co.za>
Message-ID: <1536795216.3905236.1506231144.3997AE95@webmail.messagingengine.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Wed, Sep 12, 2018, at 16:03, Joseph Sible wrote:
> 2. Most of the time, counting on receiving an EINTR results in race 
> conditions. Our code seems to be affected by this too. Even on glibc, a 
> signal at just the "right" time could result in it not being 
> interrupted. This is why I think moving to an eventfd or something would 
> be better, since we could then use pselect/ppoll/etc. to avoid the 
> signal blocking race.

The race is a good point.

However, switching to eventfd is not trivial. It would be the third locking implementation in python just for pthreads. Using eventfd would require reimplementing all the userspace parts of locking (atomics, appropriate memory barriers, and spinning) ourselves. futex is carefully optimized for userspace locking, whereas I've never heard of normal program locking being done with eventfd before.

If the expected usecase for interrupting locks is user pressing C-c, being 99.99999% correct is probably enough.

So, it's fine with me if you open another issue for reimplementing locks with eventfd. But, I don't personally have the desire to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34004>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:36:09 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 23:36:09 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536795369.17.0.956365154283.issue34652@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 98344a4f2f09ddae295352ec54fae6388446eeaf by Miss Islington (bot) in branch '3.7':
closes bpo-34652: Always disable lchmod on Linux. (GH-9234)
https://github.com/python/cpython/commit/98344a4f2f09ddae295352ec54fae6388446eeaf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:36:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 23:36:22 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536795382.66.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8678

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:43:23 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 23:43:23 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536795803.83.0.956365154283.issue34652@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bdace2ea53c578184235729a4cf383891084cc70 by Miss Islington (bot) in branch '3.6':
closes bpo-34652: Always disable lchmod on Linux. (GH-9234)
https://github.com/python/cpython/commit/bdace2ea53c578184235729a4cf383891084cc70


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:49:59 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 12 Sep 2018 23:49:59 +0000
Subject: [issue34655] Support sendfile in asyncio streams API
Message-ID: <1536796199.79.0.956365154283.issue34655@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Support sendfile in asyncio streams API
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34655>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:53:09 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 12 Sep 2018 23:53:09 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536796389.57.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I can make the test reliable... but I wouldn't say I fully understand the ultimate cause of the problem.

The reliability fix for test_pkg is to stop using test.support.modules_setup() and test.support.modules_cleanup() in the setUp() and tearDown() methods.

these test support functions are semi scary.  they attempt to backup and replace sys.modules contents with special case code in the cleanup function to try and avoid doing that to things that are still necessary.

running python -vvv when I could get test_pkg to fail led me looking at code paths that were being executed mid-test that i'd expect to be executed only on process startup.  locale.getpreferredencoding triggering a _bootlocale import, etc.  I don't understand why it cause the problem though.

PR to at least make the test reliable coming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 19:54:14 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Sep 2018 23:54:14 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
In-Reply-To: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>
Message-ID: <1536796454.3.0.956365154283.issue34654@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ea2fcd3db65b796ad3eda1619a903cefb1aa9363 by Miss Islington (bot) in branch '3.7':
closes bpo-34654: Tolerate + at the beginning of large years. (GH-9238)
https://github.com/python/cpython/commit/ea2fcd3db65b796ad3eda1619a903cefb1aa9363


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:00:59 2018
From: report at bugs.python.org (Sebastian Rittau)
Date: Thu, 13 Sep 2018 00:00:59 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1536796859.41.0.956365154283.issue34648@psf.upfronthosting.co.za>


Change by Sebastian Rittau <srittau at rittau.biz>:


----------
nosy: +srittau

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:03:31 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 00:03:31 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536797011.58.0.956365154283.issue34200@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +8679
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:05:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 13 Sep 2018 00:05:20 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536797120.73.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 5b7cbd602e57265604d6c099fd174b1c7917f861 by Yury Selivanov (Carol Willing) in branch 'master':
bpo-33649: Edit asyncio eventloop doc - second pass (GH-9233)
https://github.com/python/cpython/commit/5b7cbd602e57265604d6c099fd174b1c7917f861


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:06:57 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 00:06:57 +0000
Subject: [issue34654] test_time needs to handle '+' at the beginning of large
 years
In-Reply-To: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>
Message-ID: <1536797217.24.0.956365154283.issue34654@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 21a808230aa33741f1dd9bf38f0e283c1b72210e by Miss Islington (bot) in branch '3.6':
closes bpo-34654: Tolerate + at the beginning of large years. (GH-9238)
https://github.com/python/cpython/commit/21a808230aa33741f1dd9bf38f0e283c1b72210e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34654>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:08:02 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 13 Sep 2018 00:08:02 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536797282.5.0.956365154283.issue34200@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Did you attempt to use the 3-line change I posted earlier?  I stepped through to test line-by-line to find the offending piece of code.  And it was indeed the open() call causing the test-tree to be processed prior to it being completed.  Thus making the .py file seen before the directory of same name would exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:14:42 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 00:14:42 +0000
Subject: [issue34641] Curiosity: f((a)=1) is not a syntax error -- why?
In-Reply-To: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>
Message-ID: <1536797682.65.0.956365154283.issue34641@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset c9a71dd223c4ad200a97aa320aef6bd3d45f8897 by Benjamin Peterson in branch 'master':
closes bpo-34641: Further restrict the LHS of keyword argument function call syntax. (GH-9212)
https://github.com/python/cpython/commit/c9a71dd223c4ad200a97aa320aef6bd3d45f8897


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34641>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:22:14 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 00:22:14 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536798134.96.0.956365154283.issue34652@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset ed709d5699716bf7237856dc20aba321e2dfff6d by Benjamin Peterson in branch 'master':
bpo-34652: Remove lchmod from the big func checking block. (GH-9247)
https://github.com/python/cpython/commit/ed709d5699716bf7237856dc20aba321e2dfff6d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:22:24 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 00:22:24 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536798144.48.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8680

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:24:44 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 00:24:44 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536798284.22.0.956365154283.issue34652@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8681

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:25:14 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Sep 2018 00:25:14 +0000
Subject: [issue34643] How to build Release Version of Python in Windows?
In-Reply-To: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>
Message-ID: <1536798314.37.0.956365154283.issue34643@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Have a look in the Tools/msi directory. The "build.bat" and "buildrelease.bat" files will generate the installers and other packages (note that you may need .NET 3.5 enabled on your machine).

You may also be able to use the make_zip.py script to help create a "full" distribution in a specific directory. Though it may still exclude Tcl and Tk (deliberately). It's not meant for replacing the full installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34643>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:26:42 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 00:26:42 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536798402.5.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

this is also present in 3.5, but it'll be up to the 3.5 release manager to cherry pick the test_pkg.py reliability fix into the 3.5 branch if it impacts them during the release process.

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:32:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 00:32:23 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1536798743.06.0.956365154283.issue34595@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8682

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:37:51 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 00:37:51 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536799071.14.0.956365154283.issue34652@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 2184fe5ba48a58cb51be144230622b84b372644c by Benjamin Peterson in branch '3.6':
[3.6] bpo-34652: Remove lchmod from the big func checking block. (GH-9250)
https://github.com/python/cpython/commit/2184fe5ba48a58cb51be144230622b84b372644c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:58:45 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 00:58:45 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536800325.01.0.956365154283.issue34200@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4ae8ece5cd4c5853b625381db13429f25512108d by Miss Islington (bot) (Gregory P. Smith) in branch 'master':
bpo-34200: Fix non-determinism of test_pkg (GH-9248)
https://github.com/python/cpython/commit/4ae8ece5cd4c5853b625381db13429f25512108d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:58:52 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 00:58:52 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536800332.06.0.956365154283.issue34200@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8683

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 20:58:58 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 00:58:58 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536800338.92.0.956365154283.issue34200@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8684

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 21:29:13 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 01:29:13 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536802153.17.0.956365154283.issue34200@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 90f7d455b7f4bd53d3af11cb951347c9c8230399 by Miss Islington (bot) in branch '3.7':
bpo-34200: Fix non-determinism of test_pkg (GH-9248)
https://github.com/python/cpython/commit/90f7d455b7f4bd53d3af11cb951347c9c8230399


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 21:29:36 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 01:29:36 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536802176.48.0.956365154283.issue34200@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3e3d4a4b55cbef481486aaa68ee255f4928b9c3f by Miss Islington (bot) in branch '3.6':
bpo-34200: Fix non-determinism of test_pkg (GH-9248)
https://github.com/python/cpython/commit/3e3d4a4b55cbef481486aaa68ee255f4928b9c3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 21:32:06 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 01:32:06 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536802326.26.0.956365154283.issue34200@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I still feel like there is an underlying issue within the import system that use of test.support.modules_cleanup somehow triggers that I never managed to really understand.

but the particular issue in this bug that people were seeing frequently is fixed.

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Wed Sep 12 22:07:42 2018
From: report at bugs.python.org (hongweipeng)
Date: Thu, 13 Sep 2018 02:07:42 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1536804462.71.0.956365154283.issue34410@psf.upfronthosting.co.za>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
pull_requests: +8685

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Wed Sep 12 22:31:24 2018
From: report at bugs.python.org (Valentin Zhao)
Date: Thu, 13 Sep 2018 02:31:24 +0000
Subject: [issue34643] How to build Release Version of Python in Windows?
In-Reply-To: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>
Message-ID: <1536805884.32.0.956365154283.issue34643@psf.upfronthosting.co.za>


Valentin Zhao <jmsqzzl at gmail.com> added the comment:

Sorry for not illustrating this clearly. What I need to build is a copyable, relocatable bunch of files which contains a directory like \bin then has an executable in it, so I can run Python directly. Notwithstanding I do not need a installer because I am not supposed to alter user's configuration. Thanks for your patience in advance!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34643>
_______________________________________

From report at bugs.python.org  Thu Sep 13 00:03:15 2018
From: report at bugs.python.org (shashank)
Date: Thu, 13 Sep 2018 04:03:15 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1536811395.97.0.956365154283.issue21109@psf.upfronthosting.co.za>


shashank <shanx.shashank at gmail.com> added the comment:

1. I have done some changes to Lar's patch to address class of bugs which Jakub found.
Attached patch safetarfile-2.diff 
Patch is for code only and is work in progress.

2. However, there maybe several edge cases which have not been covered. Going by types of bugs we want to catch:

  * Don't allow creating files whose absolute path is not under the
    destination.
  * Don't allow creating links (hard or soft) which link to a path
    outside of the destination.
  * Don't create device nodes.


I suspect there may be more so which haven't been mentioned yet, one of which I have listed below.


3. Now, on to patch, Safetar now tries to keep a list of symlinks it has seen so far and tries to figure effective path of current name which may use symlinks. This approach does address bugs found in Jakub's comment, details below, but when symlink's link has a symlink in it, there are cases which this impl. let slip.

For example:
	# tar -tvf dirsym_rouge.tar
	drwxr-xr-x root/root         0 2018-09-12 19:03 dirsym/
	lrwxrwxrwx root/root         0 2018-09-12 18:39 dirsym/sym -> .
	lrwxrwxrwx root/root         0 2018-09-12 19:02 dirsym/symsym3 -> ../dirsym/sym/../..

	This escapes the check since, given name "../dirsym/sym/../.." translates to "..", ideally this should have given relative link warning.
	Above symlink is valid.

But for:
	# tar -tvf dirsym.tar
	drwxr-xr-x root/root         0 2018-09-12 18:44 dirsym/
	lrwxrwxrwx root/root         0 2018-09-12 18:44 dirsym/sym -> .
	lrwxrwxrwx root/root         0 2018-09-12 18:44 dirsym/symsym -> dirsym/sym/../..

	This fails with warning of relative link name, as expected.
	given name "dirsym/sym/../.." translates to "../.."
	However, the symlink points to invalid path which may or maynot be useful.


4. Regarding bugs reported by Jakub, following enumerates the effective name that gets computed by Safetar:

	absolute1.tar
		"/tmp/moo" translates to "/tmp/moo"

	absolute2.tar
		"//tmp/moo" translates to "//tmp/moo"

	dirsymlink.tar
		"tmp" translates to "tmp"
		"/tmp" translates to "tmp"

	dirsymlink2a.tar
		"cur" translates to "cur"
		"." translates to "."
		"par" translates to "par"
		"cur/.." translates to  ".."
		"par/moo" translates to "../moo"


	dirsymlink2b.tar
		"cur" translates to "cur"
		"." translates to "."
		"cur/par" translates to "par"
		".." translates to ".."
		"par/moo" translates to "../moo"


	relative0.tar
		"../moo" translates to "../moo"

	relative2.tar
		"tmp/../../moo" translates to "../moo"

	symlink.tar
		"moo" translates to "moo"
		"/tmp/moo" translates to "/tmp/moo"

----------
Added file: https://bugs.python.org/file47800/safetarfile-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Thu Sep 13 00:38:47 2018
From: report at bugs.python.org (shuoz)
Date: Thu, 13 Sep 2018 04:38:47 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
Message-ID: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>


New submission from shuoz <zzw20124321 at gmail.com>:

python version:
   Python 3.8.0a0 (heads/master:4ae8ece, Sep 13 2018, 09:48:16) 
   [GCC 5.4.0 20160609] on linux


I found a bug in python pickle.load func. Can cause memory exhaustion DDOS.

./python pk.py poc


cat ./pk.py
import pickle
import sys
filename = sys.argv[1]
with open(filename, 'rb') as f:
    aa = pickle.load(f)
    print(aa)

----------
components: FreeBSD
files: poc
messages: 325230
nosy: koobs, shuoz
priority: normal
severity: normal
status: open
title: memory exhaustion in Modules/_pickle.c:1393
type: security
versions: Python 3.8
Added file: https://bugs.python.org/file47801/poc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 13 00:53:32 2018
From: report at bugs.python.org (shuoz)
Date: Thu, 13 Sep 2018 04:53:32 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1536814412.42.0.956365154283.issue34656@psf.upfronthosting.co.za>


Change by shuoz <zzw20124321 at gmail.com>:


Added file: https://bugs.python.org/file47802/pk.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 13 00:55:08 2018
From: report at bugs.python.org (shuoz)
Date: Thu, 13 Sep 2018 04:55:08 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1536814508.3.0.956365154283.issue34656@psf.upfronthosting.co.za>


shuoz <zzw20124321 at gmail.com> added the comment:

[----------------------------------registers-----------------------------------]
RAX: 0x7ff9d401e010 --> 0x0 
RBX: 0x7ffff7f48d00 --> 0x1 
RCX: 0x7ff8ab58c800 --> 0x7ffff7ea5d80 --> 0x2 
RDX: 0x7ffff3ac47d8 --> 0x1 
RSI: 0x25152303 
RDI: 0xfff3a803c00 --> 0x0 
RBP: 0x7473078c 
RSP: 0x7fffffffcf20 --> 0x7ffff3ac47d8 --> 0x1 
RIP: 0x7ffff28a8a64 (<_Unpickler_MemoPut+1668>:	add    r11,0x20)
R8 : 0xfff3a803bff --> 0x0 
R9 : 0xfff3a803c01 --> 0x0 
R10: 0xffffefe91a3 --> 0x0 
R11: 0x128a917f8 --> 0x0 
R12: 0xfff156b1922 --> 0x0 
R13: 0xe8e60f18 --> 0x0 
R14: 0x7ffff7f48d18 --> 0x7ff8ab58c800 --> 0x7ffff7ea5d80 --> 0x2 
R15: 0xfff3a803c02 --> 0x0
EFLAGS: 0x216 (carry PARITY ADJUST zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff28a8a52 <_Unpickler_MemoPut+1650>:	cmp    BYTE PTR [r15+0x7fff8000],0x0
   0x7ffff28a8a5a <_Unpickler_MemoPut+1658>:	jne    0x7ffff28a8ae1 <_Unpickler_MemoPut+1793>
   0x7ffff28a8a60 <_Unpickler_MemoPut+1664>:	add    rsi,0x4
=> 0x7ffff28a8a64 <_Unpickler_MemoPut+1668>:	add    r11,0x20
   0x7ffff28a8a68 <_Unpickler_MemoPut+1672>:	cmp    BYTE PTR [r10+0x7fff8000],0x0
   0x7ffff28a8a70 <_Unpickler_MemoPut+1680>:	mov    QWORD PTR [rax],0x0
   0x7ffff28a8a77 <_Unpickler_MemoPut+1687>:	je     0x7ffff28a896d <_Unpickler_MemoPut+1421>
   0x7ffff28a8a7d <_Unpickler_MemoPut+1693>:	nop    DWORD PTR [rax]
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffcf20 --> 0x7ffff3ac47d8 --> 0x1 
0008| 0x7fffffffcf28 --> 0xffffefe91a3 --> 0x0 
0016| 0x7fffffffcf30 --> 0x7ffff7f48da8 --> 0x20 (' ')
0024| 0x7fffffffcf38 --> 0x7ffff7f48d00 --> 0x1 
0032| 0x7fffffffcf40 --> 0xffffffffa00 --> 0x0 
0040| 0x7fffffffcf48 --> 0x0 
0048| 0x7fffffffcf50 --> 0x7ffff7f48da0 --> 0x28 ('(')
0056| 0x7fffffffcf58 --> 0x7ffff7f48da8 --> 0x20 (' ')
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x00007ffff28a8a64	1392	    for (i = self->memo_size; i < new_size; i++)
gdb-peda$ p new_size
$5 = 0xe8e60f18
gdb-peda$ p self->memo_size
$6 = 0x20
gdb-peda$ p i


.....
for (i = self->memo_size; i < new_size; i++)
        self->memo[i] = NULL;
.....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 13 01:29:13 2018
From: report at bugs.python.org (Valentin Zhao)
Date: Thu, 13 Sep 2018 05:29:13 +0000
Subject: [issue34643] How to build Release Version of Python in Windows?
In-Reply-To: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>
Message-ID: <1536816553.94.0.956365154283.issue34643@psf.upfronthosting.co.za>


Valentin Zhao <jmsqzzl at gmail.com> added the comment:

Or say what the difference of the python executable generated from msi installer and built from source?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34643>
_______________________________________

From report at bugs.python.org  Thu Sep 13 01:33:08 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 05:33:08 +0000
Subject: [issue34652] never enable lchmod on Linux
In-Reply-To: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>
Message-ID: <1536816788.23.0.956365154283.issue34652@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 35c94c765bf46e93a0d84e39dbc6eaaba40b1f36 by Miss Islington (bot) in branch '3.7':
bpo-34652: Remove lchmod from the big func checking block. (GH-9247)
https://github.com/python/cpython/commit/35c94c765bf46e93a0d84e39dbc6eaaba40b1f36


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34652>
_______________________________________

From report at bugs.python.org  Thu Sep 13 01:46:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Sep 2018 05:46:03 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1536817563.65.0.956365154283.issue34656@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +alexandre.vassalotti, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 13 01:54:03 2018
From: report at bugs.python.org (iMath)
Date: Thu, 13 Sep 2018 05:54:03 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1536818043.3.0.956365154283.issue27820@psf.upfronthosting.co.za>


iMath <redstone-cold at 163.com> added the comment:

I encountered the same issue ,  Dario D'Amico's changing works ! please fix the problem !

----------
nosy: +redstone-cold

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Thu Sep 13 02:10:52 2018
From: report at bugs.python.org (Mark Mikofski)
Date: Thu, 13 Sep 2018 06:10:52 +0000
Subject: [issue34657] pyconfig.h macro "timezone" name clashes with user
 source are likely
Message-ID: <1536819052.42.0.956365154283.issue34657@psf.upfronthosting.co.za>


New submission from Mark Mikofski <bwana.marko at yahoo.com>:

TL;DR: if PC user compiles source which defines "timezone" in a header, and includes Python.h after the header, then the macro also called "timezone" in pyconfig.h will redefine the users source, yielding unexpected results.

see Cython google group for an actual use case where this occurred:
https://groups.google.com/forum/#!topic/cython-users/pjbhYrpl_rU

trying to compile NREL SPA code which has a header file with a struct with a timezone field fails with the following traceback:
spa.h(88): error C2032: '__timezone': function cannot be member of struct '<anonymous-tag>'

here's the macro in PC/pyconfig.h in master as of 5489bdad
https://github.com/python/cpython/blob/5489bdad5143050b8bb89b648b3c00d951b72d4f/PC/pyconfig.h#L202

/* VS 2015 defines these names with a leading underscore */
#if _MSC_VER >= 1900
#define timezone _timezone
#define daylight _daylight
#define tzname _tzname
#endif

----------
components: Build
messages: 325235
nosy: bwanamarko
priority: normal
severity: normal
status: open
title: pyconfig.h macro "timezone" name clashes with user source are likely
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/issue34657>
_______________________________________

From report at bugs.python.org  Thu Sep 13 02:18:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 06:18:42 +0000
Subject: [issue34200] importlib: python -m test test_pkg fails semi-randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1536819522.11.0.956365154283.issue34200@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thank you for the fix Gregory!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Thu Sep 13 02:20:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 06:20:51 +0000
Subject: [issue31141] Start should be a keyword argument of the built-in sum
In-Reply-To: <1502193168.16.0.095124886528.issue31141@psf.upfronthosting.co.za>
Message-ID: <1536819651.92.0.956365154283.issue31141@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution: out of date -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31141>
_______________________________________

From report at bugs.python.org  Thu Sep 13 02:27:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 06:27:51 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1536820071.66.0.956365154283.issue21109@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Thu Sep 13 02:32:59 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 06:32:59 +0000
Subject: [issue34647] print sys.thread_info in regrtest header
In-Reply-To: <1536779302.68.0.956365154283.issue34647@psf.upfronthosting.co.za>
Message-ID: <1536820379.93.0.956365154283.issue34647@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Actually, this is already in "make pythoninfo", which is enough, I think.

Yeah, whenever possible, I try to avoid to "pollute" the regrtest header. In the past, we added more and more info, and at the end, the header became "giant" for no good reason. That's why I created pythoninfo which should now run on all CI (Travis CI, AppVeyor, buildbots, I don't know for VSTS).

I was going to suggest you to extend pythoninfo to log sys.thread_info, but you just wrote that it's already there. Good :-D

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34647>
_______________________________________

From report at bugs.python.org  Thu Sep 13 04:44:23 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 13 Sep 2018 08:44:23 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1536828263.19.0.956365154283.issue11192@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +8686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Thu Sep 13 05:47:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 13 Sep 2018 09:47:19 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1536832039.53.0.956365154283.issue34656@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 13 06:42:11 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 13 Sep 2018 10:42:11 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536835331.97.0.956365154283.issue34605@psf.upfronthosting.co.za>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Thu Sep 13 06:57:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 10:57:27 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
Message-ID: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Found in the stdlib test suite while testing the fix for bpo-6721: When subprocess is called with a preexec_fn and os.register_at_fork has been used and the fork() system call fails, the Python error state is set before the "after fork in parent process" function calls that were registered were called.  So they'd call back into Python code with a pending unreturned exception set.

boom.  SystemError (or assertion failure in pydebug builds).

----------
assignee: gregory.p.smith
messages: 325238
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: subprocess with preexec_fn when fork() fails could corrupt PyErr state
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 06:57:49 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 10:57:49 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536836269.05.0.956365154283.issue34658@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 07:03:14 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 11:03:14 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536836594.13.0.956365154283.issue34658@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +8687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 07:04:43 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 11:04:43 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536836683.57.0.956365154283.issue34658@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 07:30:15 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 11:30:15 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536838215.18.0.956365154283.issue34658@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a20b6adb5a5880fd22c099961eb9f9787739cefe by Miss Islington (bot) (Gregory P. Smith) in branch 'master':
bpo-34658: Fix rare subprocess prexec_fn fork error. (GH-9255)
https://github.com/python/cpython/commit/a20b6adb5a5880fd22c099961eb9f9787739cefe


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 07:30:23 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 11:30:23 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536838223.1.0.956365154283.issue34658@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8688

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 07:51:17 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 11:51:17 +0000
Subject: [issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option
In-Reply-To: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>
Message-ID: <1536839477.65.0.956365154283.issue34639@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Respecting -E and -I isn't a problem per se - the problem is moving the _Py_CoerceLegacyLocale call to a point that's incredibly late in the startup process *just* to get it to respect those flags.

I don't actually mind if you reinstate the extra pass through the command line arguments just to check for -E and -I early enough for it to affect a properly located call to _Py_CoerceLegacyLocale, I just don't think it's necessary to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34639>
_______________________________________

From report at bugs.python.org  Thu Sep 13 08:24:39 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Thu, 13 Sep 2018 12:24:39 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536841479.32.0.956365154283.issue34605@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

The discussion under GH PRs is now censored. What will be the next level?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Thu Sep 13 08:46:30 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 12:46:30 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536842790.96.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reviewing the way things are now, I don't think it's worth rearranging this yet again for 3.7 - instead, I'll just put it back the way I intended it to be (and the way the PEP describes) for 3.8.

The issue is that Victor had good reasons for moving the handling of the "PYTHONCOERCECLOCALE=warn" case to be after the low level C stdio streams were properly initialised, and retaining that aspect of the changes while still moving the C locale coercion back to the beginning of the program means changing the signature of _Py_CoerceLegacyLocale to return a stateless static string to be printed to stderr later.

----------
priority: release blocker -> normal
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 13 09:16:59 2018
From: report at bugs.python.org (Azat Ishmukhametovich Ibrakov)
Date: Thu, 13 Sep 2018 13:16:59 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
Message-ID: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>


New submission from Azat Ishmukhametovich Ibrakov <azatibrakov at gmail.com>:

Why there is an optional `initial` parameter for `functools.reduce` function, but there is no such for `itertools.accumulate`, when they both are doing kind of similar things except that `itertools.accumulate` yields intermediate results and `functools.reduce` only the final one?

----------
components: Library (Lib)
messages: 325243
nosy: lycantropos
priority: normal
severity: normal
status: open
title: Inconsistency between functools.reduce & itertools.accumulate
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Thu Sep 13 09:42:09 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 13:42:09 +0000
Subject: [issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option
In-Reply-To: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>
Message-ID: <1536846129.03.0.956365154283.issue34639@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the PYTHONCOERCECLOCALE=warn case, it turns out that my preferred approach to implementing bpo-34589 also naturally ends up respecting -I and -E for that (i.e. supplying -I or -E will suppressed the warning).

However, my upcoming PR for that also reinstates and expands on my original comment that explained why it was valuable to support "PYTHONCOERCECLOCALE=0 python3 -E ..." and "PYTHONCOERCECLOCALE=0 python3 -I ...": so you can readily reproduce the way that locale coercion behaves on a platform *without* a suitable target locale (e.g. CentOS 7), even if your current platform actually does have such a locale available (e.g. Fedora).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34639>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:15:18 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Sep 2018 14:15:18 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1536848118.0.0.956365154283.issue34659@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Presumably because conceptually an 'initial value' would be like adding an additional element on to the front of the iterable being passed as an argument, and itertools is all about operating on iterables.  I'm not saying such an argument could not be added, but the API is cleaner without it.

----------
nosy: +r.david.murray
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:15:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 14:15:32 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536848132.84.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The actual functional error is that the following will currently give different outputs on Fedora and CentOS 7, whereas in the original PEP 538 implementation it would always print "C", even if locale coercion would otherwise normally work on your current platform:

    LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -E -c 'import os; print(os.env["LC_CTYPE"])'


As per the comment that was deleted in https://github.com/python/cpython/commit/9454060e84a669dde63824d9e2fcaf295e34f687#diff-8c018c3ada66d06c8e101e47a313c2c7, that was an intentional behaviour to allow developers testing scripts that are invoked using -E and -I to pretend that their local C.UTF-8 locale didn't exist when trying to reproducing behaviour otherwise seen only when locale coercion fails due to the lack of a suitable coercion target.

I'm working on an alternate PR that restores that aspect of the original behaviour, while preserving all the other improvements you made (such as ensuring that emitting the warning gets delayed until after the C level stderr is properly initialised)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:16:27 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 13 Sep 2018 14:16:27 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536848187.76.0.956365154283.issue34605@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

No further discussion needed. This issue has been closed and resolved. Thanks Victor for the PRs.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:34:04 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 14:34:04 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1536849244.89.0.956365154283.issue34587@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Same problem here. However, checking the test code, it seems that what's happening is that even though the sending socket has been put into non-blocking mode, self.cli.sendto in the _testCongestion helper method invoked by the ThreadableTest base class [1] has *not* thrown OSError, and hence the finally clause setting the event has *not* been triggered, and hence the test is hanging.

Neither socket.py nor test_socket.py have changed recently though, so it seems to me that this is either a recent Fedora bug (where the socket is blocking when it shouldn't), or else a Fedora change that has uncovered a latent defect in the socket module code.

[1] https://github.com/python/cpython/blob/master/Lib/test/test_socket.py#L228

----------
nosy: +ncoghlan, petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:35:13 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 14:35:13 +0000
Subject: [issue34657] pyconfig.h macro "timezone" name clashes with user
 source are likely
In-Reply-To: <1536819052.42.0.956365154283.issue34657@psf.upfronthosting.co.za>
Message-ID: <1536849313.46.0.956365154283.issue34657@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows -Build
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34657>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:40:35 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 13 Sep 2018 14:40:35 +0000
Subject: [issue34657] pyconfig.h macro "timezone" name clashes with user
 source are likely
In-Reply-To: <1536819052.42.0.956365154283.issue34657@psf.upfronthosting.co.za>
Message-ID: <1536849635.37.0.956365154283.issue34657@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This is a duplicate of bpo-24643.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34657>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:43:28 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 13 Sep 2018 14:43:28 +0000
Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts
 with timeb.h
In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za>
Message-ID: <1536849808.95.0.956365154283.issue24643@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This was just reported again in bpo-34657.  We should go ahead and define _Py_timezone et al., which I will try to do today if nobody beats me to it :)

----------
priority: normal -> high
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24643>
_______________________________________

From report at bugs.python.org  Thu Sep 13 10:56:59 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 14:56:59 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536850619.36.0.956365154283.issue34597@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

While, as Ronald notes, it would be nice to fully support weak linking so that building Python on macOS 10.n with a deployment target for 10.m where m < n so that an application with an embedded or bundled Python can run on 10.m through 10.n systems, in the mean time there is a simple and safe alternative that has been used for years: build the Python on 10.m (or use a ready-built Python built on 10.m or lower).  That's what we do for the macOS Pythons provided by python.org installers, e.g. the installer variants that claim 10.9+ support are actually built on 10.9.  If you need an app bundle with an embedded Python, py2app can greatly simplify the process of constructing one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:00:16 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 15:00:16 +0000
Subject: [issue7713] implement ability to disable automatic search path
 additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1536850816.45.0.956365154283.issue7713@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Closing as the release has reached EOL.

----------
nosy: +willingc
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7713>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:06:59 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 15:06:59 +0000
Subject: [issue34585] Don't use AC_RUN_IFELSE to determine float endian
In-Reply-To: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>
Message-ID: <1536851219.18.0.956365154283.issue34585@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mark.dickinson, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34585>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:09:24 2018
From: report at bugs.python.org (Zorg)
Date: Thu, 13 Sep 2018 15:09:24 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536851364.5.0.956365154283.issue34597@psf.upfronthosting.co.za>


Zorg <zorgiepoo at gmail.com> added the comment:

https://bugs.python.org/issue31359 has a better details about this issue.

I personally believe it's safer to link against a newer SDK and deal with the trouble of finding out what to strip out, which will be opted into implications or code paths that linking a binary against a newer SDK may provide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:10:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 15:10:17 +0000
Subject: [issue34583] os.stat() wrongfully returns False for symlink on
 Windows 10 v1803
In-Reply-To: <1536098954.93.0.56676864532.issue34583@psf.upfronthosting.co.za>
Message-ID: <1536851417.03.0.956365154283.issue34583@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows -Library (Lib)
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34583>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:11:29 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 15:11:29 +0000
Subject: [issue34582] VSTS builds should use new YAML syntax and pools
Message-ID: <1536851489.9.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:14:29 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Sep 2018 15:14:29 +0000
Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts
 with timeb.h
In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za>
Message-ID: <1536851669.22.0.956365154283.issue24643@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I'd still rather put the redefinitions in our files that need it, and leave end users untouched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24643>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:16:20 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 15:16:20 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536851780.17.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +8689

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:18:17 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 15:18:17 +0000
Subject: [issue34578] Pipenv lock : ModuleNotFoundError: No module named
 '_ctypes'
In-Reply-To: <1536072641.34.0.56676864532.issue34578@psf.upfronthosting.co.za>
Message-ID: <1536851897.08.0.956365154283.issue34578@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Since you are using pipenv and it is not part of the Python standard library, you should check the pipenv issue tracker and documentation and, if necessary, ask there:

https://github.com/pypa/pipenv/issues

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34578>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:22:04 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Sep 2018 15:22:04 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536852124.17.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Alternate PR is up at https://github.com/python/cpython/pull/9257

There's one setting that remains in CoreConfig: "warn_on_c_locale", which _Py_UnixMain also uses to decide whether or not to actually emit the passed in locale coercion warning.

The coercion warning information itself moves out of CoreConfig, and into the private _PyMain helper struct.

The signature of _Py_CoerceLegacyLocale changed to both return an integer indicating whether or not coercion took place, as well as supporting two output variables that allow the display of the coercion warning message to be deferred (or skipped entirely).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:27:15 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 15:27:15 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536852435.82.0.956365154283.issue31577@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks, Serihy.  Can we either close this now or remove 3.7 and "release blocker"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:43:43 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Thu, 13 Sep 2018 15:43:43 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1536853423.44.0.956365154283.issue34603@psf.upfronthosting.co.za>


Change by Vladimir Matveev <desco.by at gmail.com>:


----------
keywords: +patch
pull_requests: +8690
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:46:08 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 15:46:08 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536853568.09.0.956365154283.issue34597@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> https://bugs.python.org/issue31359 has a better details about this issue.

Yea, the approach there is again dealing with using a newer SDK to build for an older system.

> I personally believe it's safer to link against a newer SDK and deal with the trouble of finding out what to strip out, which will be opted into implications or code paths that linking a binary against a newer SDK may provide.

Why do you believe that is safer?  Apple goes to great lengths to provide compatibility for existing applications to keep running on newer systems.  That's not to say that eventually certain APIs are deprecated and removed but Python itself makes fairly minimal demands on macOS, i.e. it pretty much does not use anything other than basic libc-style system calls.  The one obvious disadvantage is that Python apps can't take advantage of newly introduced system calls (introduced after 10.m) when running on those newer systems.  I honestly don't recall any case dating back to 10.5 or so where there have been any reported problems with running a 10.m Python on a 10.n system (as best as I can recall!).  On the other hand, trying to support weak linking and backward compatibility requires more code and significant increase in ongoing testing.  It would be a good thing to have but there is a significant cost and added risk to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Thu Sep 13 11:50:58 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 13 Sep 2018 15:50:58 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536853858.77.0.956365154283.issue31577@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

The crash is fixed, so I've lowered the priority.  Serhiy, are you still interested in pursuing an alternative fix in 3.8, or content with what's merged?

----------
priority: release blocker -> normal
resolution:  -> fixed
stage: patch review -> commit review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:08:58 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 13 Sep 2018 16:08:58 +0000
Subject: [issue34653] PyParser_SimpleParseStringFilename should be deleted
In-Reply-To: <1536789485.93.0.956365154283.issue34653@psf.upfronthosting.co.za>
Message-ID: <1536854938.11.0.956365154283.issue34653@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +8691
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34653>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:15:57 2018
From: report at bugs.python.org (25.45)
Date: Thu, 13 Sep 2018 16:15:57 +0000
Subject: [issue34660] Remove ableist terms and pejoratives from source code
 and docs
Message-ID: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>


New submission from 25.45 <resister at mailinator.com>:

It has come to my attention that CPython's source code contains problematic ableist/saneist terms and/or pejoratives, namely

sanity check    144
silly           26
insane          13
crazy           13
stupid          6
lame            2
lunatic         1

Some of those slipped into the documentation. In an attempt to make Python community more inclusive and welcoming, we should clean up these usages and replace them with something neutral (where applicable). Unfortunately, to this day many developers deem such efforts as "trolling", so please note that the precedent has already been set by many major projects. Here're just a few:

https://github.com/unpkg/unpkg.com/pull/81
https://github.com/reduxjs/redux/pull/2335
https://github.com/rtfd/readthedocs.org/pull/3752
https://github.com/krzysztofzablocki/Sourcery/issues/2
https://github.com/google/xi-editor/pull/126

Other resources:

https://english.stackexchange.com/q/282282
http://isthisableism.tumblr.com/sluralternatives

The goal of this issue is not to stir up arguments, but to figure out the alternatives and ways to replace those problematic terms.

----------
messages: 325260
nosy: 25.45
priority: normal
severity: normal
status: open
title: Remove ableist terms and pejoratives from source code and docs
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:22:20 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Sep 2018 16:22:20 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1536855740.59.0.956365154283.issue34659@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:35:01 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 16:35:01 +0000
Subject: [issue34653] PyParser_SimpleParseStringFilename should be deleted
In-Reply-To: <1536789485.93.0.956365154283.issue34653@psf.upfronthosting.co.za>
Message-ID: <1536856501.65.0.956365154283.issue34653@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 53c427e839d3e55d4791dca687a2d47534465a7a by Miss Islington (bot) (Eric V. Smith) in branch 'master':
bpo-34653: Removed unused function PyParser_SimpleParseStringFilename. (GH-9260)
https://github.com/python/cpython/commit/53c427e839d3e55d4791dca687a2d47534465a7a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34653>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:39:29 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 13 Sep 2018 16:39:29 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1536856769.13.0.956365154283.issue34480@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:48:00 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 16:48:00 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536857280.52.0.956365154283.issue1621@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8692

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:48:01 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 16:48:01 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536857281.02.0.956365154283.issue1621@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8692, 8693

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:52:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 16:52:18 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
Message-ID: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

BusyBox has a unzip command, but it doesn't support -t.

======================================================================
FAIL: test_unzip_zipfile (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_shutil.py", line 1181, in test_unzip_zipfile
    subprocess.check_output(zip_cmd, stderr=subprocess.STDOUT)
subprocess.CalledProcessError: Command '['unzip', '-t', '/tmp/tmp92zs6lmt/archive.zip']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_shutil.py", line 1185, in test_unzip_zipfile
    self.fail(msg.format(exc, details))
AssertionError: Command '['unzip', '-t', '/tmp/tmp92zs6lmt/archive.zip']' returned non-zero exit status 1.
**Unzip Output**
unzip: unrecognized option: t
BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary.
Usage: unzip [-lnopq] FILE[.zip] [FILE]... [-x FILE...] [-d DIR]
Extract FILEs from ZIP archive
	-l	List contents (with -q for short form)
	-n	Never overwrite files (default: ask)
	-o	Overwrite
	-p	Print to stdout
	-q	Quiet
	-x FILE	Exclude FILEs
	-d DIR	Extract into DIR

----------
components: Tests
messages: 325262
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_shutil fails with busybox unzip
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:53:55 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 16:53:55 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536857635.86.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8694
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 12:59:34 2018
From: report at bugs.python.org (Farhaan Bukhsh)
Date: Thu, 13 Sep 2018 16:59:34 +0000
Subject: [issue29341] Missing accepting path-like object in docstrings of os
 module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1536857974.07.0.956365154283.issue29341@psf.upfronthosting.co.za>


Farhaan Bukhsh <farhaan.bukhsh at gmail.com> added the comment:

Hey I would like to make this change which file should I look into?

----------
nosy: +fhackdroid

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29341>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:08:49 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 17:08:49 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536858529.47.0.956365154283.issue34661@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a710ebd21b09efe902dde84d4862ce5c6427f7af by Benjamin Peterson in branch 'master':
closes bpo-34661: Fix test_shutil if unzip doesn't support -t. (GH-9262)
https://github.com/python/cpython/commit/a710ebd21b09efe902dde84d4862ce5c6427f7af


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:09:03 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:09:03 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536858543.7.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:09:16 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:09:16 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536858556.38.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8696

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:11:03 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:11:03 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536858663.66.0.956365154283.issue34658@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b2ff9a9f9298761985aa85aa3f42421ce6effb9e by Miss Islington (bot) in branch '3.7':
bpo-34658: Fix rare subprocess prexec_fn fork error. (GH-9255)
https://github.com/python/cpython/commit/b2ff9a9f9298761985aa85aa3f42421ce6effb9e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:19:07 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 13 Sep 2018 17:19:07 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1536859147.75.0.956365154283.issue17239@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8697

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:20:55 2018
From: report at bugs.python.org (Daniel Pope)
Date: Thu, 13 Sep 2018 17:20:55 +0000
Subject: [issue34662] tarfile.TarFile may write corrupt files if not closed
Message-ID: <1536859255.56.0.956365154283.issue34662@psf.upfronthosting.co.za>


New submission from Daniel Pope <lord.mauve at gmail.com>:

A tarfile.TarFile object open for writing may silently write corrupt tar files if it is destroyed before being closed.

While explicitly calling close() or using the object as a context manager is recommended, I would not expect this in basic usage.

There are two steps needed for a TarFile to be closed properly:

* According to https://github.com/python/cpython/blob/3.7/Lib/tarfile.py#L1726, two zero blocks must be written (though GNU tar seems to work even if these are absent)
* The underlying fileobj (an io.BufferedWriter) must then be flushed

A BufferedWriter is flushed in its __del__(); the problem is that TarFile objects form a reference cycle with their TarInfo members due to this line, which has the comment "Not Needed": https://github.com/python/cpython/blob/3.7/Lib/tarfile.py#L1801

Under PEP-442, when the TarFile becomes unreferenced the following Cycle Isolate is formed:

    TarInfo <=> TarFile -> BufferedWriter -> FileIO

Finalisers for these objects are run in an undefined order. If the FileIO finaliser is run before the BufferedWriter finaliser, then the fd is closed, buffered data in the BufferedWriter is not committed to disk, and the tar file is corrupt.

Additionally, while ResourceWarning is issued if the BufferedWriter or FileIO are left unclosed, no such warning is emitted by the TarFile.

----------
components: Library (Lib)
messages: 325266
nosy: lordmauve
priority: normal
severity: normal
status: open
title: tarfile.TarFile may write corrupt files if not closed
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34662>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:25:11 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 17:25:11 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536859511.92.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8698

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:27:55 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:27:55 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536859675.7.0.956365154283.issue34661@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1550b7311216082748ddcdc048ee0374ce004513 by Miss Islington (bot) in branch '3.7':
closes bpo-34661: Fix test_shutil if unzip doesn't support -t. (GH-9262)
https://github.com/python/cpython/commit/1550b7311216082748ddcdc048ee0374ce004513


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:32:48 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:32:48 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536859968.11.0.956365154283.issue34661@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7eeb80b1e0034fd4e6b8d03b2c0fc5c94fe8d8fa by Miss Islington (bot) in branch '3.6':
closes bpo-34661: Fix test_shutil if unzip doesn't support -t. (GH-9262)
https://github.com/python/cpython/commit/7eeb80b1e0034fd4e6b8d03b2c0fc5c94fe8d8fa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:39:44 2018
From: report at bugs.python.org (Daniel Pope)
Date: Thu, 13 Sep 2018 17:39:44 +0000
Subject: [issue34662] tarfile.TarFile may write corrupt files if not closed
In-Reply-To: <1536859255.56.0.956365154283.issue34662@psf.upfronthosting.co.za>
Message-ID: <1536860384.97.0.956365154283.issue34662@psf.upfronthosting.co.za>


Daniel Pope <lord.mauve at gmail.com> added the comment:

I have several suggestions for steps to address this:

1. Don't create reference cycles. TarInfo.tarfile does not appear to be a documented attribute (https://docs.python.org/3/library/tarfile.html#tarinfo-objects) and could perhaps be deleted.
2. Issue a ResourceWarning in TarFile.__del__() if the TarFile was not closed prior to finalisation. ResourceWarnings are ignored by default but this would help when debugging. Given that the file may be corrupted perhaps something more visible than a ResourceWarning is required.
3. Make TarFile.__del__() close the TarFile cleanly. This is only possible if we can guarantee the underlying fileobj is finalized later (eg. because we have eliminated the reference cycle).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34662>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:47:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 17:47:27 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536860847.29.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8699

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:57:12 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 13 Sep 2018 17:57:12 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1536861432.78.0.956365154283.issue20047@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8700

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:57:26 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 17:57:26 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536861446.8.0.956365154283.issue34661@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset e78734d579439861f6d7e12f35d268836b2c1e24 by Benjamin Peterson in branch 'master':
bpo-34661: Fix test skipping call. (GH-9266)
https://github.com/python/cpython/commit/e78734d579439861f6d7e12f35d268836b2c1e24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:57:35 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:57:35 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536861455.68.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8701

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 13:57:43 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 17:57:43 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536861463.4.0.956365154283.issue34661@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8702

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:08:51 2018
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 13 Sep 2018 18:08:51 +0000
Subject: [issue33239] tempfile module: functions with the 'buffering' option
 are incorrectly documented
In-Reply-To: <1523128962.9.0.682650639539.issue33239@psf.upfronthosting.co.za>
Message-ID: <1536862131.33.0.956365154283.issue33239@psf.upfronthosting.co.za>


Antti Haapala <antti at haapala.name> added the comment:

This week we were bit by this in production. I foolishly thought that the  docs would give me correct default values... It is worse that it didn't actually occur until we went over the limit.

----------
nosy: +ztane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33239>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:11:38 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 13 Sep 2018 18:11:38 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
Message-ID: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

In some systems, posix_spawn has an optional flag (POSIX_SPAWN_USEVFORK) that is GNU specific and allows the user to force posix_spawn to spawn the child using vfork instead of fork. This is very beneficial as it gives great speedups compare with normal fork+execv.

----------
components: Extension Modules
messages: 325272
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Support POSIX_SPAWN_USEVFORK flag in posix_spawn
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:15:45 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 13 Sep 2018 18:15:45 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1536862545.97.0.956365154283.issue34663@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8703
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:17:57 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 18:17:57 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536862677.6.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8704

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:22:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 18:22:08 +0000
Subject: [issue34664] test.test_os.MakedirTests.test_mode is too strict
Message-ID: <1536862928.9.0.956365154283.issue34664@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

If TESTFN is in a directory with S_ISGID set in its mode, test_os will fail:

======================================================================
FAIL: test_mode (test.test_os.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_os.py", line 1134, in test_mode
    self.assertEqual(stat.S_IMODE(os.stat(path).st_mode), 0o555)
AssertionError: 1389 != 365

The problem is we're checking the entire file mode when we should just be checking the permission bits.

----------
components: Tests
messages: 325273
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test.test_os.MakedirTests.test_mode is too strict
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34664>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:23:58 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 18:23:58 +0000
Subject: [issue34664] test.test_os.MakedirTests.test_mode is too strict
In-Reply-To: <1536862928.9.0.956365154283.issue34664@psf.upfronthosting.co.za>
Message-ID: <1536863038.3.0.956365154283.issue34664@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8705
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34664>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:24:10 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 18:24:10 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536863050.76.0.956365154283.issue34661@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 18e21883a4ec2a36a02054eb2ff47e3ba9bd1d33 by Benjamin Peterson in branch '2.7':
[2.7] closes bpo-34661: Fix test_shutil if unzip doesn't support -t. (GH-9267)
https://github.com/python/cpython/commit/18e21883a4ec2a36a02054eb2ff47e3ba9bd1d33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:25:52 2018
From: report at bugs.python.org (Johannes M.)
Date: Thu, 13 Sep 2018 18:25:52 +0000
Subject: [issue34665] Py_FinalizeEx() - Bugs & caveats - Add info that NumPy
 and Pandas don't support reinitialization
Message-ID: <1536863152.32.0.956365154283.issue34665@psf.upfronthosting.co.za>


New submission from Johannes M. <jcmueller at posteo.de>:

Since about a decade, it's a know problem that NumPy and Pandas initialization function crashes on reinitialization after a call to Py_Finalize() + Py_Initialize().

[https://github.com/numpy/numpy/issues/8097]
[https://github.com/numpy/numpy/issues/11925]

It seems to be unlikely that this problem gets fixed soon. Due to the popularity of the modules, it would be good to add this information to the documentation of Py_FinalizeEx(), such that developers, who are planning to embed Python get this information already at the moment when they read the documentation.

I would suggest to change the following sentence:

    Some extensions may not work properly if their
    initialization routine is called more than once;

to

    Some extensions, like NumPy and Pandas, may not work properly if their
    initialization routine is called more than once;

----------
assignee: docs at python
components: Documentation
messages: 325275
nosy: docs at python, jcmuel
priority: normal
severity: normal
status: open
title: Py_FinalizeEx() - Bugs & caveats - Add info that NumPy and Pandas don't support reinitialization
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34665>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:27:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 18:27:12 +0000
Subject: [issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option
In-Reply-To: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>
Message-ID: <1536863232.53.0.956365154283.issue34639@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Respecting -E and -I isn't a problem per se - the problem is moving the _Py_CoerceLegacyLocale call to a point that's incredibly late in the startup process *just* to get it to respect those flags.

Would you mind to elaborate how it is an issue? The LC_CTYPE is coerced *before* the configuration is read a second time. If there is an issue, would you mind to show an example where something is decoded from the wrong encoding?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34639>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:35:25 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 18:35:25 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536863725.73.0.956365154283.issue34661@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 218b4bf47410ff8ab46b68461267fe10db18aee1 by Miss Islington (bot) in branch '3.7':
bpo-34661: Fix test skipping call. (GH-9266)
https://github.com/python/cpython/commit/218b4bf47410ff8ab46b68461267fe10db18aee1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:43:19 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 18:43:19 +0000
Subject: [issue34286] lib2to3 tests fail on the 3.7 branch (used to work with
 3.7.0)
In-Reply-To: <1533007091.73.0.56676864532.issue34286@psf.upfronthosting.co.za>
Message-ID: <1536864199.97.0.956365154283.issue34286@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I can't reproduce this either using a current top of 3.7 branch and installed on macOS; I also tried building 3.7 just prior to the fix for Issue21446 that Brett mentioned; the test also did not fail.  Let's close this until it can be reproduced outside of doko's environment.

----------
nosy: +ned.deily
resolution:  -> works for me
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34286>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:44:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 18:44:33 +0000
Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts
 with timeb.h
In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za>
Message-ID: <1536864273.34.0.956365154283.issue24643@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24643>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:46:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 13 Sep 2018 18:46:09 +0000
Subject: [issue34666] Implement async write and async close in asyncio
 StreamWriter
Message-ID: <1536864369.03.0.956365154283.issue34666@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Methods are needed for providing consistent stream API with control flow switched on by default.

----------
components: asyncio
messages: 325279
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement async write and async close in asyncio StreamWriter
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34666>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:47:50 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 18:47:50 +0000
Subject: [issue34661] test_shutil fails with busybox unzip
In-Reply-To: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>
Message-ID: <1536864470.9.0.956365154283.issue34661@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 81361cdff847f14f6258c0ead17817d6f9e04022 by Miss Islington (bot) in branch '3.6':
bpo-34661: Fix test skipping call. (GH-9266)
https://github.com/python/cpython/commit/81361cdff847f14f6258c0ead17817d6f9e04022


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34661>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:47:52 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 13 Sep 2018 18:47:52 +0000
Subject: [issue34666] Implement async write and async close in asyncio
 StreamWriter
In-Reply-To: <1536864369.03.0.956365154283.issue34666@psf.upfronthosting.co.za>
Message-ID: <1536864472.38.0.956365154283.issue34666@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +8706
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34666>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:49:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 18:49:50 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536864590.79.0.956365154283.issue34247@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 66755cbb1e529f54c9066639ebbbac81add0affd by Ned Deily in branch 'master':
bpo-34247: add porting note to 3.7 What's New (GH-9223)
https://github.com/python/cpython/commit/66755cbb1e529f54c9066639ebbbac81add0affd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:50:01 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 18:50:01 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536864601.12.0.956365154283.issue34247@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8707

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:50:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 18:50:29 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1536864629.69.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -E ...

The UTF-8 Mode has the same behavior: PYTHONUTF8 env var is ignored when using -E, but enabled by the C locale: you can use -X utf8=0 in that case to ensure that the UTF-8 Mode is disabled.

I wanted to propose you to add a new -X option, ex: -X coerce_c_locale=0, which would have the priority over the environment variable. I'm not a big fan of env vars, it's not always convenient to use them. I prefer an env var, but both are even better :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:51:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 18:51:52 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536864712.77.0.956365154283.issue34247@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> (in earlier Python versions, it respected an ill-defined subset of those environment variables, ...)

I'm not aware of the Python 3.6 issue ("ill-defined"): which env vars were not properly handled?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:54:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 18:54:21 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1536864861.6.0.956365154283.issue1621@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Benjamin: what do you think of adding an explicit check after the "new_size <<= 1;" loop?

    if (new_size > (size_t)PY_SSIZE_T_MAX) {
        PyErr_NoMemory();
        return -1;
    }

Technically, PyMem_Malloc() already implements the check, so it's not really needed. So I'm not sure if it's needed :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Thu Sep 13 14:59:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 18:59:47 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1536865187.33.0.956365154283.issue34587@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8708
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:00:19 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 19:00:19 +0000
Subject: [issue34664] test.test_os.MakedirTests.test_mode is too strict
In-Reply-To: <1536862928.9.0.956365154283.issue34664@psf.upfronthosting.co.za>
Message-ID: <1536865219.25.0.956365154283.issue34664@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 84db4a9978069a98978e9cd7951d1a01d47e5286 by Benjamin Peterson in branch 'master':
closes bpo-34664: Only check file permission bits of newly created directories. (GH-9273)
https://github.com/python/cpython/commit/84db4a9978069a98978e9cd7951d1a01d47e5286


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34664>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:00:25 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 19:00:25 +0000
Subject: [issue34664] test.test_os.MakedirTests.test_mode is too strict
In-Reply-To: <1536862928.9.0.956365154283.issue34664@psf.upfronthosting.co.za>
Message-ID: <1536865225.63.0.956365154283.issue34664@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8709

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34664>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:00:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 19:00:35 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1536865235.94.0.956365154283.issue34587@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I proposed PR 9277 to remove the test: see the PR for the rationale.

> Neither socket.py nor test_socket.py have changed recently though, so it seems to me that this is either a recent Fedora bug (where the socket is blocking when it shouldn't), or else a Fedora change that has uncovered a latent defect in the socket module code.

IMHO it's a change in the implementation of the RDS protocol in Linux, likely in the kernel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:09:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 19:09:11 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1536865751.11.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I suggest to name the parameter "use_vfork", or maybe even "vfork".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:14:49 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 19:14:49 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536866089.46.0.956365154283.issue34247@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 305056494d7e1debec3df268b8925725b0110293 by Miss Islington (bot) in branch '3.7':
bpo-34247: add porting note to 3.7 What's New (GH-9223)
https://github.com/python/cpython/commit/305056494d7e1debec3df268b8925725b0110293


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:19:33 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 19:19:33 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1536866373.19.0.956365154283.issue34247@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I've merged Nick's suggested porting note so I'm going to remove the "release blocker" status.  Can we also close this now?

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:21:43 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 13 Sep 2018 19:21:43 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1536866503.58.0.956365154283.issue34651@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +8710
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Thu Sep 13 15:42:31 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 19:42:31 +0000
Subject: [issue34664] test.test_os.MakedirTests.test_mode is too strict
In-Reply-To: <1536862928.9.0.956365154283.issue34664@psf.upfronthosting.co.za>
Message-ID: <1536867751.98.0.956365154283.issue34664@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b2a6aa32f34b6d77c15f175a9df7271a05519bf9 by Miss Islington (bot) in branch '3.7':
closes bpo-34664: Only check file permission bits of newly created directories. (GH-9273)
https://github.com/python/cpython/commit/b2a6aa32f34b6d77c15f175a9df7271a05519bf9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34664>
_______________________________________

From report at bugs.python.org  Thu Sep 13 16:26:32 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 20:26:32 +0000
Subject: [issue34660] Remove ableist terms and pejoratives from source code
 and docs
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1536870392.78.0.956365154283.issue34660@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Thank you for filing an issue. I will be carefully reviewing the Python documentation section by section over the next several months. I will open individual issues as I go through each section as well as pull requests as I thoughtfully review each section.

I'm closing this issue but will be opening individual issues by documentation section as time permits my review.

----------
assignee:  -> willingc
components: +Documentation
nosy: +willingc
resolution:  -> remind
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Thu Sep 13 16:31:15 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 20:31:15 +0000
Subject: [issue34667] Review documentation section by section
Message-ID: <1536870675.97.0.956365154283.issue34667@psf.upfronthosting.co.za>


New submission from Carol Willing <willingc at gmail.com>:

This issue is a placeholder for a comprehensive documentation review by content sections. I will develop a more detailed workplan in the coming weeks.

----------
assignee: willingc
messages: 325292
nosy: willingc
priority: normal
severity: normal
status: open
title: Review documentation section by section
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34667>
_______________________________________

From report at bugs.python.org  Thu Sep 13 16:31:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 20:31:38 +0000
Subject: [issue34668] test_resource fails if test has CAP_SYS_RESOURCE but
 isn't root
Message-ID: <1536870698.96.0.956365154283.issue34668@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

test_prlimit tries to test that raising the hardlimit of an unprivileged process. It tries to raise the hardlimit of pid 1, which usually raises a PermissionError. However, if the tests are privileged, this test can't work. The test tries to avoid this by only running the test if os.geteuid() != 0. However, there are other cases. For example, if the test process isn't root but has CAP_SYS_RESOURCE. While we could check for these other cases, I think we should just delete this test. There's no special logic in the prlimit implementation for handling permission errors, so it's not adding much value.

======================================================================
FAIL: test_prlimit (test.test_resource.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/support/__init__.py", line 587, in wrapper
    return func(*args, **kw)
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_resource.py", line 152, in test_prlimit
    1, resource.RLIMIT_AS)
AssertionError: PermissionError not raised by prlimit

----------
components: Tests
messages: 325293
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_resource fails if test has CAP_SYS_RESOURCE but isn't root
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34668>
_______________________________________

From report at bugs.python.org  Thu Sep 13 16:33:03 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 20:33:03 +0000
Subject: [issue34668] test_resource fails if test has CAP_SYS_RESOURCE but
 isn't root
In-Reply-To: <1536870698.96.0.956365154283.issue34668@psf.upfronthosting.co.za>
Message-ID: <1536870783.56.0.956365154283.issue34668@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8711
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34668>
_______________________________________

From report at bugs.python.org  Thu Sep 13 16:37:13 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Sep 2018 20:37:13 +0000
Subject: [issue34582] VSTS builds should use new YAML syntax and pools
Message-ID: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

Thanks, David!

I'm partway through most of these changes (as well as some other improvements) in my PR at https://github.com/python/cpython/pull/9210/files, so if it's all the same to you, I'll make sure I've covered everything you've done here and then close yours. Sound good?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Thu Sep 13 16:38:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Sep 2018 20:38:19 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1536871099.3.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

We discussed with Gregory P. Smith, and we agreed on the "use_vfork=True" name. He is a native english speaker, so I rely on him :-) Moreover, "use_vfork" is closer to POSIX_SPAWN_USEVFORK constant than "vfork".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:15:29 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 13 Sep 2018 21:15:29 +0000
Subject: [issue34668] test_resource fails if test has CAP_SYS_RESOURCE but
 isn't root
In-Reply-To: <1536870698.96.0.956365154283.issue34668@psf.upfronthosting.co.za>
Message-ID: <1536873329.0.0.956365154283.issue34668@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Check also discussion on issue31132.
If you agree, I'm OK with marking that one as duplicate, and removing the test.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34668>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:17:02 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 13 Sep 2018 21:17:02 +0000
Subject: [issue34668] test_resource fails if test has CAP_SYS_RESOURCE but
 isn't root
In-Reply-To: <1536870698.96.0.956365154283.issue34668@psf.upfronthosting.co.za>
Message-ID: <1536873422.27.0.956365154283.issue34668@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> test_prlimit from test_resource fails when building python3 inside systemd-nspawn environment

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34668>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:17:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 21:17:08 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536873428.29.0.956365154283.issue31132@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8712
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:47:05 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 21:47:05 +0000
Subject: [issue34662] tarfile.TarFile may write corrupt files if not closed
In-Reply-To: <1536859255.56.0.956365154283.issue34662@psf.upfronthosting.co.za>
Message-ID: <1536875225.43.0.956365154283.issue34662@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34662>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:53:13 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 21:53:13 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536875593.19.0.956365154283.issue31132@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 01e0afa994c2e840f85e2de103e72a2c0ddf1b1f by Miss Islington (bot) (Benjamin Peterson) in branch 'master':
bpo-31132: Remove prlimit permission test. (GH-9280)
https://github.com/python/cpython/commit/01e0afa994c2e840f85e2de103e72a2c0ddf1b1f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:53:21 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 21:53:21 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536875601.1.0.956365154283.issue31132@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8713

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 17:53:28 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 21:53:28 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536875608.86.0.956365154283.issue31132@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8714

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 18:00:53 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Sep 2018 22:00:53 +0000
Subject: [issue34660] Remove ableist terms and pejoratives from source code
 and docs
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1536876053.29.0.956365154283.issue34660@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Thu Sep 13 18:04:04 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 13 Sep 2018 22:04:04 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
In-Reply-To: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>
Message-ID: <1536876244.62.0.956365154283.issue34635@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

What's the use case for these?

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Thu Sep 13 18:13:59 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 22:13:59 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536876839.03.0.956365154283.issue31132@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b162941c0793e0dd5533ee3090901cba9d8cf7d by Miss Islington (bot) in branch '3.7':
bpo-31132: Remove prlimit permission test. (GH-9280)
https://github.com/python/cpython/commit/2b162941c0793e0dd5533ee3090901cba9d8cf7d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 18:19:22 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 13 Sep 2018 22:19:22 +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: <1536877162.78.0.956365154283.issue32933@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Ned, as release manager of 3.6 and 3.7, what do you think about backporting this to maintenance releases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Thu Sep 13 18:22:19 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Sep 2018 22:22:19 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536877339.94.0.956365154283.issue31132@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f79d74d5a3ceb06b63996e8ecf23e419e16e4be2 by Miss Islington (bot) in branch '3.6':
bpo-31132: Remove prlimit permission test. (GH-9280)
https://github.com/python/cpython/commit/f79d74d5a3ceb06b63996e8ecf23e419e16e4be2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:05:46 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 23:05:46 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1536879946.86.0.956365154283.issue34651@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

+1 agreed.  this is the simplest approach to start with.

Code to restrict: os.fork itself and disallowing the use of preexec_fn on subprocess within subinterpreters.

feel free to ignore preexec_fn in subprocess for the time being if desired, we already promise people that it is a bad idea legacy API that we don't want, guaranteed to cause undiagnosable problems and deadlocks at times. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:07:39 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Sep 2018 23:07:39 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1536880059.57.0.956365154283.issue34659@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm open to adding the feature as a keyword-only argument.

Lisa, would you like to bring this to fruition?

----------
assignee: rhettinger -> lisroach
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:11:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 23:11:27 +0000
Subject: [issue34669] test_ssl fails if SSLv2 is enabled
Message-ID: <1536880287.69.0.956365154283.issue34669@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

I modified multissltests.py to enable-ssl2:

--- a/Tools/ssl/multissltests.py
+++ b/Tools/ssl/multissltests.py
@@ -275,7 +275,8 @@ class AbstractBuilder(object):
         cmd = [
             "./config",
             "shared", "--debug",
-            "--prefix={}".format(self.install_dir)
+            "--prefix={}".format(self.install_dir),
+            "enable-ssl2",
         ]
         env = os.environ.copy()

This results in some test_ssl failures, which all seem to have the same root cause:

$ Tools/ssl/multissltests.py  --openssl 1.0.2o
....
======================================================================
ERROR: test_constructor (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 965, in test_constructor
    ssl.SSLContext(protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 973, in test_protocol
    ctx = ssl.SSLContext(proto)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_session_stats (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 1320, in test_session_stats
    ctx = ssl.SSLContext(proto)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_echo (test.test_ssl.ThreadedTests) (protocol='PROTOCOL_SSLv2')
Basic test of an SSL client connecting to a server
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2569, in test_echo
    context = ssl.SSLContext(protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2960, in test_protocol_sslv2
    try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3026, in test_protocol_sslv3
    try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3043, in test_protocol_tlsv1
    try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3058, in test_protocol_tlsv1_1
    try_protocol_combo(ssl.PROTOCOL_TLSv1_1, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_tlsv1_2 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.2 server with various client options.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3079, in test_protocol_tlsv1_2
    try_protocol_combo(ssl.PROTOCOL_TLSv1_2, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

----------------------------------------------------------------------

----------
assignee: christian.heimes
components: SSL
messages: 325304
nosy: benjamin.peterson, christian.heimes
priority: normal
severity: normal
status: open
title: test_ssl fails if SSLv2 is enabled
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34669>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:13:19 2018
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 13 Sep 2018 23:13:19 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1536880399.29.0.956365154283.issue34659@psf.upfronthosting.co.za>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

Happy to! I'll try to make a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:16:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 13 Sep 2018 23:16:44 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1536880604.3.0.956365154283.issue20047@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 0b9fe1734168d45861d6dc3022492387dec5a4a2 by Berker Peksag (Zackery Spytz) in branch '2.7':
[2.7] bpo-20047: Remove Objects/bytesobject.c from 2.7 (GH-9268)
https://github.com/python/cpython/commit/0b9fe1734168d45861d6dc3022492387dec5a4a2


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:27:31 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 13 Sep 2018 23:27:31 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536881251.45.0.956365154283.issue26979@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Thanks! I think that explains enough of the issue.

Converting static types to heap ones is just one way you can use PyType_Spec. Another is writing new types, which should work much like Python classes.

So I don't think we should change the default, but rather document the use case. I'd rather update the docs after GH-9154 is merged, so this is blocked now.
 
I'll also try making an explicit `{Py_tp_dealloc, NULL}` override the inherited value, as per Serhiy's suggestion. But it'll only go to 3.8, so it won't help PySide now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:37:06 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 13 Sep 2018 23:37:06 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1536881826.59.0.956365154283.issue34490@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:39:12 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 23:39:12 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536881952.76.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8715

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:39:23 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 23:39:23 +0000
Subject: [issue31132] test_prlimit from test_resource fails when building
 python3 inside systemd-nspawn environment
In-Reply-To: <1502124202.05.0.637493609291.issue31132@psf.upfronthosting.co.za>
Message-ID: <1536881963.71.0.956365154283.issue31132@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31132>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:41:56 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 13 Sep 2018 23:41:56 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1536882116.84.0.956365154283.issue34490@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +8716

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:44:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 13 Sep 2018 23:44:47 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536882287.81.0.956365154283.issue34596@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

It would be nice to make *reason* optional. Every time I needed to use @unittest.skip() (even if I wanted to use it temporarily), I ended up passing some random string as reason or use 'raise SkipTest' directly.

If we decide to keep *reason* required, I agree with Serhiy's proposal.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34596>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:47:52 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Sep 2018 23:47:52 +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: <1536882472.29.0.956365154283.issue32933@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

While I think arguments could be made either way, this seems to me to be somewhat more of a bugfix (rather than a feature) in the sense that mock_open did not correctly emulate a real textfile open at least for an idiom that is commonly used (while acknowledging that mock_open does not claim to fully implement open or all classes of IO objects).  The key question to me is would backporting this change likely cause any change in behavior to existing programs running on 3.7.x or 3.6.x.  If yes, then we definitely shouldn't backport it.  If not, then there is now the issue that people using mock_open on 3.7.x (or possibly 3.6.x) still can't depend on its behavior unless they explicitly check for, say, 3.7.1 or 3.6.7.  That's not particularly user friendly, either.  So perhaps it *is* best to not backport; if the functionality is needed in earlier releases, one could create a PyPI package to provide it, for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Thu Sep 13 19:53:54 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 13 Sep 2018 23:53:54 +0000
Subject: [issue34666] Implement async write and async close in asyncio
 StreamWriter
In-Reply-To: <1536864369.03.0.956365154283.issue34666@psf.upfronthosting.co.za>
Message-ID: <1536882834.51.0.956365154283.issue34666@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 11194c877c902a6c3b769d85be887c2272e0a541 by Andrew Svetlov in branch 'master':
bpo-34666: Implement stream.awrite() and stream.aclose() (GH-9274)
https://github.com/python/cpython/commit/11194c877c902a6c3b769d85be887c2272e0a541


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34666>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:00:55 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 14 Sep 2018 00:00:55 +0000
Subject: [issue34669] test_ssl fails if SSLv2 is enabled
In-Reply-To: <1536880287.69.0.956365154283.issue34669@psf.upfronthosting.co.za>
Message-ID: <1536883255.3.0.956365154283.issue34669@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Benjamin and I discussed the issue face to face. Rather than fixing the tests, I'm going to remove support and tests for SSL 2.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34669>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:03:40 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 14 Sep 2018 00:03:40 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1536883420.83.0.956365154283.issue34490@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset d0491cd7fd8a22093ab1ae54eee51fb0e7805c0d by Andrew Svetlov in branch '3.7':
[3.7] bpo-34490: Fix test_asyncio for AIX - do not call transport.get_extra_info('sockname') (GH-8907) (#9286)
https://github.com/python/cpython/commit/d0491cd7fd8a22093ab1ae54eee51fb0e7805c0d


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:04:21 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 14 Sep 2018 00:04:21 +0000
Subject: [issue34666] Implement async write and async close in asyncio
 StreamWriter
In-Reply-To: <1536864369.03.0.956365154283.issue34666@psf.upfronthosting.co.za>
Message-ID: <1536883461.38.0.956365154283.issue34666@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34666>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:06:16 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 00:06:16 +0000
Subject: [issue34660] Remove ableist terms and pejoratives from source code
 and docs
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1536883576.31.0.956365154283.issue34660@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +8717

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:14:28 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 14 Sep 2018 00:14:28 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1536884068.66.0.956365154283.issue34648@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> 1) I know it has the name "format_list", but is it really intended to require a
> list? Why not a sequence, or a collection, or an iterable? I would think it would
> be fine to pass an iterable to traceback.format_list. Is it fine?

In 3.4, format_list() was documented to accept return values of extract_tb() and extract_stack() functions and they both were returned lists:

    def extract_tb(tb, limit=None):
        return list(_extract_tb_iter(tb, limit=limit))

    def extract_stack(f=None, limit=None):
        stack = list(_extract_stack_iter(_get_stack(f), limit=limit))
        stack.reverse()
        return stack

I don't think we support the "pass manually created iterables" case here.

> 2) What is the desired component type for the aggregate passed to
> format_list? In 3.4-and-earlier it was Tuple[str, int, str,
> Optional[str]], and that still works in 3.5-through-3.8, but is that
> just backwards compatibility [...]

Yes, the old API is still supported for backwards compatibility reasons.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:16:09 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 14 Sep 2018 00:16:09 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
Message-ID: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

TLS 1.3 removed renegotiation in favor of rekeying and post handshake authentication (PHA). With PHA, a server can request a client certificate from a client at some point after the handshake. The feature is commonly used by HTTP server for conditional and path specific TLS client auth. For example a server can decide to require a cert based on HTTP method and/or path. A client must announce support for PHA during the handshake

Apache mod_ssl uses PHA, https://github.com/apache/httpd/blob/trunk/modules/ssl/ssl_engine_kernel.c#L1207

As of OpenSSL ticket https://github.com/openssl/openssl/issues/6933, TLS 1.3 clients no longer send the PHA TLS extension by default. Nikos and I requested the change, because PHA breaks some assumptions of TLS 1.2 clients. For on-demand auth, PHA extension must be enabled with SSL_CTX_set_post_handshake_auth(), https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_post_handshake_auth.html .

I propose to add a property on SSLContext to enable PHA and backport the change to Python 2.7, 3.6 and 3.7.

In order to test the feature, I'd also have to add some flags and a function for the server side: (SSL_VERIFY_CLIENT_ONCE, SSL_VERIFY_POST_HANDSHAKE, SSL_verify_client_post_handshake()).

----------
assignee: christian.heimes
components: SSL
messages: 325314
nosy: benjamin.peterson, christian.heimes, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Add set_post_handshake_auth for TLS 1.3
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/issue34670>
_______________________________________

From report at bugs.python.org  Thu Sep 13 20:55:24 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 00:55:24 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1536886524.07.0.956365154283.issue34656@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8718
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 13 21:00:22 2018
From: report at bugs.python.org (Sebastian Bassi)
Date: Fri, 14 Sep 2018 01:00:22 +0000
Subject: [issue34671] Remove references to Benevolent Dictator
Message-ID: <1536886822.26.0.956365154283.issue34671@psf.upfronthosting.co.za>


New submission from Sebastian Bassi <sbassi at users.sourceforge.net>:

Following the trend initiated at https://bugs.python.org/issue34605, I want to point out that the term dictator has a negative connotation in Argentina and other countries where we suffered bloody dictatorship (30000 dead and missing persons, or "desaparecidos" as we call it).
I understand that the former title BDFL may be funny for most developers, but the term "benevolent dictatorship" (or it Spanish equivalent "dictablanda") was used in Chile by the Pinochet's regime.
This title doesn't reflect the democratic nature of the whole project.
My suggestion is to take this into account when defining PEP-8010 and related documentation.

----------
assignee: docs at python
components: Documentation
messages: 325315
nosy: docs at python, sbassi
priority: normal
severity: normal
status: open
title: Remove references to Benevolent Dictator
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34671>
_______________________________________

From report at bugs.python.org  Thu Sep 13 21:28:24 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 01:28:24 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536888504.62.0.956365154283.issue33649@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4e824e96491f33c8a8462aa4970c55942064ae76 by Miss Islington (bot) (Carol Willing) in branch 'master':
bpo-33649: Polish asyncio subprocess and sync docs (GH-9285)
https://github.com/python/cpython/commit/4e824e96491f33c8a8462aa4970c55942064ae76


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 13 23:09:38 2018
From: report at bugs.python.org (Benjamin Mintz)
Date: Fri, 14 Sep 2018 03:09:38 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
In-Reply-To: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>
Message-ID: <1536894578.61.0.956365154283.issue34635@psf.upfronthosting.co.za>


Benjamin Mintz <benjabean1 at gmail.com> added the comment:

I didn't have one in mind. I just noticed that there was a getmro which accessed __mro__ but no corresponding method for __subclasses__.
That got me getsubclasses and getallsubclasses.

Then I thought it would be cool if you could walk the tree of subclasses in code, so I wrote getsubclasstree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Thu Sep 13 23:34:53 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 03:34:53 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
In-Reply-To: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>
Message-ID: <1536896093.48.0.956365154283.issue34635@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

__subclasses__ is, as Tim Peters put it [0], "just Python exposing an
internal mechanism for the morbidly curious".
I'd expect that not all alternative implementations of Python have something like __subclasses__ -- it's a detail of the implementation (as opposed to the MRO, which is something any implementation of the Python language needs to be able to compute).
It certainly is cool functionality, but keep in mind we'd have to support it for decades, and it would put pressure on other Python implementations to add something like __subclasses__.

With that in mind, and because there's no real use case, I think it's better to not add this to inspect.

[0] https://mail.python.org/pipermail/python-list/2003-August/210297.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Thu Sep 13 23:46:55 2018
From: report at bugs.python.org (Benjamin Mintz)
Date: Fri, 14 Sep 2018 03:46:55 +0000
Subject: [issue34635] inspect: add tools for inspecting subclasses
In-Reply-To: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>
Message-ID: <1536896815.76.0.956365154283.issue34635@psf.upfronthosting.co.za>


Change by Benjamin Mintz <benjabean1 at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34635>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:01:29 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:01:29 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
Message-ID: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

With the musl C library, one has failures like this:

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 273, in test_strptime
    time.strptime(strf_output, format)
ValueError: time data '' does not match format '%Z'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 276, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with '' input.
----------------------------------------------------------------------

The root problem is that time.strptime('%Z', time.gmtime()) won't work?it returns an empty string?even though time.gmtime() will probably have a valid tm_zone field. This is because musl has a safety mechanism where it refuses to process a tm_zone entry unless it produced the string. (See https://git.musl-libc.org/cgit/musl/commit/?id=d78be392e144c338f58ce6a51d82c859126c137d.)

As a partial workaround, I propose we check whether an incoming time.struct_time instance has an tm_zone member equal to tzname[0] or tzname[1], and place one of those global strings into the C-level tm struct if they do match.

----------
components: Library (Lib)
messages: 325319
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: '%Z' strftime specifier never works with musl
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:04:40 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 14 Sep 2018 04:04:40 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1536897880.6.0.956365154283.issue34656@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/issue34656>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:06:29 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:06:29 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
In-Reply-To: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>
Message-ID: <1536897989.41.0.956365154283.issue34672@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8719
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:14:32 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:14:32 +0000
Subject: [issue34673] make the eval loop more editable
Message-ID: <1536898472.44.0.956365154283.issue34673@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

The TARGET macro in ceval.c hides control flow, most importantly the case statement. This confuses my editor and makes it indent things automatically improperly. This can be fixed by moving the case statements out of the TARGET macro.

----------
components: Interpreter Core
messages: 325320
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: make the eval loop more editable
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34673>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:15:54 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:15:54 +0000
Subject: [issue34673] make the eval loop more editable
In-Reply-To: <1536898472.44.0.956365154283.issue34673@psf.upfronthosting.co.za>
Message-ID: <1536898554.89.0.956365154283.issue34673@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8720
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34673>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:28:14 2018
From: report at bugs.python.org (Christian Tismer)
Date: Fri, 14 Sep 2018 04:28:14 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536899294.18.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

Petr, Fine! PySide's problems are solved for now, no worries.
But as mentioned, there is more.


Problem 1)
----------

There is another thing that gives problems:

When creating types which have fields "behind" the normal type fields,
PySide had explicit structs that contained PyHeaptypeObject explicitly,
plus the extra fields.

We changed that into a normal PyType declaration (opaque) and a pointer
expression that dynamically computed the offset.

For that, we needed sizeof(PyType_Type). Ok, that could be solved by Python 
code, but this "trick" is not so obvious and should be documented, or
a variable should be provided that gives the heap type size, dynamically.


Problem 2)
----------

Harder is this:

For some operations, we needed access to fields of normal types, for instance the
tp_new field of PyType_Type. That is not possible, although it would be easy:

PyType_GetSlot forbids access to normal types, rigorously.
But concerning the "normal" type fields, those which are not indirections,
it would cost nothing to allow this for normal types.

This uses a property of types which has not explicitly been used:

* All types have the same basic structure *

That means, we can allow access to all "tp_" fields with simply changing a check
in PyType_GetSlot.

I'm not sure if that information should be made official. May be it should be hidden
and PyType_GetSlot should be made more complicated. But the proposed change comes
at no cost. And the prefixes like "nb_" or "sq_" are still visible, so I don't
think there was an intent to make type structures completely opaque?

For PySide, it was crucial to use that information to compute the offset of
certain fields of normal types, which is a bit of a Pep 384 breach.
We wrote code that verifies that these assumptions are all valid, but I would be 
happy to remove that and revert to only using PyType_GetSlot.

Please let me know if I can help with something!

Cheers - Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:28:45 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:28:45 +0000
Subject: [issue34674] assume unistd.h exists
Message-ID: <1536899325.09.0.956365154283.issue34674@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

We still have some conditional code under HAVE_UNISTD. However, we also unconditionally include it many other places, so let's just get rid of the condition and configure check.

----------
components: Build
messages: 325322
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: assume unistd.h exists
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34674>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:29:32 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:29:32 +0000
Subject: [issue34674] assume unistd.h exists
In-Reply-To: <1536899325.09.0.956365154283.issue34674@psf.upfronthosting.co.za>
Message-ID: <1536899372.52.0.956365154283.issue34674@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8721
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34674>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:42:57 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:42:57 +0000
Subject: [issue30786] getaddrinfo emulation does not support AI_NUMERICSERV
In-Reply-To: <1498560008.54.0.948539783321.issue30786@psf.upfronthosting.co.za>
Message-ID: <1536900177.34.0.956365154283.issue30786@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

What platform needs Modules/getaddrinfo.c these days?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30786>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:50:24 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 04:50:24 +0000
Subject: [issue34552] Clarify built-in types comparisons
In-Reply-To: <1535693872.67.0.56676864532.issue34552@psf.upfronthosting.co.za>
Message-ID: <1536900624.91.0.956365154283.issue34552@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1aeba7458d2aaf8a03b5d443179d122ceb2ccece by Miss Islington (bot) (Windson yang) in branch 'master':
bpo-34552: Clarify built-in types comparisons (GH-9035)
https://github.com/python/cpython/commit/1aeba7458d2aaf8a03b5d443179d122ceb2ccece


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34552>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:57:34 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:57:34 +0000
Subject: [issue34674] assume unistd.h exists
In-Reply-To: <1536899325.09.0.956365154283.issue34674@psf.upfronthosting.co.za>
Message-ID: <1536901054.63.0.956365154283.issue34674@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset ea13740a37347d68d096b11b87c9167917ccfc22 by Benjamin Peterson in branch 'master':
bpo-34674: Assume unistd.h exists on Unix. (GH-9290)
https://github.com/python/cpython/commit/ea13740a37347d68d096b11b87c9167917ccfc22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34674>
_______________________________________

From report at bugs.python.org  Fri Sep 14 00:58:00 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:58:00 +0000
Subject: [issue34674] assume unistd.h exists
In-Reply-To: <1536899325.09.0.956365154283.issue34674@psf.upfronthosting.co.za>
Message-ID: <1536901080.76.0.956365154283.issue34674@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34674>
_______________________________________

From report at bugs.python.org  Fri Sep 14 01:08:35 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 14 Sep 2018 05:08:35 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1536901715.84.0.956365154283.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 19003841e965bbf56fd06824d6093620c1b66f9e by Gregory P. Smith in branch 'master':
bpo-6721: Hold logging locks across fork() (GH-4071)
https://github.com/python/cpython/commit/19003841e965bbf56fd06824d6093620c1b66f9e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Sep 14 01:08:43 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 05:08:43 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1536901723.19.0.956365154283.issue6721@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8722

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Sep 14 01:19:38 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 14 Sep 2018 05:19:38 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536902378.23.0.956365154283.issue34658@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +8723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Fri Sep 14 01:24:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 14 Sep 2018 05:24:27 +0000
Subject: [issue34658] subprocess with preexec_fn when fork() fails could
 corrupt PyErr state
In-Reply-To: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>
Message-ID: <1536902667.48.0.956365154283.issue34658@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34658>
_______________________________________

From report at bugs.python.org  Fri Sep 14 02:09:44 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Sep 2018 06:09:44 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1536905384.65.0.956365154283.issue32117@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Move to 3.8.

----------
nosy: +gvanrossum
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Fri Sep 14 02:56:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 06:56:27 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536908187.96.0.956365154283.issue33073@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 5ac704306f4b81ae3f28d8742408d3214b145e8a by Raymond Hettinger (Lisa Roach) in branch 'master':
bpo-33073: Adding as_integer_ratio to ints. (GH-8750)
https://github.com/python/cpython/commit/5ac704306f4b81ae3f28d8742408d3214b145e8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:17:01 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Sep 2018 07:17:01 +0000
Subject: [issue32876] HTMLParser raises exception on some inputs
In-Reply-To: <1519069936.36.0.467229070634.issue32876@psf.upfronthosting.co.za>
Message-ID: <1536909421.28.0.956365154283.issue32876@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +patch
pull_requests: +8724
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32876>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:17:42 2018
From: report at bugs.python.org (Lisa Roach)
Date: Fri, 14 Sep 2018 07:17:42 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1536909462.16.0.956365154283.issue26467@psf.upfronthosting.co.za>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
keywords: +patch
pull_requests: +8725
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:20:38 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 07:20:38 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536909638.28.0.956365154283.issue33073@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +8726

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:21:54 2018
From: report at bugs.python.org (shashank)
Date: Fri, 14 Sep 2018 07:21:54 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1536909714.51.0.956365154283.issue21109@psf.upfronthosting.co.za>


shashank <shanx.shashank at gmail.com> added the comment:

Figured a fix for the bug I found, trick was to keep track of current working dir of symlink it was trying to evaluate.

Attached patch: safetarfile-3.diff
Patch is for code only.

I'd like to see this go thorough, and would appreciate feedback.

----------
Added file: https://bugs.python.org/file47803/safetarfile-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:28:22 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 14 Sep 2018 07:28:22 +0000
Subject: [issue32876] HTMLParser raises exception on some inputs
In-Reply-To: <1519069936.36.0.467229070634.issue32876@psf.upfronthosting.co.za>
Message-ID: <1536910102.62.0.956365154283.issue32876@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There are at least a couple of issues here.

The first one is the way the parser handles '<![...'.  The linked page contains markup like '<![STAT]-[USER-ACTIVE]!>' and since the parser currently checks for '<![' only, _markupbase.py:parse_marked_section gets called and an error gets incorrectly raised.   
However "8.2.4.42. Markup declaration open state"[0], states that after consuming '<!', there are only 4  valid paths forward:
1) if we have '<!--', it's a comment;
2) if we have '<!doctype', it's a doctype declaration;
3) if we have '<![CDATA[', it's a CDATA section;
4) if it's something else, it's a bogus comment;

The above example should therefore fall into 4), and be treated like a bogus comment.

PR-9295 changes parse_html_declaration() to align to the specs and implement path 3), resulting in the webpage being parsed without errors (the invalid markup is considered as a bogus comment).


The second issue is about an EOF in the middle of a bogus markup declaration, like in the minified example provided by OP ("<![\n").  In this case the comment should still be emitted ('[\n'), but currently nothing gets emitted.  I'll look more into it either tomorrow or later this month and update the PR accordingly (or perhaps I'll open a separate issue).


[0]: https://www.w3.org/TR/html52/syntax.html#tokenizer-markup-declaration-open-state

----------
versions: +Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32876>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:29:31 2018
From: report at bugs.python.org (Freed_Slave)
Date: Fri, 14 Sep 2018 07:29:31 +0000
Subject: [issue34675] Avoid terminology related to slavery
Message-ID: <1536910171.17.0.956365154283.issue34675@psf.upfronthosting.co.za>


New submission from Freed_Slave <Freed_Slave at notmailinator.com>:

It is very good to see that "master" and "slave" terminology was removed from the project, however there are still references to "owned" references, as if these references were property. There are also things needing to be "freed" as if they were indentured servants.

I would like to open up discussion about better terminology - and when better terminology has been agreed upon I do not mind submitting a PR to get rid of this exclusive language.

"Freed" terminology:

* https://github.com/python/cpython/search?q=freed&unscoped_q=freed

There are also additional instances were "free" is used instead of "clear" but the context makes it harder to discover with a naive search.

"Owned" terminology:

* https://github.com/python/cpython/search?utf8=%E2%9C%93&q=owned&type=

"Master/Slave" terminology, now removed:

* https://bugs.python.org/issue34605

On the topic of inclusive/exclusive terminology, there are other problematic things that should be addressed - either here or in separate issues. However I'd like to draw attention to one particularly sexist email in `test_smtplib.py` "my_mom at great.cooker.com" - hilarious! Not. It especially sticks out among the more generic and inclusive test emails. I particularly like the inclusion of "P?olo <f?o at bar.com>" but then in a test email he makes a sexual innuendo.

* https://github.com/python/cpython/search?utf8=%E2%9C%93&q=mom&type=

* Said innuendo: "oh l? l?, know what I mean, know what I mean?\n\n")"

----------
assignee: docs at python
components: Documentation
messages: 325331
nosy: Freed_Slave, docs at python
priority: normal
severity: normal
status: open
title: Avoid terminology related to slavery
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34675>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:37:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 07:37:36 +0000
Subject: [issue33774] Document that @lru_cache caches based on exactly how the
 function arguments are specified
In-Reply-To: <1528217935.32.0.592728768989.issue33774@psf.upfronthosting.co.za>
Message-ID: <1536910656.87.0.956365154283.issue33774@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +8727
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33774>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:55:12 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 07:55:12 +0000
Subject: [issue33774] Document that @lru_cache caches based on exactly how the
 function arguments are specified
In-Reply-To: <1528217935.32.0.592728768989.issue33774@psf.upfronthosting.co.za>
Message-ID: <1536911712.79.0.956365154283.issue33774@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8728

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33774>
_______________________________________

From report at bugs.python.org  Fri Sep 14 03:59:40 2018
From: report at bugs.python.org (=?utf-8?q?Lukas_R=C3=B6llin?=)
Date: Fri, 14 Sep 2018 07:59:40 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1536911980.54.0.956365154283.issue33498@psf.upfronthosting.co.za>


Lukas R?llin <lsroellin at gmail.com> added the comment:

I definitely would like this too. I have a code base that's only grazing on path usage, and I could completely convert it to pathlib, but one shutil.rmtree still remains...

----------
nosy: +Dreami

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:09:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 08:09:01 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536912541.75.0.956365154283.issue33073@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +8729

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:14:28 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 08:14:28 +0000
Subject: [issue33774] Document that @lru_cache caches based on exactly how the
 function arguments are specified
In-Reply-To: <1528217935.32.0.592728768989.issue33774@psf.upfronthosting.co.za>
Message-ID: <1536912868.72.0.956365154283.issue33774@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33774>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:14:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 08:14:30 +0000
Subject: [issue31305] 'pydoc -w import' report "no Python documentation found
 for 'import'"
Message-ID: <1536912870.64.0.956365154283.issue31305@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

> Run "pydoc -w <name>" to write out the HTML documentation for a module
to a file named "<name>.html".

As mentioned in the help this works only for modules and since import is a keyword it throws an error. Maybe this could be added as an enhancement?

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31305>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:23:16 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 08:23:16 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536913396.88.0.956365154283.issue33073@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:37:10 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 08:37:10 +0000
Subject: [issue33259] Encoding issue in the name of the local DST timezone
In-Reply-To: <1523396060.7.0.682650639539.issue33259@psf.upfronthosting.co.za>
Message-ID: <1536914230.63.0.956365154283.issue33259@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems like formatting timezone names on Windows has a lot of issues. I don't if it's related to the ones reported before but just like to add reference comment with more issues : https://bugs.python.org/msg302937

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33259>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:39:14 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 08:39:14 +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: <1536914354.72.0.956365154283.issue33173@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33173>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:39:42 2018
From: report at bugs.python.org (Anthony Flury)
Date: Fri, 14 Sep 2018 08:39:42 +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: <1536914382.51.0.956365154283.issue32933@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

I still support backporting to 3.6 and 3.7 : 

Yes it is correct that this fix could change the behavior of existing test code, but only if someone has written a test case for a function where : 

 1. The function under test uses dunder_iter iteration
 2. The test case provides a read_data content to mock_open
 3. The test case expects a response from the function which 
    implies that the file provided is empty/invalid in all cases - regardless of the data provided.

I simply cannot see that someone would implement a test case such as this - if your file has data, you would expect that your function under test would recognize that the data exists, if that data is valid; and most code will differentiate between invalid data and empty data.

So the only time I think this fix would change the behavior of existing code is if someone has written an illogical test case, which is currently passing and would now fail (since the test function will no2 see the data being provided and respond as such).

Specifically the only change in behavior to existing code is to highlight an invalid test case and potentially a bug in the code under test. It is for this reason I support backporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:42:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 08:42:07 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536914527.58.0.956365154283.issue33073@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The merged PR contains several errors. See comments on GitHub.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 04:43:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 08:43:34 +0000
Subject: [issue33052] Sporadic segmentation fault in test_datetime
In-Reply-To: <1520803979.78.0.467229070634.issue33052@psf.upfronthosting.co.za>
Message-ID: <1536914614.41.0.956365154283.issue33052@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33052>
_______________________________________

From report at bugs.python.org  Fri Sep 14 05:03:31 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 09:03:31 +0000
Subject: [issue32496] lib2to3 fails to parse a ** of a conditional expression
In-Reply-To: <1515108489.44.0.467229070634.issue32496@psf.upfronthosting.co.za>
Message-ID: <1536915811.92.0.956365154283.issue32496@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32496>
_______________________________________

From report at bugs.python.org  Fri Sep 14 05:30:53 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 09:30:53 +0000
Subject: [issue32080] Re locale test fails after installing Python 3.6.3 on
 ubuntu 16.04
In-Reply-To: <1511157949.99.0.213398074469.issue32080@psf.upfronthosting.co.za>
Message-ID: <1536917453.72.0.956365154283.issue32080@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is it something specific to the environment? I tried the test on Ubuntu 16.04 on both master and on v3.6.3 with no errors. Maybe if you can execute the following code based on which the test is executed then it will be helpful to debug this.


import locale

foo, enc = locale.getlocale(locale.LC_CTYPE)
# Search non-ASCII letter
for i in range(128, 256):
    try:
        c = bytes([i]).decode(enc)
        sletter = c.lower()
        if sletter == c: continue
        bletter = sletter.encode(enc)
        if len(bletter) != 1: continue
        if bletter.decode(enc) != sletter: continue
        bpat = re.escape(bytes([i]))
        break
    except (UnicodeError, TypeError):
        pass
else:
    bletter = None
    bpat = b'A'
# Bytes patterns

print(bletter)
print(bpat)
print(foo)
print(enc)



Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32080>
_______________________________________

From report at bugs.python.org  Fri Sep 14 05:31:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 09:31:41 +0000
Subject: [issue32153] mock.create_autospec fails if an attribute is a partial
 function
In-Reply-To: <1511864595.09.0.213398074469.issue32153@psf.upfronthosting.co.za>
Message-ID: <1536917501.26.0.956365154283.issue32153@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32153>
_______________________________________

From report at bugs.python.org  Fri Sep 14 05:42:49 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 09:42:49 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536918169.77.0.956365154283.issue33073@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The merged PR contains several errors. See comments on GitHub.

Some comments were seen after the merge of 8750 and were addressed in 9297.  If you want to change the checked in code, please open a separate PR and tracker item.  If you want different doc markup, please just fix it.  This issue has already sprawled out of proportion to its usefulness and has eaten many hours of our time.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 05:49:38 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 09:49:38 +0000
Subject: [issue31290] segfault on missing library symbol
In-Reply-To: <1503905323.73.0.492729138939.issue31290@psf.upfronthosting.co.za>
Message-ID: <1536918578.59.0.956365154283.issue31290@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31290>
_______________________________________

From report at bugs.python.org  Fri Sep 14 05:53:53 2018
From: report at bugs.python.org (Matthias Bussonnier)
Date: Fri, 14 Sep 2018 09:53:53 +0000
Subject: [issue34616] implement "Async exec"
In-Reply-To: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>
Message-ID: <1536918833.96.0.956365154283.issue34616@psf.upfronthosting.co.za>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

> A utility to check whether an AST requires async mode should be fairly straightforward.

Here is one case we forgot in IPython apparently :

In [1]: x = 1
   ...: def f():
   ...:     nonlocal x
   ...:     x = 10000

This is not detected as a syntax error, but considered as asyn, we took an approach that prefer false positive (try to run invalid syntax as async) than false negative (reject valid async-code). Add this to the test suite for this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34616>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:10:37 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 10:10:37 +0000
Subject: [issue31177] unittest mock's reset_mock throws an error when an
 attribute has been deleted
In-Reply-To: <1502374939.75.0.688742031254.issue31177@psf.upfronthosting.co.za>
Message-ID: <1536919837.66.0.956365154283.issue31177@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can confirm this behavior on CPython master as well. It seems that when an attribute is deleted then a deleted flag is set for the attribute at https://github.com/python/cpython/blob/73820a60cc3c990abb351540ca27bf7689bce8ac/Lib/unittest/mock.py#L737 . But when reset_mock is called it doesn't check for the deleted flag at https://github.com/python/cpython/blob/73820a60cc3c990abb351540ca27bf7689bce8ac/Lib/unittest/mock.py#L543

?  cpython git:(master) ./python.exe ../backups/bpo31177.py
Traceback (most recent call last):
  File "../backups/bpo31177.py", line 5, in <module>
    m.reset_mock()
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 546, in reset_mock
    child.reset_mock(visited)
AttributeError: '_SentinelObject' object has no attribute 'reset_mock'

A simple patch would be to skip the deleted as below but some of the code in mock module raise an AttributeError. I don't know the correct behavior here. But applying the below patch and running tests with `./python.exe Lib/unittest/test/` doesn't cause any test failure.

diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index db1e642c00..700e2fb8b9 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -541,7 +541,7 @@ class NonCallableMock(Base):
             self._mock_side_effect = None
 
         for child in self._mock_children.values():
-            if isinstance(child, _SpecState):
+            if isinstance(child, _SpecState) or child is _deleted:
                 continue
             child.reset_mock(visited)
 
I will try to make a PR if it's ok.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31177>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:13:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 10:13:50 +0000
Subject: [issue34676] Guarantie that divmod() and PyNumber_Divmod() return a
 2-tuple
Message-ID: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

It is documented that divmod() returns a pair of numbers, but the implementation doesn't enforce this. Actually divmod() just returns the result of __divmod__() or __rdivmod__() without checking it. PyNumber_Divmod() is documented as the C equivalent of divmod(). But since it returns a 2-tuple in all implemented cases, the user code can expect that it always return a 2-tuple. This can lead to hidden bugs similar to issue31577.

I think there are no reasons of returning anything except a 2-tuple from divmod(). Forcing this conditions can save third-party code from crashes. The following PR make divmod() and PyNumber_Divmod() always returning a 2-tuple.

----------
components: Interpreter Core
messages: 325341
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Guarantie that divmod() and PyNumber_Divmod() return a 2-tuple
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:17:32 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 14 Sep 2018 10:17:32 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536920252.0.0.956365154283.issue34597@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Linking with newer SDKs is needed to get access to some newer features and APIs. That's less relevant for Python itself, but can be relevant for the embedding application.  You can still compile Python itself on an older machine, then link it into an application build against a newer SDK. This does make the build process harder though.

However, there seem to be some issues when you mix code linked for different deployment targets, for example <https://bitbucket.org/ronaldoussoren/pyobjc/issues/174/crash-using-dictionaryservices-on-1012>.  This is issue contains a C extension that works correctly when CPython is build with a new SDK and crashed hard with the interpreters on Python.org.

This is one reason why I will at some time in the future look into this, but I cannot say when that will happen because I have limited time to work on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:19:21 2018
From: report at bugs.python.org (Christoph Reiter)
Date: Fri, 14 Sep 2018 10:19:21 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536920361.37.0.956365154283.issue34597@psf.upfronthosting.co.za>


Change by Christoph Reiter <reiter.christoph at gmail.com>:


----------
nosy:  -lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:24:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 10:24:01 +0000
Subject: [issue34676] Guarantie that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1536920641.36.0.956365154283.issue34676@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8730
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:46:40 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 10:46:40 +0000
Subject: [issue31177] unittest mock's reset_mock throws an error when an
 attribute has been deleted
In-Reply-To: <1502374939.75.0.688742031254.issue31177@psf.upfronthosting.co.za>
Message-ID: <1536922000.65.0.956365154283.issue31177@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +8731
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31177>
_______________________________________

From report at bugs.python.org  Fri Sep 14 06:58:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 10:58:24 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1536922704.52.0.956365154283.issue33073@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8732

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Fri Sep 14 07:20:34 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 14 Sep 2018 11:20:34 +0000
Subject: [issue34675] Avoid terminology related to slavery
In-Reply-To: <1536910171.17.0.956365154283.issue34675@psf.upfronthosting.co.za>
Message-ID: <1536924034.26.0.956365154283.issue34675@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

No thanks.

----------
nosy: +Mariatta
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34675>
_______________________________________

From report at bugs.python.org  Fri Sep 14 08:02:28 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 14 Sep 2018 12:02:28 +0000
Subject: [issue34671] Remove references to Benevolent Dictator
In-Reply-To: <1536886822.26.0.956365154283.issue34671@psf.upfronthosting.co.za>
Message-ID: <1536926548.45.0.956365154283.issue34671@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

No thanks.

----------
nosy: +Mariatta
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34671>
_______________________________________

From report at bugs.python.org  Fri Sep 14 08:17:49 2018
From: report at bugs.python.org (mediator42)
Date: Fri, 14 Sep 2018 12:17:49 +0000
Subject: [issue34677] Event scheduler page example
Message-ID: <1536927469.93.0.956365154283.issue34677@psf.upfronthosting.co.za>


New submission from mediator42 <h.lensch at lmt.uni-saarland.de>:

Hi,
I am pretty confident, that the example you put on the Event scheduler page (https://docs.python.org/3.7/library/sched.html) is somehow strange. 

If the priority argument behave as described, it should print the "keyword" line before the "positional" line, since these events are scheduled for the same time but "keyword" has a higher priority than "positional".

When I run this script on my PC it behaves correctly.

Best reagrds

----------
assignee: docs at python
components: Documentation
messages: 325345
nosy: docs at python, mediator42
priority: normal
severity: normal
status: open
title: Event scheduler page example
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34677>
_______________________________________

From report at bugs.python.org  Fri Sep 14 08:56:13 2018
From: report at bugs.python.org (dwayne gigleum)
Date: Fri, 14 Sep 2018 12:56:13 +0000
Subject: [issue34678] need to remove the term "white space"
Message-ID: <1536929773.36.0.956365154283.issue34678@psf.upfronthosting.co.za>


New submission from dwayne gigleum <dwaygig at gmail.com>:

As we are purging offensive language

"white space" needs removing, as this can be offensive.

as seen in lots of places: https://github.com/python/cpython/search?p=1&q=white+space

----------
messages: 325346
nosy: dwaygig
priority: normal
severity: normal
status: open
title: need to remove the term "white space"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34678>
_______________________________________

From report at bugs.python.org  Fri Sep 14 09:54:00 2018
From: report at bugs.python.org (Zorg)
Date: Fri, 14 Sep 2018 13:54:00 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536933240.51.0.956365154283.issue34597@psf.upfronthosting.co.za>


Zorg <zorgiepoo at gmail.com> added the comment:

> Why do you believe that is safer?  Apple goes to great lengths to provide compatibility for existing applications to keep running on newer systems. 

They also don't want developers to develop using older SDKs. Hypothetically speaking, more information may be stored in the binaries, and there could be something down the road to opt into that requires all binaries to be linked against a certain SDK. Or your code takes an older path based on the SDK version at runtime -- python may include some other higher level baggage too, like the tkinter stuff for instance.

There is some middle ground other than weak linking; stripping out features from the configure part of the project and opt in to using the deprecated APIs. Not as ideal as weak linking, but better than building on an older SDK IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Fri Sep 14 10:01:26 2018
From: report at bugs.python.org (Zorg)
Date: Fri, 14 Sep 2018 14:01:26 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1536933686.79.0.956365154283.issue34597@psf.upfronthosting.co.za>


Zorg <zorgiepoo at gmail.com> added the comment:

Also more obviously: it's less convenient for others keeping themselves up to date to set up an older development environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Fri Sep 14 10:52:51 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 14:52:51 +0000
Subject: [issue33052] Sporadic segmentation fault in test_datetime
In-Reply-To: <1520803979.78.0.467229070634.issue33052@psf.upfronthosting.co.za>
Message-ID: <1536936771.3.0.956365154283.issue33052@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33052>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:07:21 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Sep 2018 15:07:21 +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: <1536937641.31.0.956365154283.issue32933@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The potential change in behavior affecting existing code was one issue.  But the other was the fact that people writing tests to make use of the new behavior can't depend on that behavior being there for 3.7 or 3.6 without checking the patch level, for example, 3.6.7 vs 3.6.6.  That's one of the main reasons we generally do not backport behavior changes unless they are a clear bug; as I noted. this particular issue seems somewhere in between a bug and a feature.  Given how far along we are in the 3.6.x cycle, I think we definitely should not backport to 3.6.  Since 3.7 is near the beginning of its support cycle, I would not object if we did backport this for 3.7.1.  I'll leave it up to Berker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:27:45 2018
From: report at bugs.python.org (Nic Watson)
Date: Fri, 14 Sep 2018 15:27:45 +0000
Subject: [issue34679] asyncio.add_signal_handler call fails if not on main
 thread
Message-ID: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za>


New submission from Nic Watson <pythonbugs at nicwatson.org>:

Summary:  essentially asyncio.add_signal_handler doesn't work when called off the main thread.  One might consider this a documentation failure.

(Note: there's also a bigger issue with cleanup, which I'll submit separately)

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/asyncio/unix_events.py", line 91, in add_signal_handler
    signal.set_wakeup_fd(self._csock.fileno())
ValueError: set_wakeup_fd only works in main thread

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/home/nic/tmp/signal_event_loop_bug.py", line 14, in do_loop
    loop.add_signal_handler(signal.SIGINT, mysighandler)
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/asyncio/unix_events.py", line 93, in add_signal_handler
    raise RuntimeError(str(exc))
RuntimeError: set_wakeup_fd only works in main thread

Code:

import asyncio
import signal
import threading

def mysighandler():
    pass

def do_loop():
    loop = asyncio.new_event_loop()
    # This will fail with RuntimeError: set_wakeup_fd only works in main thread
    loop.add_signal_handler(signal.SIGINT, mysighandler)
    loop.close()

t = threading.Thread(target=do_loop)
t.start()
t.join()

----------
components: asyncio
messages: 325350
nosy: asvetlov, jnwatson, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.add_signal_handler call fails if not on main thread
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34679>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:29:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 15:29:00 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536938940.37.0.956365154283.issue34605@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

News about this issue published on different resources are exaggerated. Actually the controversial changes were rejected. All merged changes look correct to me, they fix outdated terminology ("worker" instead of "buildslave" is now the official term in the Buildbot documentation) and make the documentation using more common terminology (for example "parent process" instead of "master process" in context of multiprocessing).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:30:49 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 15:30:49 +0000
Subject: [issue34653] PyParser_SimpleParseStringFilename should be deleted
In-Reply-To: <1536789485.93.0.956365154283.issue34653@psf.upfronthosting.co.za>
Message-ID: <1536939049.96.0.956365154283.issue34653@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not going to backport this to 3.7, just in case.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34653>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:32:19 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 15:32:19 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536939139.83.0.956365154283.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 9b9d97dd139a799d28ff8bc90d118b1cac190b03 by Eric V. Smith in branch 'master':
bpo-34363: dataclasses.asdict() and .astuple() now handle fields which are namedtuples. (GH-9151)
https://github.com/python/cpython/commit/9b9d97dd139a799d28ff8bc90d118b1cac190b03


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:32:31 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 15:32:31 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536939151.46.0.956365154283.issue34363@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8733

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:33:28 2018
From: report at bugs.python.org (Nic Watson)
Date: Fri, 14 Sep 2018 15:33:28 +0000
Subject: [issue34680] asyncio event_loop close fails off main thread if signal
 handler registered
Message-ID: <1536939208.48.0.956365154283.issue34680@psf.upfronthosting.co.za>


New submission from Nic Watson <pythonbugs at nicwatson.org>:

If a signal handler callback is registered on an event loop, and the event loop has close() called on it, the close will fail.

Exception:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/home/nic/tmp/signal_event_loop_bug.py", line 9, in do_loop
    loop.close()
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/asyncio/unix_events.py", line 58, in close
    self.remove_signal_handler(sig)
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/asyncio/unix_events.py", line 147, in remove_signal_handler
    signal.signal(sig, handler)
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal only works in main thread

Code:
import asyncio
import signal
import threading

def mysighandler():
    pass

def do_loop(loop):
    loop.close()

loop = asyncio.new_event_loop()
loop.add_signal_handler(signal.SIGINT, mysighandler)
t = threading.Thread(target=do_loop, args=(loop,))
t.start()
t.join()

----------
components: asyncio
messages: 325354
nosy: asvetlov, jnwatson, yselivanov
priority: normal
severity: normal
status: open
title: asyncio event_loop close fails off main thread if signal handler registered
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34680>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:37:26 2018
From: report at bugs.python.org (epiphyte)
Date: Fri, 14 Sep 2018 15:37:26 +0000
Subject: [issue34679] asyncio.add_signal_handler call fails if not on main
 thread
In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za>
Message-ID: <1536939446.83.0.956365154283.issue34679@psf.upfronthosting.co.za>


Change by epiphyte <epiphyte at vertex.link>:


----------
nosy: +epiphyte

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34679>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:37:34 2018
From: report at bugs.python.org (epiphyte)
Date: Fri, 14 Sep 2018 15:37:34 +0000
Subject: [issue34680] asyncio event_loop close fails off main thread if signal
 handler registered
In-Reply-To: <1536939208.48.0.956365154283.issue34680@psf.upfronthosting.co.za>
Message-ID: <1536939454.71.0.956365154283.issue34680@psf.upfronthosting.co.za>


Change by epiphyte <epiphyte at vertex.link>:


----------
nosy: +epiphyte

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34680>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:45:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Sep 2018 15:45:42 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1536939942.78.0.956365154283.issue34582@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Co-opting this bug for my own PR, that will include these changes as well as generating JUnit-format test results and publishing them in Azure Pipelines builds.

----------
assignee:  -> steve.dower
components: +Build, Tests
title: VSTS builds should use new YAML syntax and pools -> VSTS builds should use jobs, pools, and test results
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:46:09 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Sep 2018 15:46:09 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1536939969.15.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8734

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:46:44 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 15:46:44 +0000
Subject: [issue34678] need to remove the term "white space"
In-Reply-To: <1536929773.36.0.956365154283.issue34678@psf.upfronthosting.co.za>
Message-ID: <1536940004.66.0.956365154283.issue34678@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34678>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:48:40 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 15:48:40 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536940120.59.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8735

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 11:53:17 2018
From: report at bugs.python.org (dwayne gigleum)
Date: Fri, 14 Sep 2018 15:53:17 +0000
Subject: [issue34678] need to remove the term "white space"
In-Reply-To: <1536929773.36.0.956365154283.issue34678@psf.upfronthosting.co.za>
Message-ID: <1536940397.99.0.956365154283.issue34678@psf.upfronthosting.co.za>


dwayne gigleum <dwaygig at gmail.com> added the comment:

are you being a hypocrit trying to supress me?

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34678>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:09:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 16:09:08 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
In-Reply-To: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>
Message-ID: <1536941348.52.0.956365154283.issue34672@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 5633c4f342d957df2ef0d67b9bfb472a0d28a76b by Benjamin Peterson in branch 'master':
bpo-34672: Try to pass the C library's own timezone strings back to it. (GH-9288)
https://github.com/python/cpython/commit/5633c4f342d957df2ef0d67b9bfb472a0d28a76b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:19:02 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Sep 2018 16:19:02 +0000
Subject: [issue34678] need to remove the term "white space"
In-Reply-To: <1536929773.36.0.956365154283.issue34678@psf.upfronthosting.co.za>
Message-ID: <1536941942.89.0.956365154283.issue34678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Trolling is not welcome.

----------
nosy: +eric.araujo
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34678>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:21:53 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 16:21:53 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
In-Reply-To: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>
Message-ID: <1536942113.86.0.956365154283.issue34672@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:22:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 16:22:32 +0000
Subject: [issue34681] Incorrect class name Pattern in sre_parse.py
Message-ID: <1536942152.74.0.956365154283.issue34681@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

In 8a3ebf8ca87a7d2989148d7c218974ab4235ca5d, with synchronizing regex engine with SRE 0.9.6, the class State in sre_parse.py was renamed to Pattern and the following comment was added: "master pattern object.  keeps track of global attributes".

This name is incorrect and misleading. This class doesn't represents a pattern in any sense. It just keeps global flags and groups information for parser. There is a class SupParser in sre_parse.py that represents a pattern or its part in intermediate representation, and there is a class Pattern defined in sre.c and exposed publicly, that represents a compiled pattern.

The proposed PR renames Pattern back to State and renames attribute, parameter and variable names for referring to objects of this class from pattern to state. All this is an internal API, but since there may be a third-party that uses it, it is for developer version only.

----------
components: Library (Lib), Regular Expressions
messages: 325359
nosy: effbot, ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Incorrect class name Pattern in sre_parse.py
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34681>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:26:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 16:26:03 +0000
Subject: [issue34681] Incorrect class name Pattern in sre_parse.py
In-Reply-To: <1536942152.74.0.956365154283.issue34681@psf.upfronthosting.co.za>
Message-ID: <1536942363.88.0.956365154283.issue34681@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8736
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34681>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:28:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 16:28:02 +0000
Subject: [issue34681] Incorrect class name Pattern in sre_parse.py
In-Reply-To: <1536942152.74.0.956365154283.issue34681@psf.upfronthosting.co.za>
Message-ID: <1536942482.38.0.956365154283.issue34681@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34681>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:29:24 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 16:29:24 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536942564.13.0.956365154283.issue26979@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

1) If I understand correctly, this problem could be solved by per-class C storage? Something like PyModuleDef.m_size / PyModule_GetState, but for classes?

2) Making PyType_GetSlot work for static types would not be trivial. 
All types do have the same *basic* structure (the tp_* fields), but the nb_*/sq_*/etc. fields don't need to be in the same order, and might not exist at all.
Even making it work for the tp_* fields only would bake in some assumptions I do want to get rid of.
I'd like to understand your use case better. Do you have a specific example here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:43:35 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 16:43:35 +0000
Subject: [issue34676] Guarantie that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1536943415.19.0.956365154283.issue34676@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I would be somewhat worried that this might break something like numpy (though not numpy specifically) which might be counting on the ability to write a wrapper that overloads this behavior.

Another concern is that people could be playing it fast-and-loose with actual types, and are returning something that fits the bill for a collections.abc.Sequence with length 2 (e.g. return [a, b]) but isn't an actual Tuple.

I would at least think that this should go through a deprecation cycle.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:49:47 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 16:49:47 +0000
Subject: [issue34682] Typo reports on docs@
Message-ID: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

>From ZooDSS (?????? ????????) on docs@:

https://mail.python.org/pipermail/docs/2018-September/037223.html :
"""
https://docs.python.org/3/reference/datamodel.html#metaclass-example - 
    "uses an collections.OrderedDict to remember" when it is better to use "uses a collections.OrderedDict to remember"

https://docs.python.org/3/reference/executionmodel.html#exceptions
"Exceptions are a means" - Is it correct to use "a" here? "means" means a lot of them. "a" means one.

"In either case, it prints a stack backtrace" - most of the time in Python documentation term "traceback" is used instead of "backtrace". It may mislead newcomers, so they will think, that this is potentially a new term.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"Due to their side effects on the containing scope, yield expressions are not permitted as part of the implicitly defined scopes used to implement comprehensions and generator expressions (in Python 3.7, such expressions emit DeprecationWarning when compiled, in Python 3.8+ they will emit SyntaxError).." - two periods in the end of the sentence.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"...or automatically when the sub-iterator is a generator (by returning a value from the sub-generator)." - inconsistent use of "sub-iterator" term. Previously subiterator was referenced several times as "subiterator" not "sub-iterator".

If i understood something wrong, then i am sorry.
"""

https://mail.python.org/pipermail/docs/2018-September/037224.html :
"""
https://docs.python.org/3/reference/expressions.html#yield-expressions

Term "sub-generator" is used in PEP 280 without dash ("-") symbol - "subgenerator". At the same time it is used as "sub-generator" 2 times on this page:

"generator (by returning a value from the sub-generator)." - here.

"The proposal to introduce the yield_from syntax, making delegation to sub-generators easy." - and here.
"""

https://mail.python.org/pipermail/docs/2018-September/037237.html :
"""
https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
"function as a asynchronous generator function." - it's better to say "function as an asynchronous generator function."

https://docs.python.org/3/reference/expressions.html#agen.__anext__
"When an asynchronous generator function is resumed with a __anext__() method" - may be better "...function is resumed with an __anext__() method".

"the awaitable instead raises an StopAsyncIteration exception" - at the same time here may be better to use "the awaitable instead raises a StopAsyncIteration exception".

https://docs.python.org/3/reference/expressions.html#agen.athrow
"an StopAsyncIteration exception is raised" - here is the same situation as previously. "a" instead of "an" may be better.

Here goes very special case, and if i am wrong you can laugh on me as much as you wish! =)

https://docs.python.org/3/reference/expressions.html#parenthesized-forms
"Since tuples are immutable, the rules for literals apply" - Tuples are immutable, but not literals. So may be "the same rules as for literals apply" is better? Or does it apply exactly those rules, that apply for literals? "()" - this is a literal, that yelds an empty tuple. But this doesn't connect, or i am wrong? If i am - then i am very sorry.

Again, if i mistook something - i am sorry. Thanks for the good work. This is the best documentation i've ever seen.
"""

----------
assignee: docs at python
components: Documentation
messages: 325362
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Typo reports on docs@
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34682>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:52:53 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 16:52:53 +0000
Subject: [issue33070] Add platform triplet for RISC-V
Message-ID: <1536943973.01.0.956365154283.issue33070@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> add new triplets for mips r6 and riscv variants

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33070>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:58:37 2018
From: report at bugs.python.org (Geoffrey Spear)
Date: Fri, 14 Sep 2018 16:58:37 +0000
Subject: [issue34682] Typo reports on docs@
In-Reply-To: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>
Message-ID: <1536944317.91.0.956365154283.issue34682@psf.upfronthosting.co.za>


Geoffrey Spear <geoffspear at gmail.com> added the comment:

"Means" is perfectly acceptable to use as a singular form: http://grammarist.com/usage/means/ (the rest of these all look like legitimate typos)

----------
nosy: +geoffreyspear

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34682>
_______________________________________

From report at bugs.python.org  Fri Sep 14 12:58:44 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 16:58:44 +0000
Subject: [issue34676] Guarantie that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1536944324.36.0.956365154283.issue34676@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-0 Perhaps this should be left as-is.  There is no known problem that we would be solving and it would add an extra step to a fine-grained function.  In general, I think we have these guards in places where it is known that downstream callers rely on a particular type signature for the return value.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:03:47 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 17:03:47 +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: <1536944627.59.0.956365154283.issue32933@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8737

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:04:31 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 17:04:31 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
In-Reply-To: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>
Message-ID: <1536944671.55.0.956365154283.issue34672@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8738

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:06:58 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 17:06:58 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536944818.86.0.956365154283.issue33649@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:


New changeset c9d66f0ed4f07b9d184d22abbfdd4c3c8e2702df by Carol Willing in branch 'master':
bpo-33649 Polish asyncio docs on queues, protocols, and subproccesses (#9306)
https://github.com/python/cpython/commit/c9d66f0ed4f07b9d184d22abbfdd4c3c8e2702df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:22:22 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Sep 2018 17:22:22 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
Message-ID: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Input file with a subtle error: a number where an assignment target is required:

for 1 in []: pass

Run it, it gives a SyntaxError.  Note how the caret pointing to the incorrect token is position one to the left of where you'd expect it:

  File "s.py", line 1
    for 1 in []: pass
       ^
SyntaxError: can't assign to literal

For every syntax error I've seen that's produced by ast.c this seems to be the case -- the caret is always positioned 1 too far left.

I tried to understand how this is happening but my AST-fu is lacking. It seems this has been happening since ast.c started added column numbers -- in Python 2.7 there's no caret at all, but in 3.4 and later there's a caret and it has the same problem. (Also in 3.3; I don't have 3.2 or older 3.x lying around to test.)

----------
messages: 325366
nosy: gvanrossum
priority: low
severity: normal
status: open
title: Caret positioned wrong for SyntaxError reported by ast.c
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/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:23:32 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 17:23:32 +0000
Subject: [issue33259] Encoding issue in the name of the local DST timezone
In-Reply-To: <1523396060.7.0.682650639539.issue33259@psf.upfronthosting.co.za>
Message-ID: <1536945812.51.0.956365154283.issue33259@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33259>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:24:29 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Sep 2018 17:24:29 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1536945869.35.0.956365154283.issue34683@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +emilyemorehouse

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:24:35 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 17:24:35 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1536945875.11.0.956365154283.issue31635@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:28:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 17:28:58 +0000
Subject: [issue32313] Wrong inspect.getsource for datetime
In-Reply-To: <1513201599.09.0.213398074469.issue32313@psf.upfronthosting.co.za>
Message-ID: <1536946138.93.0.956365154283.issue32313@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32313>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:30:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 17:30:28 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1536946228.96.0.956365154283.issue34683@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:35:00 2018
From: report at bugs.python.org (shirish)
Date: Fri, 14 Sep 2018 17:35:00 +0000
Subject: [issue34684] Generate _geoslib.c with Cython 0.28.2 for Python 3.7
 transition
Message-ID: <1536946500.32.0.956365154283.issue34684@psf.upfronthosting.co.za>


New submission from shirish <shirishag75 at gmail.com>:

umm... I do not know about python other than python $something.py to run a python script. 

At Debian people are having an issue with not having _geoslib.c generated with a more recent Cython 0.28.2 for the transition. 

There is a patch and the bug has been put at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903579

Could somebody have a look at it and recommend either at the bug-report or here what could be done to fix the issue.

----------
components: Build
messages: 325367
nosy: shirish
priority: normal
severity: normal
status: open
title: Generate _geoslib.c with Cython 0.28.2 for Python 3.7 transition
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34684>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:38:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 17:38:00 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536946680.02.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8739

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:39:16 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 17:39:16 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
In-Reply-To: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>
Message-ID: <1536946756.58.0.956365154283.issue34672@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b93062b7fbc965cd0d522f597ed51eb4e493dfc2 by Benjamin Peterson in branch 'master':
bpo-34672: Don't pass NULL to gmtime_r. (GH-9312)
https://github.com/python/cpython/commit/b93062b7fbc965cd0d522f597ed51eb4e493dfc2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:40:56 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 17:40:56 +0000
Subject: [issue34684] Generate _geoslib.c with Cython 0.28.2 for Python 3.7
 transition
In-Reply-To: <1536946500.32.0.956365154283.issue34684@psf.upfronthosting.co.za>
Message-ID: <1536946856.93.0.956365154283.issue34684@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

_geoslib.c is not part of the core distribution of Python, and in fact I don't know which project it *is* part of.  I'm afraid you'll need to find its home project and report this there.

----------
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34684>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:41:12 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 17:41:12 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
Message-ID: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

https://buildbot.python.org/all/#/builders/87/builds/1428/steps/4/logs/stdio


======================================================================
ERROR: test_setscheduler_with_policy (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_posix.py", line 1693, in test_setscheduler_with_policy
    scheduler=(policy, os.sched_param(priority))
PermissionError: [Errno 1] Operation not permitted: '/usr/home/buildbot/python/3.x.koobs-freebsd10/build/python'
======================================================================
FAIL: test_setscheduler_only_param (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_posix.py", line 1677, in test_setscheduler_only_param
    self.assertEqual(os.waitpid(pid, 0), (pid, 0))
AssertionError: Tuples differ: (96981, 256) != (96981, 0)
First differing element 1:
256
0
- (96981, 256)
?         ^^^
+ (96981, 0)
?         ^
----------------------------------------------------------------------

----------
components: Tests
messages: 325370
nosy: pablogsal
priority: normal
severity: normal
status: open
title: scheduler tests for posix_spawn fail on AMD64 FreeBSD 10.x Shared 3.x
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:42:00 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Fri, 14 Sep 2018 17:42:00 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
Message-ID: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>


New submission from Erwan Le Pape <lepaperwan3 at gmail.com>:

I'm attempting to leverage PEP 552 to make the core interpreter build process more deterministic. However, the standard Python Makefile uses `python -E` when calling the compileall (and all other setup scripts), which forces randomization since it can only be turned off through environment variables (which in turn leads to nondeterministic behaviour as noted in PEP 552 [1],[2]).

Also, is adding a flag that disables randomization something that would be acceptable? Or are options to the core interpreter to be kept to a minimum and this does not represent a large enough use-case?

This would basically hold in Modules/main.c in something as short as:
+ case 'r':
+     config->use_hash_seed = 1;
+     config->hash_seed = 0;
+     break;

----------
components: Interpreter Core
messages: 325371
nosy: lepaperwan
priority: normal
severity: normal
status: open
title: Add `-r`, as opposed to `-R` to Python core interpreter
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:47:18 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 17:47:18 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536947238.11.0.956365154283.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 78aa3d8f5204bc856d7b2eb67288cf90c6a30660 by Eric V. Smith (Miss Islington (bot)) in branch '3.7':
bpo-34363: dataclasses.asdict() and .astuple() now handle fields which are namedtuples. (GH-9151) (GH-9304)
https://github.com/python/cpython/commit/78aa3d8f5204bc856d7b2eb67288cf90c6a30660


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:48:54 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 17:48:54 +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: <1536947334.12.0.956365154283.issue28955@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset ad8a0004206ba7aec5a8a60fce413da718080db2 by Benjamin Peterson (Tony Flury) in branch 'master':
closes bpo-28955: Clarified comparisons between NaN and number in reference documentation (GH-5982)
https://github.com/python/cpython/commit/ad8a0004206ba7aec5a8a60fce413da718080db2


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28955>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:49:06 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 17:49:06 +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: <1536947346.29.0.956365154283.issue28955@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8740

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28955>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:50:23 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 17:50:23 +0000
Subject: [issue34682] Typo reports on docs@
In-Reply-To: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>
Message-ID: <1536947423.17.0.956365154283.issue34682@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Agreed with @geoffreyspear: "means" is okay, the rest of the changes look good.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34682>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:51:59 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 17:51:59 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1536947519.29.0.956365154283.issue34683@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm doing some fairly major surgery on line and column numbers for fixing f-string errors. I'll see if I can include this case, too.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:56:45 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 17:56:45 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
In-Reply-To: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>
Message-ID: <1536947805.97.0.956365154283.issue34685@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Some extra stdout when I try to reproduce this on FreeBSD:

test_setscheduler_only_param (test.test_posix.TestPosixSpawn) ... Traceback (most recent call last):
  File "<string>", line 5, in <module>
AttributeError: module 'os' has no attribute 'exit'
FAIL
test_setscheduler_with_policy (test.test_posix.TestPosixSpawn) ... Traceback (most recent call last):
  File "<string>", line 5, in <module>
AttributeError: module 'os' has no attribute 'exit'
FAIL

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:05:45 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 18:05: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: <1536948345.84.0.956365154283.issue28955@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca2fa2841f8e3ce5213a0e8c0abc1d0fdc7d386b by Miss Islington (bot) in branch '3.7':
closes bpo-28955: Clarified comparisons between NaN and number in reference documentation (GH-5982)
https://github.com/python/cpython/commit/ca2fa2841f8e3ce5213a0e8c0abc1d0fdc7d386b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28955>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:08:11 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 18:08:11 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1536948491.27.0.956365154283.issue34363@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/issue34363>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:13:48 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 14 Sep 2018 18:13:48 +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: <1536948828.08.0.956365154283.issue32933@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks, Ned!

Anthony, I'm one of the maintainers of https://github.com/testing-cabal/mock and I'd be happy to merge a PR that backports the fix to the PyPI version of mock.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:20:43 2018
From: report at bugs.python.org (Anthony Flury)
Date: Fri, 14 Sep 2018 18:20:43 +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: <1536949243.88.0.956365154283.issue32933@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:21:05 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 18:21:05 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1536949265.86.0.956365154283.issue34683@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think ast.c is in the right here and there are two complementary bugs in caret printing and the parser.

print_error_text does this:

    while (--offset > 0)
        PyFile_WriteString(" ", f);

which is off-by-one if offset is zero-indexed (which it should be IMO).

The parser has an off-by-one error in the other direction. When it reports an error, it reports the offset of the tokenizer's "cur" buffer. This is generally advanced past the location that actually resulted in a parser error. I believe the parser should be fixed to report the error offset as the offset of the start of the token that caused the error.

----------
nosy: +benjamin.peterson -eric.smith, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:25:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 18:25:38 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1536949538.22.0.956365154283.issue34686@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It would be preferable to fix build outputs to be deterministic even under randomization in the interpreter.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:29:34 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Sep 2018 18:29:34 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1536949774.59.0.956365154283.issue34683@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:42:07 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 18:42:07 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1536950527.25.0.956365154283.issue34683@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think Benjamin's diagnosis is correct. In which case, my f-string error reporting changes (see #34364) won't intersect with a fix to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 14:45:58 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Sep 2018 18:45:58 +0000
Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2n
In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za>
Message-ID: <1536950758.42.0.956365154283.issue31392@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Sorry, this should have been closed a while back.  We're now on to 1.0.2p for 3.6.7 and 1.1.0i for 3.7.1.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31392>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:02:40 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 19:02:40 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1536951760.9.0.956365154283.issue3468@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8741

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:04:13 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 19:04:13 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
In-Reply-To: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>
Message-ID: <1536951853.79.0.956365154283.issue34685@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

What is failing is this line in the spawned process:

os.sched_getparam(0).sched_priority != {priority}

For some reason posix_spawn cannot change the priority in BSD. I have tried to hardcode the change in the implementation but the priority does not change in the child.

I am out of ideas, except skipping the tests on these systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:05:31 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 19:05:31 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
In-Reply-To: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>
Message-ID: <1536951931.75.0.956365154283.issue34685@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8742
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:09:19 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 19:09:19 +0000
Subject: [issue32313] Wrong inspect.getsource for datetime
In-Reply-To: <1513201599.09.0.213398074469.issue32313@psf.upfronthosting.co.za>
Message-ID: <1536952159.01.0.956365154283.issue32313@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32313>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:09:40 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 19:09:40 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1536952180.13.0.956365154283.issue31635@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:11:49 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 19:11:49 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1536952309.3.0.956365154283.issue24937@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Well, hasn't this languished for a while.

I've talked with Benjamin, and he's OK with just removing the "Porting Extension Modules to Python 3" HOWTO, and replacing it by links to external guides that do a much better job at documenting this.

Also, Python 2.6 and 3.0 is EOL; it should be fine to scrub capsulethunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:12:22 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 19:12:22 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1536952342.64.0.956365154283.issue24937@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +8743

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:18:05 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Sep 2018 19:18:05 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1536952685.3.0.956365154283.issue3468@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests:  -8741

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:30:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:30:38 +0000
Subject: [issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop
In-Reply-To: <1421883613.58.0.0395481360088.issue23295@psf.upfronthosting.co.za>
Message-ID: <1536953438.04.0.956365154283.issue23295@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Duplicate of bpo-29883.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> asyncio: Windows Proactor Event Loop UDP Support

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23295>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:30:40 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Fri, 14 Sep 2018 19:30:40 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1536953440.42.0.956365154283.issue34686@psf.upfronthosting.co.za>


Erwan Le Pape <lepaperwan3 at gmail.com> added the comment:

How would you suggest going about doing that?

Without the proposed option, the alternative is leaving the build process vulnerable to environment variables potentially breaking the build process by patching configure.ac as follows:
-PYTHON_FOR_BUILD='./$(BUILDPYTHON) -E'
+PYTHON_FOR_BUILD='PYTHONHASHSEED=0 ./$(BUILDPYTHON) -E'

Otherwise all environment variables affecting the Python interpreter would need to be cleared in addition to setting PYTHONHASHSEED=0.

Without these `hacks`, making build outputs to be deterministic means fixing marshal to essentially sort elements when dumping unordered objects. Would you rather see a patch going in that direction?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:31:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:31:26 +0000
Subject: [issue29883] asyncio: Windows Proactor Event Loop UDP Support
In-Reply-To: <1490210881.18.0.553215827239.issue29883@psf.upfronthosting.co.za>
Message-ID: <1536953486.93.0.956365154283.issue29883@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I just marked my old issue bpo-23295 as duplicate of this one. Copy of my messages:

"""
ProactorEventLoop lacks UDP support: create_datagram_endpoint() is not supported.

New functions should be added to the _overlapped modul. Example: add maybe WSARecvFrom()?

See also https://code.google.com/p/tulip/issues/detail?id=187
"""

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29883>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:32:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:32:20 +0000
Subject: [issue29883] asyncio: Windows Proactor Event Loop UDP Support
In-Reply-To: <1490210881.18.0.553215827239.issue29883@psf.upfronthosting.co.za>
Message-ID: <1536953540.59.0.956365154283.issue29883@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Copy of my messages in July 2014:
https://github.com/python/asyncio/issues/187

"""
ProcatorEventLoop doesn't support UDP right now.

I'm working on a patch. I need to implement WSARecvFrom in the _overlapped module for example.

ConnectEx() fails with an error 10022 when create_datagram_endpoint() is called with remote_address. A workaround is to replace "yield from sock_connect(sock, remote_address)" with "sock.connect(remote_address)".
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29883>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:33:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:33:01 +0000
Subject: [issue29883] asyncio: Windows Proactor Event Loop UDP Support
In-Reply-To: <1490210881.18.0.553215827239.issue29883@psf.upfronthosting.co.za>
Message-ID: <1536953581.51.0.956365154283.issue29883@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Adam Meily: Thanks for the proposed pull request. Would you mind to try to rebase it on the current master branch, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29883>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:33:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:33:25 +0000
Subject: [issue31922] Can't receive replies from multicast UDP with asyncio
In-Reply-To: <1509619876.25.0.213398074469.issue31922@psf.upfronthosting.co.za>
Message-ID: <1536953605.84.0.956365154283.issue31922@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31922>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:35:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:35:18 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
Message-ID: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Is it time to make ProactorEventLoop as the default event loop?

Since 2014, many features have been added to ProactorEventLoop (ex: SSL support) and the implementation is way more today than it was 4 years ago.

Comparison of SelectorEventLoop and ProactorEventLoop on Windows:
https://docs.python.org/dev/library/asyncio-platforms.html#windows

----------
components: asyncio
messages: 325391
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: is it time to make ProactorEventLoop as the default event loop?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Fri Sep 14 15:52:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 19:52:30 +0000
Subject: [issue34688] Segfault in pandas that works fine on 3.7
Message-ID: <1536954749.8.0.956365154283.issue34688@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I have tried running pandas test suite under Python 3.8 and the below code segfault as part of the test suite. Pandas uses Python 3.7 in Travis and it runs fine. There is also NumPy related code in the trace but it also seems to run fine under Python 3.7. I suppose this is a crash in CPython master and I didn't try latest Python 3.7 branch yet. Attaching the sample program and stack trace as below : 

# Program 

from pandas import DataFrame
import pandas as pd

df = DataFrame({'A': [1, 2, 3],
                'B': [1., 2., 3.],
                'C': ['foo', 'bar', 'baz'],
                'D': pd.date_range('20130101', periods=3)})

print(df.agg('sum'))

# Python 3.7 output

$ virtualenv -p /usr/bin/python3.7 py-37-venv
$ source py-37-venv/bin/activate
$ python
Python 3.7.0 (default, Jun 28 2018, 02:32:19)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

$ pip install pandas

$ python foo.py
A            6
B            6
C    foobarbaz
dtype: object


# Crash on Python 3.8 (CPython master)

$ ./python -m venv ../pandas-venv
$ cd ../ && source pandas-venv/bin/activate
$ python
Python 3.8.0a0 (heads/master:73820a6, Sep 14 2018, 18:33:26)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ pip install pandas
$ python foo.py
<frozen importlib._bootstrap>:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
/home/karthi/pandas/pandas/core/dtypes/inference.py:6: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import Iterable
/home/karthi/pandas/pandas/core/tools/datetimes.py:3: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import MutableMapping
python: Objects/call.c:90: _PyObject_FastCallDict: Assertion `!PyErr_Occurred()' failed.


# Stack trace

$ gdb --args python foo.py
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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 "x86_64-linux-gnu".
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...done.
warning: File "/home/karthi/cpython/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /home/karthi/cpython/python-gdb.py
line to your configuration file "/home/karthi/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/karthi/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb)
(gdb) set pagination off
(gdb) r
Starting program: /home/karthi/pandas-venv/bin/python foo.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
<frozen importlib._bootstrap>:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
/home/karthi/pandas/pandas/core/dtypes/inference.py:6: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import Iterable
/home/karthi/pandas/pandas/core/tools/datetimes.py:3: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import MutableMapping
python: Objects/call.c:90: _PyObject_FastCallDict: Assertion `!PyErr_Occurred()' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff7115428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7115428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff711702a in __GI_abort () at abort.c:89
#2  0x00007ffff710dbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion at entry=0x5fa699 "!PyErr_Occurred()", file=file at entry=0x5fa650 "Objects/call.c", line=line at entry=90, function=function at entry=0x5fade0 <__PRETTY_FUNCTION__.13021> "_PyObject_FastCallDict") at assert.c:92
#3  0x00007ffff710dc82 in __GI___assert_fail (assertion=assertion at entry=0x5fa699 "!PyErr_Occurred()", file=file at entry=0x5fa650 "Objects/call.c", line=line at entry=90, function=function at entry=0x5fade0 <__PRETTY_FUNCTION__.13021> "_PyObject_FastCallDict") at assert.c:101
#4  0x0000000000432229 in _PyObject_FastCallDict (callable=callable at entry=0x7fffe8f33350, args=0x7fffffffba90, nargs=nargs at entry=1, kwargs=kwargs at entry=0x0) at Objects/call.c:90
#5  0x0000000000479dcd in call_unbound (unbound=<optimized out>, func=func at entry=0x7fffe8f33350, self=self at entry=0x7fffe8f284e8, args=args at entry=0x7fffffffba90, nargs=nargs at entry=1) at Objects/typeobject.c:1484
#6  0x0000000000483783 in call_maybe (obj=obj at entry=0x7fffe8f284e8, name=name at entry=0x8cf800 <op_id>, args=args at entry=0x7fffffffba90, nargs=nargs at entry=1) at Objects/typeobject.c:1534
#7  0x00000000004851d2 in slot_nb_add (self=0x7fffe8f284e8, other=0x7fffe8f28638) at Objects/typeobject.c:6167
#8  0x00000000005a47cc in binary_op1 (v=v at entry=0x7fffe8f284e8, w=w at entry=0x7fffe8f28638, op_slot=op_slot at entry=0) at Objects/abstract.c:804
#9  0x00000000005a5d2c in PyNumber_Add (v=0x7fffe8f284e8, w=0x7fffe8f28638) at Objects/abstract.c:954
#10 0x00007ffff61db5bb in PyUFunc_OO_O (args=<optimized out>, dimensions=<optimized out>, steps=<optimized out>, func=0x5a5d18 <PyNumber_Add>) at numpy/core/src/umath/loops.c.src:592
#11 0x00007ffff6332c24 in reduce_loop (iter=0x1295500, dataptrs=dataptrs at entry=0x12955e0, strides=strides at entry=0x12955d0, countptr=0x12955a8, iternext=iternext at entry=0x7ffff6971611 <npyiter_buffered_reduce_iternext_iters2>, needs_api=1, skip_first_count=<optimized out>, data=0x994fa0) at numpy/core/src/umath/ufunc_object.c:3263
#12 0x00007ffff61d00c5 in PyUFunc_ReduceWrapper (operand=operand at entry=0x7fffe8f16bc0, out=out at entry=0x0, wheremask=wheremask at entry=0x0, operand_dtype=<optimized out>, result_dtype=<optimized out>, casting=casting at entry=NPY_UNSAFE_CASTING, axis_flags=0x7fffffffbda0 "\001", reorderable=1, keepdims=0, subok=0, identity=0x8cb3c0 <_Py_NoneStruct>, loop=0x7ffff6332a23 <reduce_loop>, data=0x994fa0, buffersize=8192, funcname=0x7ffff6375457 "add", errormask=9) at numpy/core/src/umath/reduction.c:567
#13 0x00007ffff633a8a4 in PyUFunc_Reduce (ufunc=ufunc at entry=0x994fa0, arr=arr at entry=0x7fffe8f16bc0, out=0x0, naxes=naxes at entry=1, axes=axes at entry=0x7fffffffbe90, odtype=0x7ffff6c2c1a0 <OBJECT_Descr>, keepdims=0, initial=0x8cb3c0 <_Py_NoneStruct>) at numpy/core/src/umath/ufunc_object.c:3359
#14 0x00007ffff633c9fd in PyUFunc_GenericReduction (ufunc=ufunc at entry=0x994fa0, args=args at entry=0x7ffff6ec62f8, kwds=kwds at entry=0x0, operation=operation at entry=0) at numpy/core/src/umath/ufunc_object.c:4333
#15 0x00007ffff633cef7 in ufunc_reduce (ufunc=ufunc at entry=0x994fa0, args=args at entry=0x7ffff6ec62f8, kwds=kwds at entry=0x0) at numpy/core/src/umath/ufunc_object.c:5251
#16 0x00000000004315cd in _PyMethodDef_RawFastCallKeywords (method=0x7ffff65ba380 <ufunc_methods>, self=0x994fa0, args=args at entry=0x12953e0, nargs=nargs at entry=6, kwnames=<optimized out>) at Objects/call.c:690
#17 0x000000000043175a in _PyCFunction_FastCallKeywords (func=func at entry=0x7ffff5747980, args=args at entry=0x12953e0, nargs=nargs at entry=6, kwnames=kwnames at entry=0x0) at Objects/call.c:730
#18 0x00000000004eaccf in call_function (kwnames=0x0, oparg=6, pp_stack=<synthetic pointer>) at Python/ceval.c:4575
#19 _PyEval_EvalFrameDefault (f=0x1295230, throwflag=<optimized out>) at Python/ceval.c:3200
#20 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1295230, throwflag=throwflag at entry=0) at Python/ceval.c:536
#21 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7ffff5755dc0, globals=globals at entry=0x7ffff5756d00, locals=locals at entry=0x0, args=args at entry=0x7fffe8f3d7c8, argcount=argcount at entry=2, kwnames=kwnames at entry=0x7fffe8f3d760, kwargs=0x7fffe8f3d768, kwcount=2, kwstep=2, defs=0x7ffff573dbf8, defcount=5, kwdefs=0x0, closure=0x0, name=0x7ffff5757c70, qualname=0x7ffff5757c70) at Python/ceval.c:3951
#22 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7ffff57583c0, args=args at entry=0x7fffe8f3d7c8, nargs=2, kwargs=kwargs at entry=0x7fffeb60e7c0) at Objects/call.c:376
#23 0x00000000004335ca in PyObject_Call (callable=callable at entry=0x7ffff57583c0, args=args at entry=0x7fffe8f3d7a0, kwargs=kwargs at entry=0x7fffeb60e7c0) at Objects/call.c:226
#24 0x00007ffff695aff8 in forward_ndarray_method (self=self at entry=0x7fffe8f16bc0, args=args at entry=0x7ffff7e9f050, kwds=kwds at entry=0x7fffeb60e7c0, forwarding_callable=0x7ffff57583c0) at numpy/core/src/multiarray/methods.c:104
#25 0x00007ffff695b0ee in array_sum (self=self at entry=0x7fffe8f16bc0, args=args at entry=0x7ffff7e9f050, kwds=kwds at entry=0x7fffeb60e7c0) at numpy/core/src/multiarray/methods.c:1991
#26 0x00000000004315cd in _PyMethodDef_RawFastCallKeywords (method=0x7ffff6c3bb00 <array_methods+1792>, self=0x7fffe8f16bc0, args=args at entry=0x1294ad8, nargs=nargs at entry=1, kwnames=<optimized out>) at Objects/call.c:690
#27 0x000000000043175a in _PyCFunction_FastCallKeywords (func=func at entry=0x7fffe8f30910, args=args at entry=0x1294ad8, nargs=nargs at entry=1, kwnames=kwnames at entry=0x7fffed36e110) at Objects/call.c:730
#28 0x00000000004eb312 in call_function (kwnames=0x7fffed36e110, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4575
#29 _PyEval_EvalFrameDefault (f=0x1294910, throwflag=<optimized out>) at Python/ceval.c:3215
#30 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1294910, throwflag=throwflag at entry=0) at Python/ceval.c:536
#31 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed36c7c0, globals=globals at entry=0x7fffed3dae50, locals=locals at entry=0x0, args=args at entry=0x7ffff7fa4438, argcount=argcount at entry=1, kwnames=kwnames at entry=0x7fffe8f31100, kwargs=0x7fffe8f31108, kwcount=6, kwstep=2, defs=0x7fffed3742a8, defcount=3, kwdefs=0x0, closure=0x0, name=0x7ffff34a5248, qualname=0x7ffff34a5248) at Python/ceval.c:3951
#32 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed37a310, args=args at entry=0x7ffff7fa4438, nargs=1, kwargs=kwargs at entry=0x7fffe8f24f30) at Objects/call.c:376
#33 0x00000000004335ca in PyObject_Call (callable=0x7fffed37a310, args=0x7ffff7fa4410, kwargs=0x7fffe8f24f30) at Objects/call.c:226
#34 0x00000000004dee12 in do_call_core (func=func at entry=0x7fffed37a310, callargs=callargs at entry=0x7ffff7fa4410, kwdict=kwdict at entry=0x7fffe8f24f30) at Python/ceval.c:4652
#35 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x12946b0, throwflag=<optimized out>) at Python/ceval.c:3267
#36 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x12946b0, throwflag=throwflag at entry=0) at Python/ceval.c:536
#37 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed3657c0, globals=globals at entry=0x7fffed3dae50, locals=locals at entry=0x0, args=args at entry=0x7ffff6eb1f18, argcount=argcount at entry=1, kwnames=kwnames at entry=0x7fffe8f31078, kwargs=0x7fffe8f31080, kwcount=6, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x7fffed378120, name=0x7ffff34a5248, qualname=0x7ffff34a5248) at Python/ceval.c:3951
#38 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed37a3c0, args=args at entry=0x7ffff6eb1f18, nargs=1, kwargs=kwargs at entry=0x7fffe9e5d750) at Objects/call.c:376
#39 0x00000000004335ca in PyObject_Call (callable=0x7fffed37a3c0, args=0x7ffff6eb1ef0, kwargs=0x7fffe9e5d750) at Objects/call.c:226
#40 0x00000000004dee12 in do_call_core (func=func at entry=0x7fffed37a3c0, callargs=callargs at entry=0x7ffff6eb1ef0, kwdict=kwdict at entry=0x7fffe9e5d750) at Python/ceval.c:4652
#41 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x7fffe8f40850, throwflag=<optimized out>) at Python/ceval.c:3267
#42 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x7fffe8f40850, throwflag=throwflag at entry=0) at Python/ceval.c:536
#43 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7fffeb0df7c0, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x1293920, argcount=1, kwnames=0x0, kwargs=0x1293928, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x7fffe9f0b2a8, name=0x7ffff7f281e0, qualname=0x7fffeb153d40) at Python/ceval.c:3951
#44 0x00000000004310a8 in _PyFunction_FastCallKeywords (func=func at entry=0x7fffe8f32940, stack=stack at entry=0x1293920, nargs=nargs at entry=1, kwnames=kwnames at entry=0x0) at Objects/call.c:433
#45 0x00000000004eaf60 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4623
#46 _PyEval_EvalFrameDefault (f=0x12936f0, throwflag=<optimized out>) at Python/ceval.c:3200
#47 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x12936f0, throwflag=throwflag at entry=0) at Python/ceval.c:536
#48 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7fffeb0df880, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x1293410, argcount=3, kwnames=0x7fffec0834b0, kwargs=0x1293428, kwcount=4, kwstep=1, defs=0x7fffeb0deb40, defcount=4, kwdefs=0x0, closure=0x0, name=0x7fffed3b4da8, qualname=0x7fffeb0de400) at Python/ceval.c:3951
#49 0x00000000004310a8 in _PyFunction_FastCallKeywords (func=func at entry=0x7fffea4a5ec0, stack=stack at entry=0x1293410, nargs=nargs at entry=3, kwnames=kwnames at entry=0x7fffec083488) at Objects/call.c:433
#50 0x00000000004eb599 in call_function (kwnames=0x7fffec083488, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4623
#51 _PyEval_EvalFrameDefault (f=0x1293250, throwflag=<optimized out>) at Python/ceval.c:3215
#52 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1293250, throwflag=throwflag at entry=0) at Python/ceval.c:536
#53 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffec07ec40, globals=globals at entry=0x7fffec541a60, locals=locals at entry=0x0, args=args at entry=0x7fffffffd0d0, argcount=argcount at entry=1, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x7fffec0812f8, defcount=5, kwdefs=0x0, closure=0x7fffeb101738, name=0x7ffff7f83588, qualname=0x7fffea4a44a0) at Python/ceval.c:3951
#54 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffea4a6f70, args=args at entry=0x7fffffffd0d0, nargs=nargs at entry=1, kwargs=kwargs at entry=0x7fffe8f308a0) at Objects/call.c:376
#55 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffea4a6f70, args=args at entry=0x7fffffffd0d0, nargs=nargs at entry=1, kwargs=kwargs at entry=0x7fffe8f308a0) at Objects/call.c:98
#56 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffea4a6f70, obj=0x7ffff7e52890, args=0x7ffff7fa5050, kwargs=0x7fffe8f308a0) at Objects/call.c:904
#57 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#58 0x000000000043364b in PyObject_Call (callable=0x7ffff7ed4d50, args=0x7ffff7fa5050, kwargs=0x7fffe8f308a0) at Objects/call.c:245
#59 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7ed4d50, callargs=callargs at entry=0x7ffff7fa5050, kwdict=kwdict at entry=0x7fffe8f308a0) at Python/ceval.c:4652
#60 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x7fffe8f3e248, throwflag=<optimized out>) at Python/ceval.c:3267
#61 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x7fffe8f3e248, throwflag=throwflag at entry=0) at Python/ceval.c:536
#62 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed3d0400, globals=globals at entry=0x7fffed3c2750, locals=locals at entry=0x0, args=args at entry=0x7fffffffd490, argcount=argcount at entry=2, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x7fffed3c4dc0, qualname=0x7fffed3c3790) at Python/ceval.c:3951
#63 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed3883c0, args=args at entry=0x7fffffffd490, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffee1bdfa0) at Objects/call.c:376
#64 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffed3883c0, args=args at entry=0x7fffffffd490, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffee1bdfa0) at Objects/call.c:98
#65 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffed3883c0, obj=0x7ffff7e52890, args=0x7ffff6ece0b0, kwargs=0x7fffee1bdfa0) at Objects/call.c:904
#66 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#67 0x000000000043364b in PyObject_Call (callable=0x7ffff7e30258, args=0x7ffff6ece0b0, kwargs=0x7fffee1bdfa0) at Objects/call.c:245
#68 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7e30258, callargs=callargs at entry=0x7ffff6ece0b0, kwdict=kwdict at entry=0x7fffee1bdfa0) at Python/ceval.c:4652
#69 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x1292d00, throwflag=<optimized out>) at Python/ceval.c:3267
#70 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1292d00, throwflag=throwflag at entry=0) at Python/ceval.c:536
#71 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed3d0e80, globals=globals at entry=0x7fffed3c2750, locals=locals at entry=0x0, args=args at entry=0x7fffffffd850, argcount=argcount at entry=2, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x7fffed3cff90, qualname=0x7fffed3d61c0) at Python/ceval.c:3951
#72 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed388470, args=args at entry=0x7fffffffd850, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffe8f30830) at Objects/call.c:376
#73 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffed388470, args=args at entry=0x7fffffffd850, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffe8f30830) at Objects/call.c:98
#74 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffed388470, obj=0x7ffff7e52890, args=0x7ffff7e52ef0, kwargs=0x7fffe8f30830) at Objects/call.c:904
#75 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#76 0x000000000043364b in PyObject_Call (callable=0x7ffff7f532c0, args=0x7ffff7e52ef0, kwargs=0x7fffe8f30830) at Objects/call.c:245
#77 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7f532c0, callargs=callargs at entry=0x7ffff7e52ef0, kwdict=kwdict at entry=0x7fffe8f30830) at Python/ceval.c:4652
#78 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x1292ad0, throwflag=<optimized out>) at Python/ceval.c:3267
#79 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1292ad0, throwflag=throwflag at entry=0) at Python/ceval.c:536
#80 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffeb159880, globals=globals at entry=0x7fffec541f30, locals=locals at entry=0x0, args=args at entry=0x7fffffffdc10, argcount=argcount at entry=2, kwnames=kwnames at entry=0x7ffff6ed4690, kwargs=0x7ffff6ed4698, kwcount=2, kwstep=2, defs=0x7fffeb0e60d8, defcount=1, kwdefs=0x0, closure=0x7fffeb0f0890, name=0x7fffed3cff90, qualname=0x7fffeb157b80) at Python/ceval.c:3951
#81 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffea4a5520, args=args at entry=0x7fffffffdc10, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7ffff6ed26e0) at Objects/call.c:376
#82 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffea4a5520, args=args at entry=0x7fffffffdc10, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7ffff6ed26e0) at Objects/call.c:98
#83 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffea4a5520, obj=0x7ffff7e52890, args=0x7ffff7e97fb0, kwargs=0x7ffff6ed26e0) at Objects/call.c:904
#84 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#85 0x000000000043364b in PyObject_Call (callable=0x7ffff7f3fce8, args=0x7ffff7e97fb0, kwargs=0x7ffff6ed26e0) at Objects/call.c:245
#86 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7f3fce8, callargs=callargs at entry=0x7ffff7e97fb0, kwdict=kwdict at entry=0x7ffff6ed26e0) at Python/ceval.c:4652
#87 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x1292880, throwflag=<optimized out>) at Python/ceval.c:3267
#88 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1292880, throwflag=throwflag at entry=0) at Python/ceval.c:536
#89 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7fffeb1597c0, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x9a7c90, argcount=2, kwnames=0x0, kwargs=0x9a7ca0, kwcount=0, kwstep=1, defs=0x7fffeb0e6078, defcount=1, kwdefs=0x0, closure=0x0, name=0x7fffed3cf510, qualname=0x7fffeb157a90) at Python/ceval.c:3951
#90 0x00000000004310a8 in _PyFunction_FastCallKeywords (func=func at entry=0x7fffea4a5470, stack=stack at entry=0x9a7c90, nargs=nargs at entry=2, kwnames=kwnames at entry=0x0) at Objects/call.c:433
#91 0x00000000004ea4f5 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4623
#92 _PyEval_EvalFrameDefault (f=0x9a7b10, throwflag=<optimized out>) at Python/ceval.c:3169
#93 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x9a7b10, throwflag=throwflag at entry=0) at Python/ceval.c:536
#94 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7ffff7e9a640, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=argcount at entry=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:3951
#95 0x00000000004e09a4 in PyEval_EvalCodeEx (_co=_co at entry=0x7ffff7e9a640, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3980
#96 0x00000000004e09cd in PyEval_EvalCode (co=co at entry=0x7ffff7e9a640, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0) at Python/ceval.c:513
#97 0x0000000000521840 in run_mod (mod=mod at entry=0x9bc540, filename=filename at entry=0x7ffff6ed4110, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0, flags=flags at entry=0x7fffffffe360, arena=arena at entry=0x7ffff7e88040) at Python/pythonrun.c:1031
#98 0x000000000052448a in PyRun_FileExFlags (fp=fp at entry=0x9ba2e0, filename_str=filename_str at entry=0x7ffff7e983e0 "foo.py", start=start at entry=257, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0, closeit=closeit at entry=1, flags=0x7fffffffe360) at Python/pythonrun.c:984
#99 0x000000000052481f in PyRun_SimpleFileExFlags (fp=fp at entry=0x9ba2e0, filename=<optimized out>, filename at entry=0x7ffff7e983e0 "foo.py", closeit=closeit at entry=1, flags=flags at entry=0x7fffffffe360) at Python/pythonrun.c:425
#100 0x00000000005249db in PyRun_AnyFileExFlags (fp=fp at entry=0x9ba2e0, filename=0x7ffff7e983e0 "foo.py", closeit=closeit at entry=1, flags=flags at entry=0x7fffffffe360) at Python/pythonrun.c:84
#101 0x0000000000420c3b in pymain_run_file (pymain=pymain at entry=0x7fffffffe3c0, config=config at entry=0x9483a8, cf=cf at entry=0x7fffffffe360) at Modules/main.c:1159
#102 0x0000000000421146 in pymain_run_python (pymain=pymain at entry=0x7fffffffe3c0, interp=0x948320) at Modules/main.c:1607
#103 0x0000000000422da0 in pymain_main (pymain=pymain at entry=0x7fffffffe3c0) at Modules/main.c:1755
#104 0x0000000000422e74 in _Py_UnixMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:1792
#105 0x000000000041f96f in main (argc=<optimized out>, argv=<optimized out>) at ./Programs/python.c:15



Thanks

----------
components: Interpreter Core
messages: 325392
nosy: xtreak
priority: normal
severity: normal
status: open
title: Segfault in pandas that works fine on 3.7
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34688>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:11:33 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Fri, 14 Sep 2018 20:11:33 +0000
Subject: [issue34689] Lib/sysconfig.py expands non-variables
Message-ID: <1536955893.22.0.956365154283.issue34689@psf.upfronthosting.co.za>


New submission from Erwan Le Pape <lepaperwan3 at gmail.com>:

Lib/sysconfig.py _parse_makefile needs to expand Makefile-style variables which includes `$()` `${}` variables with a litteral `$` being `$$`.

That last particular point is properly accounted for in the first half of the function when determining values that need expansion and those that don't. However, the second half that actually performs variable expansion doesn't.

Sample breaking input:
VAR1=  VALUE1
VAR2=  VALUE2
VAR3=$${VAR1} ${VAR2}

Output:
Expect: {'VAR1': 'VALUE1', 'VAR2': 'VALUE2', 'VAR3': '$${VAR1} VALUE2'}
Actual: {'VAR1': 'VALUE1', 'VAR2': 'VALUE2', 'VAR3': '$VALUE1 VALUE2'}

I'm working on patching this but I'm putting this here as feedback is welcome.

As far as I could tell, this is a side effect of b2b1217, which patched #24705.

----------
components: Library (Lib)
messages: 325393
nosy: lepaperwan
priority: normal
severity: normal
status: open
title: Lib/sysconfig.py expands non-variables
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/issue34689>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:13:31 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 20:13:31 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1536956011.16.0.956365154283.issue34687@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'm not sure that ProactorEventLoop is stable enough TBH :(  And I wouldn't be able to be on call for Windows users to fix all bugs in ProactieEventLoop.

Andrew, your thoughts on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:28:25 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Sep 2018 20:28:25 +0000
Subject: [issue34643] How to build Release Version of Python in Windows?
In-Reply-To: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>
Message-ID: <1536956905.0.0.956365154283.issue34643@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

In that case, you are asking for a new feature development that we have previously decided is not in the best interests for us to provide (in that it leads to more upgrade and installation issues than a more controlled installer). If you are prepared to write and contribute scripts that do this, we can consider them against this bpo item, but if not then I suggest we close this as rejected.

In either case, we would not be offering this package on python.org.

---

There is no difference between the Python binaries. The difference is that the installer ensures they are properly integrated with Windows in a way that makes them easier to use, safer to update, and protects against conflicts between multiple copies. Apart from these, they can simply be copied around.

If the context for your question is that you know that you can't do this on other platforms, then my answer is that Windows always searches for dynamic libraries when loading them, rather than embedding an absolute path during build. So you can *only* create relocatable binaries, provided you also include all the dependencies (and it is not always obvious what these are).

Does that help?

----------
type: compile error -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34643>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:32:12 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 20:32:12 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536957132.91.0.956365154283.issue33649@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 3faaa8857a42a36383bb18425444e597fc876797 by Carol Willing (Yury Selivanov) in branch 'master':
bpo-33649: Refresh Tasks and Futures pages (#9314)
https://github.com/python/cpython/commit/3faaa8857a42a36383bb18425444e597fc876797


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:50:26 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 20:50:26 +0000
Subject: [issue31577] crash in os.utime() in case of a bad ns argument
In-Reply-To: <1506358077.62.0.262986415269.issue31577@psf.upfronthosting.co.za>
Message-ID: <1536958226.56.0.956365154283.issue31577@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Serhiy has opened bpo-34676 for the idea of restricting PyNumber_Divmod()'s return type, so I'm closing the issue.

----------
stage: commit review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31577>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:55:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 20:55:44 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536958544.04.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8744

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:57:28 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 20:57:28 +0000
Subject: [issue34676] Guarantee that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1536958648.8.0.956365154283.issue34676@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I share Paul's concern about somebody using this (mis-?)feature and being unnecessarily broken.  However, such a restriction would have prevented the segfault that was reported and fixed in bpo-31577, and would save any other users of PyNumber_Divmod from having to implement the same kind of checks.

Does anyone have an example of a legitimate use for the current behavior?

----------
nosy: +zach.ware
title: Guarantie that divmod() and PyNumber_Divmod() return a 2-tuple -> Guarantee that divmod() and PyNumber_Divmod() return a 2-tuple

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Fri Sep 14 16:58:02 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 20:58:02 +0000
Subject: [issue34354] Memory leak on _testCongestion
In-Reply-To: <1533705661.31.0.56676864532.issue34354@psf.upfronthosting.co.za>
Message-ID: <1536958682.22.0.956365154283.issue34354@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

That issue has more information/discussion, and it does look like the same bug, so I'll close this one.

Thank you for reporting it!

----------
nosy: +petr.viktorin
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_socket: testCongestion() hangs on my Fedora 28

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34354>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:17:31 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 14 Sep 2018 21:17:31 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1536959851.14.0.956365154283.issue34651@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 5903296045b586b9cd1fce0b1e02caf896028d1d by Eric Snow in branch 'master':
bpo-34651: Only allow the main interpreter to fork. (gh-9279)
https://github.com/python/cpython/commit/5903296045b586b9cd1fce0b1e02caf896028d1d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:18:10 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 14 Sep 2018 21:18:10 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1536959890.6.0.956365154283.issue34651@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:23:50 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Sep 2018 21:23:50 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
Message-ID: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

This patch was sent to me privately by Jeethu Rao at Facebook.  It's a change they're working with internally to improve startup time.  What I've been told by Carl Shapiro at Facebook is that we have their blessing to post it publicly / merge it / build upon it for CPython.  Their patch was written for 3.6, I have massaged it to the point where it minimally works with 3.8.

What the patch does: it takes all the Python modules that are loaded as part of interpreter startup and deserializes the marshalled .pyc file into precreated objects stored as static C data.  You add this .C file to the Python build.  Then there's a patch to Python itself (about 250 lines iirc) that teaches it to load modules from these data structures.

I wrote a quick dumb test harness to compare this patch vs 3.8 stock.  It runs a command line 500 times and uses time.perf_counter to time the process.  On a fast quiescent laptop I observe a 21-22% improvement:

cmdline: ['./python', '-c', 'pass']
500 runs:

sm38
  average time 0.006302303705982922
          best 0.006055746000129147
         worst 0.00816565500008437

clean38
  average time 0.007969956444008858
          best 0.007829047999621253
         worst 0.008812210000542109

improvement 0.20924239043734505 %

cmdline: ['./python', '-c', 'import io']
500 runs:

sm38
  average time 0.006297688038004708
          best 0.005980765999993309
         worst 0.0072462130010535475

clean38
  average time 0.007996319670004595
          best 0.0078091849991324125
         worst 0.009175700999549008

improvement 0.21242667903482038 %


The downside of the patch: for these modules it ignores the Python files on disk--it doesn't even stat them.  If you add stat calls you lose half of the speed improvement.  I believe they added a work-around, where you can set a flag (command-line? environment variable? I don't know, I didn't go looking for it) that tells Python "don't use the frozen modules" and it loads all those files from disk.


I don't propose to merge the patch in its current state.  I think it would need a lot of work both in terms of "doing things the way Python does it" as well as just code smell (the serializer is implemented in both C and Python and jumps back and forth, also the build process for the serialized modules is pretty tiresome).

Is it worth working on?

----------
assignee: larry
components: Interpreter Core
messages: 325401
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Store startup modules as C structures for 20%+ startup speed improvement
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:25:54 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Sep 2018 21:25:54 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536960354.2.0.956365154283.issue34690@psf.upfronthosting.co.za>


Change by Larry Hastings <larry at hastings.org>:


----------
keywords: +patch
pull_requests: +8745
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:26:32 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 21:26:32 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536960392.73.0.956365154283.issue34690@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/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:27:30 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Sep 2018 21:27:30 +0000
Subject: [issue32718] Install PowerShell activation scripts for venv for all
 platforms
In-Reply-To: <1517273696.22.0.467229070634.issue32718@psf.upfronthosting.co.za>
Message-ID: <1536960450.73.0.956365154283.issue32718@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +8746
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32718>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:27:55 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 14 Sep 2018 21:27:55 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536960475.58.0.956365154283.issue34690@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:30:07 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 14 Sep 2018 21:30:07 +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: <1536960607.68.0.956365154283.issue32933@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c83c375ed907bdd54361aa36ce76130360f323a4 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-32933: Implement __iter__ method on mock_open() (GH-5974)
https://github.com/python/cpython/commit/c83c375ed907bdd54361aa36ce76130360f323a4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32933>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:31:52 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 21:31:52 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1536960712.54.0.956365154283.issue3468@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8747

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:33:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 21:33:35 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536960815.99.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8748

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:34:59 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Sep 2018 21:34:59 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536960899.82.0.956365154283.issue34690@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I should add that there were two novel test failures in the regression test suite: test_module and test_site.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:43:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 21:43:30 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1536961410.42.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I discussed with Pablo (at the CPython sprint) about the case of FreeBSD.

On FreeBSD, posix_spawn() always uses vfork, so it can be surprising to get an error when using use_vfork=True. But, the error message is now very explicit: it mentions that a specific constant is not available on FreeBSD. The documentation is also clear on that point.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:55:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 21:55:47 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
In-Reply-To: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>
Message-ID: <1536962147.8.0.956365154283.issue34685@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

We already skip similar os.sched_setparam() tests on FreeBSD, so the change is fine.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:57:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 21:57:42 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536962262.2.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 6c7316439d966cdbc76ffcc005e5d9c563064ba2 by Yury Selivanov in branch 'master':
bpo-33649: Refresh asyncio docs landing page (GH-9322)
https://github.com/python/cpython/commit/6c7316439d966cdbc76ffcc005e5d9c563064ba2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:04:17 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Sep 2018 22:04:17 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536962657.03.0.956365154283.issue34690@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

As Neil points out on python-dev, my "improvement" should have been multiplied by 100, like 20.924239043734505 % instead of 0.20924239043734505 %, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:11:27 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 22:11:27 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536963087.93.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 7372c3bbefb4763dbd1b6d66f7971bef28c0f056 by Yury Selivanov in branch 'master':
bpo-33649: Add high-level APIs cheat-sheet (GH-9319)
https://github.com/python/cpython/commit/7372c3bbefb4763dbd1b6d66f7971bef28c0f056


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:12:26 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 22:12:26 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
In-Reply-To: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>
Message-ID: <1536963146.17.0.956365154283.issue34685@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 3d18b50a12e639e018d49d7b85663164d60bfd2b by Pablo Galindo in branch 'master':
bpo-34685: Skip posix_spawn scheduler tests on BSD (GH-9316)
https://github.com/python/cpython/commit/3d18b50a12e639e018d49d7b85663164d60bfd2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:27:29 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 22:27:29 +0000
Subject: [issue3468] Satisfy her lovemaking desire
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1536964049.66.0.956365154283.issue3468@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
pull_requests:  -8747

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:27:39 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 22:27:39 +0000
Subject: [issue3468] Spam
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1536964059.21.0.956365154283.issue3468@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
title: Satisfy her lovemaking desire -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:27:49 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 22:27:49 +0000
Subject: [issue3468] Spam
In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com>
Message-ID: <1536964069.35.0.956365154283.issue3468@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy:  -gpolo, gvanrossum, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3468>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:31:28 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 22:31:28 +0000
Subject: [issue24056] Better expose closure,
 generator & coroutine status of functions
In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za>
Message-ID: <1536964288.98.0.956365154283.issue24056@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy:  -petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24056>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:37:47 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 14 Sep 2018 22:37:47 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536964667.43.0.956365154283.issue34690@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I commented on python-dev but maybe it is better to keep discussion here.  Could we make the frozenmodules thing into a dynamically loaded module?  Then you could have support for end users making their own.  E.g. a command-line param that lists a set of DLLs from which to load frozen modules from.  Then, if the command-line is not provided, we load from .pyc as per default.  If it is provided, we dlopen (or whatever) the DLLs and give the nice performance benefits.

Like Guido, I want to see the toolchain to build the frozenmodules thing.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:53:08 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 22:53:08 +0000
Subject: [issue33486] regen autotools related files
In-Reply-To: <1526238483.3.0.682650639539.issue33486@psf.upfronthosting.co.za>
Message-ID: <1536965588.96.0.956365154283.issue33486@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

> If these changes are autogenerated, I would prefer that a trusted core developer create a PR.

I got the same changes in configure.ac.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33486>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:55:23 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 22:55:23 +0000
Subject: [issue33486] regen autotools related files
In-Reply-To: <1526238483.3.0.682650639539.issue33486@psf.upfronthosting.co.za>
Message-ID: <1536965723.55.0.956365154283.issue33486@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 24f684692070f53b6f6e4dc67b9fe23dbd58655f by Petr Viktorin (Eitan Adler) in branch 'master':
bpo-33486: regen autotools files using autoupdate+autoreconf (GH-6853)
https://github.com/python/cpython/commit/24f684692070f53b6f6e4dc67b9fe23dbd58655f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33486>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:56:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 22:56:08 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536965768.29.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8749

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 18:56:56 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 22:56:56 +0000
Subject: [issue33486] regen autotools related files
In-Reply-To: <1526238483.3.0.682650639539.issue33486@psf.upfronthosting.co.za>
Message-ID: <1536965816.17.0.956365154283.issue33486@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33486>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:08:57 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 23:08:57 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536953440.42.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1536966529.3632630.1508695672.53377723@webmail.messagingengine.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Fri, Sep 14, 2018, at 12:30, Erwan Le Pape wrote:
> Without these `hacks`, making build outputs to be deterministic means 
> fixing marshal to essentially sort elements when dumping unordered 
> objects. Would you rather see a patch going in that direction?

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:28:11 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 23:28:11 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1536967691.01.0.956365154283.issue8450@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ee78ba2c819b0cd7671a575e584d8fe1b7adb3e4 by Miss Islington (bot) (Shoham Peller) in branch '2.7':
[2.7] closes bpo-8450: a better error message when http status line isn't received (GH-2825)
https://github.com/python/cpython/commit/ee78ba2c819b0cd7671a575e584d8fe1b7adb3e4


----------
nosy: +miss-islington
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8450>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:43:26 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 14 Sep 2018 23:43:26 +0000
Subject: [issue34632] Port importlib_metadata to Python 3.8
In-Reply-To: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za>
Message-ID: <1536968606.57.0.956365154283.issue34632@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
keywords: +patch
pull_requests: +8750
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34632>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:47:23 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 14 Sep 2018 23:47:23 +0000
Subject: [issue34672] '%Z' strftime specifier never works with musl
In-Reply-To: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>
Message-ID: <1536968843.91.0.956365154283.issue34672@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34672>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:56:55 2018
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 14 Sep 2018 23:56:55 +0000
Subject: [issue20215] socketserver.TCPServer can not listen IPv6 address
In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>
Message-ID: <1536969415.39.0.956365154283.issue20215@psf.upfronthosting.co.za>


Change by Nir Soffer <nirsof at gmail.com>:


----------
nosy: +nirs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20215>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:57:18 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 23:57:18 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536969438.49.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 805e27eff65d51f7aea2c00ccbb4f5d44f4499f2 by Yury Selivanov in branch 'master':
bpo-33649: Fix asyncio-dev (GH-9324)
https://github.com/python/cpython/commit/805e27eff65d51f7aea2c00ccbb4f5d44f4499f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 14 19:58:44 2018
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 14 Sep 2018 23:58:44 +0000
Subject: [issue20215] socketserver.TCPServer can not listen IPv6 address
In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>
Message-ID: <1536969524.92.0.956365154283.issue20215@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Doesn't it affect also 2.7, 3.6, 3.7, and 3.8?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20215>
_______________________________________

From report at bugs.python.org  Fri Sep 14 21:42:24 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Sat, 15 Sep 2018 01:42:24 +0000
Subject: [issue34596] [unittest] raise error if @skip is used with an argument
 that looks like a test method
In-Reply-To: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>
Message-ID: <1536975744.3.0.956365154283.issue34596@psf.upfronthosting.co.za>


Naitree Zhu <naitreey at gmail.com> added the comment:

Hi guys, what's our consensus on this?

- raise an exception as a fix? or
- fallback to default `reason` as a new feature?

If we choose to explicitly make `reason` optional (I mean by documenting it as such), shouldn't we also change `@skipIf` and `@skipUnless` to keep consistency?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34596>
_______________________________________

From report at bugs.python.org  Fri Sep 14 22:31:59 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Sep 2018 02:31:59 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1536978719.02.0.956365154283.issue34663@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Given the FreeBSD default and seeming desirability of vfork for this use case, is there a good reason using vfork could not be the default behavior on any OS that supports it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Fri Sep 14 23:03:02 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 15 Sep 2018 03:03:02 +0000
Subject: [issue34691] _contextvars missing in x64 master branch Windows build?
Message-ID: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>


New submission from Tim Peters <tim at python.org>:

Using Visual Studio 2017 to build the current master branch of Python (something I'm trying for the first time in about two years - maybe I'm missing something obvious!), with the x64 target, under both the Release and Debug builds I get a Python that can't even start to run the test suite.  Here's output from the Release build - the Debug build output is nearly identical.  The problem does not appear with the Win32 target.  Of course I'm doing this on a 64-bit box (under Win 10 Pro):

C:\Code\Python\PCbuild>rt -q -x64

C:\Code\Python\PCbuild>"C:\Code\Python\PCbuild\amd64\python.exe"  -u -Wd -E -bb -m test
Traceback (most recent call last):
  File "C:\Code\Python\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Code\Python\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Code\Python\lib\test\__main__.py", line 1, in <module>
    from test.libregrtest import main
  File "C:\Code\Python\lib\test\libregrtest\__init__.py", line 4, in <module>
    from test.libregrtest.cmdline import _parse_args, RESOURCE_NAMES, ALL_RESOURCES
  File "C:\Code\Python\lib\test\libregrtest\cmdline.py", line 4, in <module>
    from test import support
  File "C:\Code\Python\lib\test\support\__init__.py", line 6, in <module>
    import asyncio.events
  File "C:\Code\Python\lib\asyncio\__init__.py", line 8, in <module>
    from .base_events import *
  File "C:\Code\Python\lib\asyncio\base_events.py", line 39, in <module>
    from . import events
  File "C:\Code\Python\lib\asyncio\events.py", line 14, in <module>
    import contextvars
  File "C:\Code\Python\lib\contextvars.py", line 1, in <module>
    from _contextvars import Context, ContextVar, Token, copy_context
ModuleNotFoundError: No module named '_contextvars'


_contextvarsmodule.c is in the list of Modules under the pythoncore project, and it appears to compile without incident when the Solution is built.

The executable appears to be fine in other respects I checked; e.g.,

C:\Code\Python\PCbuild>amd64\python.exe
Python 3.8.0a0 (heads/master:24f6846920, Sep 14 2018, 18:55:33) [MSC v.1915 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> from collections import Counter
>>> Counter("abab")
Counter({'a': 2, 'b': 2})
>>> import _contextvars
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named '_contextvars'

Clue?

----------
components: Build, Library (Lib), Windows
messages: 325419
nosy: paul.moore, steve.dower, tim.golden, tim.peters, zach.ware
priority: normal
severity: normal
status: open
title: _contextvars missing in x64 master branch Windows build?
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Fri Sep 14 23:05:05 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 15 Sep 2018 03:05:05 +0000
Subject: [issue29577] Enum: mixin classes don't mix well with already mixed
 Enums
In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za>
Message-ID: <1536980705.08.0.956365154283.issue29577@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +8751
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29577>
_______________________________________

From report at bugs.python.org  Fri Sep 14 23:21:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Sep 2018 03:21:34 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1536981694.29.0.956365154283.issue34690@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Sep 14 23:43:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Sep 2018 03:43:58 +0000
Subject: [issue34688] Segfault in pandas that works fine on 3.7
In-Reply-To: <1536954749.8.0.956365154283.issue34688@psf.upfronthosting.co.za>
Message-ID: <1536983038.96.0.956365154283.issue34688@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Copying my GitHub comment here : 

If I have only D or no D then there is no segfault. It occurs when I have either A, D or B, D, or C, D.

**Leaving out column D**

```python
from pandas import DataFrame
import pandas as pd

df = DataFrame({'A': [1, 2, 3],
                'B': [1., 2., 3.],
                'C': ['foo', 'bar', 'baz'],
                #'D': pd.date_range('20130101', periods=3)
})

print(df.agg('sum'))
```

**output**

```
A            6
B            6
C    foobarbaz
dtype: object
```

**Only with Column D**

```python
from pandas import DataFrame
import pandas as pd

df = DataFrame({'D': pd.date_range('20130101', periods=3)})

print(df.agg('sum'))
```

**output**

```
Series([], dtype: float64)
```

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34688>
_______________________________________

From report at bugs.python.org  Sat Sep 15 00:21:41 2018
From: report at bugs.python.org (Jordan Chapman)
Date: Sat, 15 Sep 2018 04:21:41 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1536985301.66.0.956365154283.issue32117@psf.upfronthosting.co.za>


Jordan Chapman <jchapman134569 at gmail.com> added the comment:

BFDL approval: https://mail.python.org/pipermail/python-dev/2017-November/150842.html

----------
nosy: +Jordan Chapman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Sat Sep 15 00:37:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 04:37:09 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1536986229.69.0.956365154283.issue34663@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If vfork() is used ob FreeBSD, wouldn't be better to make use_vfork=True the default on FreeBSD and raise an error on use_vfork=False?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Sat Sep 15 00:53:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 04:53:52 +0000
Subject: [issue34676] Guarantee that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1536987232.74.0.956365154283.issue34676@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

An alternate idea: convert the result of __divmod__ and __rdivmod__ to tuple instead raising an error. This will support the case of returning a list. I didn't implement this initially because I think this case is very unlikely occurred in real code.

Similar changes were made in past in PyMapping_Keys(). In Python 2 it just calls the keys() method and returns the result. In Python 3 it initially converted the result to list or tuple. But since the caller code often expects a list and use PyList API with the result, later PyMapping_Keys() was fixed but making it always returning a list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Sat Sep 15 01:36:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Sep 2018 05:36:05 +0000
Subject: [issue34676] Guarantee that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1536989765.51.0.956365154283.issue34676@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Sat Sep 15 02:46:39 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Sep 2018 06:46:39 +0000
Subject: [issue29341] Missing accepting path-like object in docstrings of os
 module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1536993999.28.0.956365154283.issue29341@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29341>
_______________________________________

From report at bugs.python.org  Sat Sep 15 02:59:55 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Sat, 15 Sep 2018 06:59:55 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1536994795.73.0.956365154283.issue34686@psf.upfronthosting.co.za>


Erwan Le Pape <lepaperwan3 at gmail.com> added the comment:

Great! My only concern with that is marshalling of untrusted data at runtime (I know, you shouldn't do that) can become a much more expensive operation.

Is there any internal use of marshal beyond .pycs used at runtime by the core interpreter that might be affected by such a change?

If not, it seems (to me) an acceptable modification of marshal and I'll submit a PR for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Sat Sep 15 03:14:28 2018
From: report at bugs.python.org (Andreas Lutro)
Date: Sat, 15 Sep 2018 07:14:28 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1536995668.66.0.956365154283.issue25296@psf.upfronthosting.co.za>


Andreas Lutro <anlutro at gmail.com> added the comment:

I see this has been closed, but the page on the devguide is still really hard to find. On the python IRC channel I often see questions about this and I always have a hard time finding the page with the correct information.

If I google "python version support" or "python version end of life" or "python version lifecycle" I don't arrive at that page. For some of these searches I even end up on a separate devcycle[1] page which only contains old versions of python. Compare that to PHP, where the official "supported versions" page is the top result no matter what I search for.

Nevermind the fact that the lifecycle of python versions is relevant to non-developers as well, making it un-intuitive to go to the devguide to find this information.

I really think this needs to be made part of python.org's main website, with some good SEO.

[1] https://devguide.python.org/devcycle/

----------
nosy: +Andreas Lutro

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25296>
_______________________________________

From report at bugs.python.org  Sat Sep 15 03:40:31 2018
From: report at bugs.python.org (arul)
Date: Sat, 15 Sep 2018 07:40:31 +0000
Subject: [issue34692] ok
Message-ID: <1536997231.82.0.9629360145.issue34692@psf.upfronthosting.co.za>


Change by arul <iamarulraj at gmail.com>:


----------
nosy: arulpython
priority: normal
severity: normal
status: open
title: ok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34692>
_______________________________________

From report at bugs.python.org  Sat Sep 15 03:59:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 07:59:22 +0000
Subject: [issue34692] ok
Message-ID: <1536998362.93.0.956365154283.issue34692@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34692>
_______________________________________

From report at bugs.python.org  Sat Sep 15 04:43:38 2018
From: report at bugs.python.org (arul)
Date: Sat, 15 Sep 2018 08:43:38 +0000
Subject: [issue34692] ok
In-Reply-To: <1536998362.96.0.249678724859.issue34692@psf.upfronthosting.co.za>
Message-ID: <CA+BZKbD4VPQWZzVWtcn3e39cQ928MVXJ-fqzFnN_mj18zvP1XA@mail.gmail.com>


New submission from arul <iamarulraj at gmail.com>:

resloved

On Sat, 15 Sep 2018 at 13:29, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:
>
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34692>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34692>
_______________________________________

From report at bugs.python.org  Sat Sep 15 04:46:29 2018
From: report at bugs.python.org (Christian Tismer)
Date: Sat, 15 Sep 2018 08:46:29 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537001189.7.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

> 1) If I understand correctly, this problem could be solved by
> per-class C storage? Something like PyModuleDef.m_size /
> PyModule_GetState, but for classes?

No. To obtain sizeof(PyType_Type), we simply used the Python code

    type.__basicsize__

It is a simple trick, but probably very few people know this path
to get that info. At least, for me it took way too long ;-)


> 2) Making PyType_GetSlot work for static types would not be trivial.
>  All types do have the same *basic* structure (the tp_* fields), but
> the nb_*/sq_*/etc. fields don't need to be in the same order, and
> might not exist at all. Even making it work for the tp_* fields only
> would bake in some assumptions I do want to get rid of.

That's my question. Do you want to hide the fact that some fields
are direct and others are indirect? I don't think that will ever be 
changed before Python 4.0, so why put this burden on every user, then?

I would simply give access to tp_* for all types and that's it.

> I'd like to
> understand your use case better. Do you have a specific example
> here?

Yes. I need access to PyType_Type's tp_new field.

PyType_Type is a very central structure in Python, and it really hurts
to hide every attribute away.

You can see the use of this field here:
https://github.com/pyside/pyside2-setup/blob/5.11/sources/shiboken2/libshiboken/basewrapper.cpp#L319

    // The meta type creates a new type when the Python programmer extends a wrapped C++ class.
    newfunc type_new = reinterpret_cast<newfunc>(PyType_Type.tp_new);
    SbkObjectType *newType = reinterpret_cast<SbkObjectType*>(type_new(metatype, args, kwds));
    if (!newType)
        return 0;

Not being able to use this field led to many weird workaround attempts, 
which did not really work. We tried to call this function from Python code, 
but then there are several checks which make it impossible to use.

We could maybe generate a heaptype clone of PyType_Type and grab the function
from there. But this is quite obscure and cannot be the recommended way to
get at the tp_new function?

Maybe there also is a way to avoid the use of this function all together.
But we did not want to re-implement a central function of a huge project
that we only understood good enough to change it a bit.

Maybe we approach it again. At that time, it was not even clear that we
would succeed with the limited API. Now that we know, we can try more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Sat Sep 15 05:10:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Sep 2018 09:10:09 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537002609.47.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Gregory: on Linux, it does change the behavior. The parent blocks until the child is spawned. Python should let the developer decide to opt-in.

Serhiy: IMHO it's better to make posix_spawn() as dumb as possible, a simple wrapper to the C call. use_vfork=True is currently designed for the GNU constant.

posix_spawn(use_vfork=True) raises on FreeBSD: only pass use_vfork=True on Linux.

What do you think?

The problem of changing the default is that we don't know the full list of all platforms that use vfork() by default. If we have a shoet list, how do we know if it's complete? For example, macOS doesn't say anything about vfork. Does it use it? Maybe not. Maybe yes. What if the default changes on a platform?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Sat Sep 15 05:28:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Sep 2018 09:28:35 +0000
Subject: [issue34579] test_embed.InitConfigTests fail on AIX
In-Reply-To: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>
Message-ID: <1537003715.7.0.956365154283.issue34579@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d2067318c79f66cfdabc53333715a02d5fa5ff81 by Victor Stinner (Michael Felt) in branch 'master':
bpo-34579: Fix test_embed DEFAULT_CON AIX (GH-9063)
https://github.com/python/cpython/commit/d2067318c79f66cfdabc53333715a02d5fa5ff81


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34579>
_______________________________________

From report at bugs.python.org  Sat Sep 15 07:02:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 11:02:11 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1537009331.62.0.956365154283.issue34656@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

>>> import pickletools
>>> pickletools.dis(b'\x80\x04\x95\x1d\x00\x00\x00\x00\x00\x00\x00}\x94(\x8c\x03age\x94K\x17\x8c\x03jobr\x8c\x07student\x94u.')
    0: \x80 PROTO      4
    2: \x95 FRAME      29
   11: }    EMPTY_DICT
   12: \x94 MEMOIZE    (as 0)
   13: (    MARK
   14: \x8c     SHORT_BINUNICODE 'age'
   19: \x94     MEMOIZE    (as 1)
   20: K        BININT1    23
   22: \x8c     SHORT_BINUNICODE 'job'
   27: r        LONG_BINPUT 1953695628
   32: u        SETITEMS   (MARK at 13)
   33: d    DICT       no MARK exists on stack
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pickletools.py", line 2457, in dis
    raise ValueError(errormsg)
ValueError: no MARK exists on stack

Ignore the error of unbalanced MARK. The problem code is LONG_BINPUT with the excessive large argument 1953695628. The C implementation of pickle tries to resize the the memo list to the size twice larger than this index. And here an integer overflow occurred.

This unlikely occurred in real world. The pickle needs to have more than 2**30-1 ? 10**9 memoized items for encountering this bug. It means that its size on disk and in memory should be tens or hundreds of gigabytes. Pickle is not the best format for serializing such amount of data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Sat Sep 15 07:42:56 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 15 Sep 2018 11:42:56 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1537011776.03.0.956365154283.issue25296@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

This is not being tracked in:

https://github.com/python/pythondotorg/issues/1302

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25296>
_______________________________________

From report at bugs.python.org  Sat Sep 15 09:46:30 2018
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 15 Sep 2018 13:46:30 +0000
Subject: [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1537019190.51.0.956365154283.issue20906@psf.upfronthosting.co.za>


Change by A.M. Kuchling <amk at amk.ca>:


----------
assignee: docs at python -> akuchling
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20906>
_______________________________________

From report at bugs.python.org  Sat Sep 15 09:46:48 2018
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 15 Sep 2018 13:46:48 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1537019208.37.0.956365154283.issue34484@psf.upfronthosting.co.za>


A.M. Kuchling <amk at amk.ca> added the comment:

Corrected in the unicode-howto-update branch being developed for issue #20906.

----------
assignee: docs at python -> akuchling
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34484>
_______________________________________

From report at bugs.python.org  Sat Sep 15 10:01:11 2018
From: report at bugs.python.org (John Joyce)
Date: Sat, 15 Sep 2018 14:01:11 +0000
Subject: [issue34693] PEPping distutils/core.py
Message-ID: <1537020071.95.0.956365154283.issue34693@psf.upfronthosting.co.za>


New submission from John Joyce <dangerwillrobinsondanger at gmail.com>:

In distutils/core.py ...

Line 227 is over-indented, inconsistent with the rest of the file.
Line 226 is over-indented, inconsistent with the rest of the file.

Line 114 is over-indented by 2 characters, inconsistent with the rest of the file.
        else:
            raise SystemExit("error in %s setup command: %s" % \
                  (attrs['name'], msg))


Line 113 backslash should not be needed to continue the line between brackets.

Line 102 there is an extra space before the "not" keyword.
    if 'script_args'  not in attrs:


Line 57 could use 1 more blank line above it.

Line 33 'script' is assigned but not used.

Line 32 could use 1 more blank line above it.


run_setup and setup had space before (

----------
components: Distutils
messages: 325433
nosy: dangerwillrobinsondanger, dstufft, eric.araujo
priority: normal
pull_requests: 8752
severity: normal
status: open
title: PEPping distutils/core.py
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34693>
_______________________________________

From report at bugs.python.org  Sat Sep 15 10:29:04 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Sat, 15 Sep 2018 14:29:04 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537021744.82.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Bumsik Kim <kbumsik at gmail.com>:


----------
pull_requests: +8753

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Sat Sep 15 10:50:44 2018
From: report at bugs.python.org (Jose Angel Acosta)
Date: Sat, 15 Sep 2018 14:50:44 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
Message-ID: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>


New submission from Jose Angel Acosta <acostaja at gmail.com>:

A request have been srecentrly uddenly committed to avoid Slave/Master wording in python code, I think the "issue"was not enough peer-reviewed, me having slave roots from my african and jewish heritage I dont consider this matter an Issue, but the Wording Slave/Master widely used to depict component relationship is better for understanding the purpose of the component relation than the non-traditional wording schemes as Parent/Worker, specially for those being non-native English readers the change has issues on code readability specially for non-English readers.

Simple, its much easier to understand the meaning of Slave/Master relationship in device functionality than Worker/Helper, I consider the whole issue as an intrusion of the "politically correct" puritanism in areas where is not required.

The main force behind Python success is CODE READABILITY, not  political rightfulness, this should be stopped here,Python itself the language name its an word which remembers snakes a creature considered impure by both Jew/Islamic/Christian religions, by appling the same political rightfulness code to this, Python language should be renamed to something non-offensive to Jew/Islamic/Christians as Bunny, (and this at least doesnt affect language readbility, since "run bunny code" vs "run python code" its easier to understand than "Process Master delegate X Data to Slave process" vs "Parent process Delegate X Data to Worker Process", the later meaning is not as easy to understand, since Parent can be translated in N ways across different languages, I.E. Spanish: Parent could means mother, father, cause while Worker just means Worker (not intrinsically related to cause or mother).

I think the python language should be kept from explicitly offensive wordings not those "niche" offensive wordings when the whole language is named after an animal that is offensive on most cultures (And its not a problem), the same naming process slave/master doesn't denote support to slavery, are just words that its more easy to understand its meaning (given its more uniform) across multiple human languages.

I consider the voting mechanism should consider polls among programmers before commit matters like this in the future, which respectfully I consider ridiculous and I said it with respect to my slave ancestors.

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
messages: 325434
nosy: AcostaJA, Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:00:53 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 15:00:53 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537023653.73.0.956365154283.issue34694@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you have any concrete propositions?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:06:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Sep 2018 15:06:05 +0000
Subject: [issue34693] PEPping distutils/core.py
In-Reply-To: <1537020071.95.0.956365154283.issue34693@psf.upfronthosting.co.za>
Message-ID: <1537023965.26.0.956365154283.issue34693@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the contribution. Is there any syntax error on using the file since you have classified it as compile error or the error messages are related to linters? On a general note style related contributions are not merged since they create whitespace noise while traversing git history. I will let it for the reviewers though to decide on this.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34693>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:07:01 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 15 Sep 2018 15:07:01 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537024021.05.0.956365154283.issue34694@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

There will be no further discussion about this.

----------
nosy: +Mariatta
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:25:37 2018
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 15 Sep 2018 15:25:37 +0000
Subject: [issue30576] http.server should support HTTP compression (gzip)
In-Reply-To: <1496691724.59.0.955308322691.issue30576@psf.upfronthosting.co.za>
Message-ID: <1537025137.05.0.956365154283.issue30576@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

Brett,

Thanks for taking the time, you and other core devs, to review the PR and to explain why you took this decision. I am disappointed by the result, but I understand the reasons, having to face the same maintenance issues, on a much smaller scale, with the project I manage (Brython, an implementation of Python for the browser).

I will follow your advice to publish the server on PyPI and cross fingers that it gains enough support to be included in a future version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30576>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:26:52 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 Sep 2018 15:26:52 +0000
Subject: [issue30140] Binary arithmetic does not always call subclasses first
In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za>
Message-ID: <1537025212.14.0.956365154283.issue30140@psf.upfronthosting.co.za>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30140>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:40:49 2018
From: report at bugs.python.org (John Joyce)
Date: Sat, 15 Sep 2018 15:40:49 +0000
Subject: [issue34693] PEPping distutils/core.py
In-Reply-To: <1537020071.95.0.956365154283.issue34693@psf.upfronthosting.co.za>
Message-ID: <1537026049.89.0.956365154283.issue34693@psf.upfronthosting.co.za>


John Joyce <dangerwillrobinsondanger at gmail.com> added the comment:

Oh, I see. I did not realize that tidying would not be accepted. That explains a lot. As it offended linters based on PEPs I chose that as the best match. It is pedantic, but many linting actions are not far from compiling... they are generally parsing to determine PEP compliance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34693>
_______________________________________

From report at bugs.python.org  Sat Sep 15 11:52:33 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 15:52:33 +0000
Subject: [issue34695] sqlite3: Cache.get() crashes if Cache.__init__() was not
 called
Message-ID: <1537026753.58.0.956365154283.issue34695@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

sqlite3.Cache allows users to create uninitialized instances because it relies on __init__() instead of __new__() for initialization, which can be skipped. Cache.get() crashes if called on an uninitialized instance:

>>> from sqlite3 import Cache
>>> Cache.__new__(Cache, None).get(42)
Segmentation fault (core dumped)

I see the following ways to fix this:

1) Explicitly check that the instance is initialized in Cache methods (this is what sqlite3 does for Connection and Cursor).

2) Move initialization from __init__() to __new__(). The latter can't be skipped due to Python safety checks. The issue here is that pysqlite_cache_init() is declared in Modules/_sqlite/cache.h, and while it's not directly called anywhere in Python sources, removing or changing it might be considered a change in public API.

3) Remove Cache from sqlite3 module dictionary. It's not clear to me why it's there because it's only used internally by Connection, is not documented, and there is no API to supply user-created Cache instances to sqlite3. Also, there are no tests for Cache.

I'll submit a PR implementing the first (most backwards-compatible) fix, but will be happy if (2), (3) or any other more reliable fixes can be considered.

----------
components: Extension Modules
messages: 325440
nosy: berker.peksag, ghaering, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sqlite3: Cache.get() crashes if Cache.__init__() was not called
type: crash
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34695>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:03:25 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 16:03:25 +0000
Subject: [issue34695] sqlite3: Cache.get() crashes if Cache.__init__() was not
 called
In-Reply-To: <1537026753.58.0.956365154283.issue34695@psf.upfronthosting.co.za>
Message-ID: <1537027405.0.0.956365154283.issue34695@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8754
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34695>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:04:32 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 15 Sep 2018 16:04:32 +0000
Subject: [issue30576] http.server should support HTTP compression (gzip)
In-Reply-To: <1537025137.05.0.956365154283.issue30576@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W743r4rgT2xkrwnCWa2Ep8+oEGL-C6VTXXKf98cd55yEw@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

Thanks for the understanding, Pierre (and thanks for the work on Brython!).

On Sat., Sep. 15, 2018, 08:25 Pierre Quentel, <report at bugs.python.org>
wrote:

>
> Pierre Quentel <pierre.quentel at gmail.com> added the comment:
>
> Brett,
>
> Thanks for taking the time, you and other core devs, to review the PR and
> to explain why you took this decision. I am disappointed by the result, but
> I understand the reasons, having to face the same maintenance issues, on a
> much smaller scale, with the project I manage (Brython, an implementation
> of Python for the browser).
>
> I will follow your advice to publish the server on PyPI and cross fingers
> that it gains enough support to be included in a future version.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue30576>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30576>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:09:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 16:09:55 +0000
Subject: [issue34695] sqlite3: Cache.get() crashes if Cache.__init__() was not
 called
In-Reply-To: <1537026753.58.0.956365154283.issue34695@psf.upfronthosting.co.za>
Message-ID: <1537027795.67.0.956365154283.issue34695@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue31734.

----------
resolution:  -> duplicate
stage: patch review -> 
superseder:  -> crash or SystemError in sqlite3.Cache in case it is uninitialized or partially initialized

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34695>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:13:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 15 Sep 2018 16:13:40 +0000
Subject: [issue34695] sqlite3: Cache.get() crashes if Cache.__init__() was not
 called
In-Reply-To: <1537026753.58.0.956365154283.issue34695@psf.upfronthosting.co.za>
Message-ID: <1537028020.53.0.956365154283.issue34695@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report and for the patch! This is a duplicate of issue 31734. The Cache class is an implementation detail and it has no use of outside of the sqlite3 implementation as you already said.

For option 3, there is an open issue: #30262. IMO, the best way to fix this issue is to make it private.

----------
stage:  -> patch review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34695>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:13:53 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 15 Sep 2018 16:13:53 +0000
Subject: [issue34695] sqlite3: Cache.get() crashes if Cache.__init__() was not
 called
In-Reply-To: <1537026753.58.0.956365154283.issue34695@psf.upfronthosting.co.za>
Message-ID: <1537028033.03.0.956365154283.issue34695@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34695>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:24:14 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 15 Sep 2018 16:24:14 +0000
Subject: [issue34696] PyByteArray_FromObject() has undocumented (and untested)
 behavior
Message-ID: <1537028654.15.0.956365154283.issue34696@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

The documentation states that PyByteArray_FromObject() creates a bytearray object from an object that implements the buffer protocol, but PyByteArray_FromObject() simply calls the bytearray constructor with its argument (the buffer protocol part is not enforced).

This was mentioned in #26759. Either the documentation or the behavior should be changed.

----------
messages: 325444
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: PyByteArray_FromObject() has undocumented (and untested) behavior
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34696>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:29:59 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 15 Sep 2018 16:29:59 +0000
Subject: [issue34696] PyByteArray_FromObject() has undocumented (and untested)
 behavior
In-Reply-To: <1537028654.15.0.956365154283.issue34696@psf.upfronthosting.co.za>
Message-ID: <1537028999.54.0.956365154283.issue34696@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8755
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34696>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:32:04 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 15 Sep 2018 16:32:04 +0000
Subject: [issue26759] PyBytes_FromObject accepts arbitrary iterable
In-Reply-To: <1460657623.47.0.29764231335.issue26759@psf.upfronthosting.co.za>
Message-ID: <1537029124.65.0.956365154283.issue26759@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

I've created #34696 for PyByteArray_FromObject().

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26759>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:36:48 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 16:36:48 +0000
Subject: [issue30262] Don't expose sqlite3 Cache and Statement
In-Reply-To: <1493841130.42.0.625787216583.issue30262@psf.upfronthosting.co.za>
Message-ID: <1537029408.67.0.956365154283.issue30262@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Some additional motivation for removing Cache: it may be used to crash the interpreter (#31734).

----------
nosy: +izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30262>
_______________________________________

From report at bugs.python.org  Sat Sep 15 12:50:34 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 15 Sep 2018 16:50:34 +0000
Subject: [issue34693] PEPping distutils/core.py
In-Reply-To: <1537020071.95.0.956365154283.issue34693@psf.upfronthosting.co.za>
Message-ID: <1537030234.85.0.956365154283.issue34693@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report and for the PR, John. Karthikeyan is correct.

Many of the modules in the stdlib predate PEP 8. Also, making PEP 8-only changes would make "git blame" less useful and can cause regressions (IIRC it has happened at least once, but I don't remember the details at the moment.)

Closing this as 'rejected'. I hope you will continue contributing to Python!

----------
nosy: +berker.peksag
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34693>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:13:13 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 17:13:13 +0000
Subject: [issue34697] ctypes: Crash if manually-created CField instance is used
Message-ID: <1537031593.26.0.956365154283.issue34697@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

It is possible to manually create an instance of private CField type which is used by ctypes to represent fields of Structure and Union types. This instance will be uninitialized because it's normally initialized when instances of Structure/Union are created, so calling its methods may crash the interpreter:

from ctypes import *

class S(Structure):
    _fields_ = [('x', c_int)]

CField = type(S.x)
f = CField()
repr(f) # Crash here

Is this issue worth fixing?

If so, is the correct way to set tp_new slot to NULL and fix the internal callers so that users wouldn't be able to create CField instances?

----------
components: ctypes
messages: 325448
nosy: amaury.forgeotdarc, belopolsky, berker.peksag, izbyshev, meador.inge, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ctypes: Crash if manually-created CField instance is used
type: crash
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34697>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:17:31 2018
From: report at bugs.python.org (Tim Burke)
Date: Sat, 15 Sep 2018 17:17:31 +0000
Subject: [issue34698] urllib.request.Request.set_proxy doesn't (necessarily)
 replace type
Message-ID: <1537031851.88.0.956365154283.issue34698@psf.upfronthosting.co.za>


New submission from Tim Burke <tim.burke at gmail.com>:

Not sure if this is a documentation or behavior bug, but... the docs for urllib.request.Request.set_proxy (https://docs.python.org/3/library/urllib.request.html#urllib.request.Request.set_proxy) say

> Prepare the request by connecting to a proxy server. *The host and type will replace those of the instance*, and the instance?s selector will be the original URL given in the constructor.

(Emphasis mine.) In practice, behavior is more nuanced than that:

>>> from urllib.request import Request
>>> req = Request('http://hostame:port/some/path')
>>> req.host, req.type
('hostame:port', 'http')
>>> req.set_proxy('proxy:other-port', 'https')
>>> req.host, req.type # So far, so good...
('proxy:other-port', 'https')
>>>
>>> req = Request('https://hostame:port/some/path')
>>> req.host, req.type
('hostame:port', 'https')
>>> req.set_proxy('proxy:other-port', 'http')
>>> req.host, req.type # Type doesn't change!
('proxy:other-port', 'https')

Looking at the source (https://github.com/python/cpython/blob/v3.7.0/Lib/urllib/request.py#L397) it's obvious why https is treated specially.

The behavior is consistent with how things worked on py2...

>>> from urllib2 import Request
>>> req = Request('http://hostame:port/some/path')
>>> req.get_host(), req.get_type()
('hostame:port', 'http')
>>> req.set_proxy('proxy:other-port', 'https')
>>> req.get_host(), req.get_type()
('proxy:other-port', 'https')
>>>
>>> req = Request('https://hostame:port/some/path')
>>> req.get_host(), req.get_type()
('hostame:port', 'https')
>>> req.set_proxy('proxy:other-port', 'http')
>>> req.get_host(), req.get_type()
('proxy:other-port', 'https')


... but only if you're actually inspecting host/type along the way!

>>> from urllib2 import Request
>>> req = Request('https://hostame:port/some/path')
>>> req.set_proxy('proxy:other-port', 'http')
>>> req.get_host(), req.get_type()
('proxy:other-port', 'http')

(FWIW, this came up while porting an application from py2 to py3; there was a unit test expecting that last behavior of proxying a https connection through a http proxy.)

----------
components: Library (Lib)
messages: 325449
nosy: tburke
priority: normal
severity: normal
status: open
title: urllib.request.Request.set_proxy doesn't (necessarily) replace type

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34698>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:24:30 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Sep 2018 17:24:30 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536994795.73.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1537032266.1986529.1509219928.0CF18418@webmail.messagingengine.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Fri, Sep 14, 2018, at 23:59, Erwan Le Pape wrote:
> 
> Erwan Le Pape <lepaperwan3 at gmail.com> added the comment:
> 
> Great! My only concern with that is marshalling of untrusted data at 
> runtime (I know, you shouldn't do that) can become a much more expensive 
> operation.
> 
> Is there any internal use of marshal beyond .pycs used at runtime by the 
> core interpreter that might be affected by such a change?

Writing pycs is the only supported use of marhsal.

> 
> If not, it seems (to me) an acceptable modification of marshal and I'll 
> submit a PR for it.

What exactly are you proposing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:32:33 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Sep 2018 17:32:33 +0000
Subject: [issue34515] lib2to3: support non-ASCII identifiers
In-Reply-To: <1535352467.5.0.56676864532.issue34515@psf.upfronthosting.co.za>
Message-ID: <1537032753.85.0.956365154283.issue34515@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 10a428b64b3f224e2ccd40ff2afb141b9b3425b1 by Benjamin Peterson (Monson Shao) in branch 'master':
closes bpo-34515: Support non-ASCII identifiers in lib2to3. (GH-8950)
https://github.com/python/cpython/commit/10a428b64b3f224e2ccd40ff2afb141b9b3425b1


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34515>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:32:49 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 15 Sep 2018 17:32:49 +0000
Subject: [issue34515] lib2to3: support non-ASCII identifiers
In-Reply-To: <1535352467.5.0.56676864532.issue34515@psf.upfronthosting.co.za>
Message-ID: <1537032769.43.0.956365154283.issue34515@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8756

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34515>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:37:33 2018
From: report at bugs.python.org (monson)
Date: Sat, 15 Sep 2018 17:37:33 +0000
Subject: [issue33338] [lib2to3] Synchronize token.py and tokenize.py with the
 standard library
In-Reply-To: <1524445496.4.0.682650639539.issue33338@psf.upfronthosting.co.za>
Message-ID: <1537033053.69.0.956365154283.issue33338@psf.upfronthosting.co.za>


Change by monson <holymonson at gmail.com>:


----------
pull_requests: +8757

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33338>
_______________________________________

From report at bugs.python.org  Sat Sep 15 13:53:02 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 15 Sep 2018 17:53:02 +0000
Subject: [issue34515] lib2to3: support non-ASCII identifiers
In-Reply-To: <1535352467.5.0.56676864532.issue34515@psf.upfronthosting.co.za>
Message-ID: <1537033982.46.0.956365154283.issue34515@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 51dbae867e82014f9af89662977e4981463c51e8 by Miss Islington (bot) in branch '3.7':
closes bpo-34515: Support non-ASCII identifiers in lib2to3. (GH-8950)
https://github.com/python/cpython/commit/51dbae867e82014f9af89662977e4981463c51e8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34515>
_______________________________________

From report at bugs.python.org  Sat Sep 15 14:12:39 2018
From: report at bugs.python.org (Adam Meily)
Date: Sat, 15 Sep 2018 18:12:39 +0000
Subject: [issue29883] asyncio: Windows Proactor Event Loop UDP Support
In-Reply-To: <1490210881.18.0.553215827239.issue29883@psf.upfronthosting.co.za>
Message-ID: <1537035159.68.0.956365154283.issue29883@psf.upfronthosting.co.za>


Adam Meily <meily.adam at gmail.com> added the comment:

I've rebased onto upstream master and I fixed the CI build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29883>
_______________________________________

From report at bugs.python.org  Sat Sep 15 14:25:04 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 15 Sep 2018 18:25:04 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1537035904.89.0.956365154283.issue33608@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +8758
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Sat Sep 15 14:59:48 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Sep 2018 18:59:48 +0000
Subject: [issue34660] Remove ableist terms and pejoratives from source code
 and docs
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537037988.55.0.956365154283.issue34660@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +8759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sat Sep 15 15:20:16 2018
From: report at bugs.python.org (Guo Ci Teo)
Date: Sat, 15 Sep 2018 19:20:16 +0000
Subject: [issue34699] allows path-like objects in program arguments in Windows
Message-ID: <1537039216.54.0.956365154283.issue34699@psf.upfronthosting.co.za>


New submission from Guo Ci Teo <zguoci at gmail.com>:

Currently, the `subprocess.Popen` function allows for path-like objects in the argument list for POSIX but not in Windows.
This PR makes Windows' `subprocess.Popen` accept path-like objects in the argument list.

----------
components: Library (Lib)
messages: 325454
nosy: guoci
priority: normal
severity: normal
status: open
title: allows path-like objects in program arguments in Windows
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34699>
_______________________________________

From report at bugs.python.org  Sat Sep 15 15:24:37 2018
From: report at bugs.python.org (Guo Ci Teo)
Date: Sat, 15 Sep 2018 19:24:37 +0000
Subject: [issue34699] allows path-like objects in program arguments in Windows
In-Reply-To: <1537039216.54.0.956365154283.issue34699@psf.upfronthosting.co.za>
Message-ID: <1537039477.09.0.956365154283.issue34699@psf.upfronthosting.co.za>


Change by Guo Ci Teo <zguoci at gmail.com>:


----------
keywords: +patch
pull_requests: +8760
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34699>
_______________________________________

From report at bugs.python.org  Sat Sep 15 15:47:21 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 15 Sep 2018 19:47:21 +0000
Subject: [issue34685] scheduler tests for posix_spawn fail on AMD64 FreeBSD
 10.x Shared 3.x
In-Reply-To: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>
Message-ID: <1537040841.93.0.956365154283.issue34685@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34685>
_______________________________________

From report at bugs.python.org  Sat Sep 15 16:10:00 2018
From: report at bugs.python.org (Ben Darnell)
Date: Sat, 15 Sep 2018 20:10:00 +0000
Subject: [issue34700] typing.get_type_hints doesn't know about typeshed
Message-ID: <1537042200.54.0.956365154283.issue34700@psf.upfronthosting.co.za>


New submission from Ben Darnell <ben.darnell at gmail.com>:

Currently, most type annotations for the standard library are provided in typeshed rather than in the library itself. Not all consumers of type annotations are aware of typeshed, and this can cause problems. Specifically, Sphinx 1.8 accesses type hints via `typing.get_type_hints()`, which fails for some hints which are (implicitly) relying on typeshed. This currently manifests as failures to build Tornado's docs with Sphinx 1.8 (Tornado is using inline type annotations).

Concretely, the issue involves the `concurrent.futures.Future` class. In typeshed, this class is a `Generic[T]`, but in the standard library it's just a normal class. Consider a function that returns a parameterized Future type:

    from concurrent.futures import Future

    def do_something_background() -> 'Future[int]':
        return executor.submit(do_something)

Note that the type annotation is already a string. We can't use `Future[int]` directly because at runtime, the real Future type is not subscriptable. The string defers resolution of the subscript until something tries to access the annotation *as a type hint*. When mypy does this, it uses the typeshed definition of Future, so everything passes. But when Sphinx calls `typing.get_type_hints()` on this function, it fails:

```
>>> typing.get_type_hints(do_something_background)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 1543, in get_type_hints
    value = _eval_type(value, globalns, localns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 350, in _eval_type
    return t._eval_type(globalns, localns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 245, in _eval_type
    eval(self.__forward_code__, globalns, localns),
  File "<string>", line 1, in <module>
TypeError: 'type' object is not subscriptable
```


What can be done about this? I see a few approaches:

1. Require that any use of type hints consults typeshed. This would entail either making typing.get_type_hints aware of typeshed or deprecating and removing it.

2. Disallow references to typeshed from inline type annotations; types that require typeshed must only appear in `.pyi` stubs, which will only be interpreted by tools like mypy that know about typeshed. (is this true, or are there tools that know about pyi files but not typeshed?)

3. Annotate types in the standard library as generic. So far, this problem has always taken the form of "type is not subscriptable", and it could be resolved by making all generic types in the stdlib subclasses of `typing.Generic[T]`. This would bring enough typing detail into the stdlib to allow the annotations to be parsed without typeshed. This would also avoid the need for the awkward quotes in the example above.

----------
messages: 325455
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: typing.get_type_hints doesn't know about typeshed
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34700>
_______________________________________

From report at bugs.python.org  Sat Sep 15 16:19:24 2018
From: report at bugs.python.org (Guo Ci Teo)
Date: Sat, 15 Sep 2018 20:19:24 +0000
Subject: [issue34699] allow path-like objects in program arguments in Windows
In-Reply-To: <1537039216.54.0.956365154283.issue34699@psf.upfronthosting.co.za>
Message-ID: <1537042764.7.0.956365154283.issue34699@psf.upfronthosting.co.za>


Change by Guo Ci Teo <zguoci at gmail.com>:


----------
title: allows path-like objects in program arguments in Windows -> allow path-like objects in program arguments in Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34699>
_______________________________________

From report at bugs.python.org  Sat Sep 15 16:41:11 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Sep 2018 20:41:11 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537044071.1.0.956365154283.issue34660@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am re-opening with the scope limited to source code that will not be part of a doc review.  The 2nd PR falls within this limit and I think it should be properly reviewed.

I am opposed to removing 'sanity check' as it has a well-enough defined meaning within programming that does not disparage the code author.  Indeed, sanity checks are often written and labelled as such by module authors.  PR9335 does not touch this phrase.

The other terms are more often applied to code by others, sometimes with a hint of disparagement of the author.

----------
assignee: willingc -> 
nosy: +terry.reedy
resolution: remind -> 
stage: resolved -> patch review
status: closed -> open
title: Remove ableist terms and pejoratives from source code and docs -> Replace ableist terms and pejoratives in source code.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sat Sep 15 17:12:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 21:12:06 +0000
Subject: [issue33617] subprocess.Popen etc do not accept os.PathLike in passed
 sequence on Windows
In-Reply-To: <1527084844.2.0.682650639539.issue33617@psf.upfronthosting.co.za>
Message-ID: <1537045926.35.0.956365154283.issue33617@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a duplicate of issue31961.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> subprocess._execute_child doesn't accept a single PathLike argument for args

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33617>
_______________________________________

From report at bugs.python.org  Sat Sep 15 17:12:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 21:12:15 +0000
Subject: [issue34699] allow path-like objects in program arguments in Windows
In-Reply-To: <1537039216.54.0.956365154283.issue34699@psf.upfronthosting.co.za>
Message-ID: <1537045935.66.0.956365154283.issue34699@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a duplicate of issue31961.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> subprocess._execute_child doesn't accept a single PathLike argument for args

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34699>
_______________________________________

From report at bugs.python.org  Sat Sep 15 18:34:31 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 15 Sep 2018 22:34:31 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537050871.34.0.956365154283.issue32117@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Jordan, what's your GitHub account name? I hope you can check this out and make the changes I'm requesting on GitHub.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Sat Sep 15 18:44:11 2018
From: report at bugs.python.org (Jordan Chapman)
Date: Sat, 15 Sep 2018 22:44:11 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537051451.27.0.956365154283.issue32117@psf.upfronthosting.co.za>


Jordan Chapman <jchapman134569 at gmail.com> added the comment:

Here's my GitHub account: I'll make the changes and rebase as soon as I get home.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Sat Sep 15 18:45:15 2018
From: report at bugs.python.org (Jordan Chapman)
Date: Sat, 15 Sep 2018 22:45:15 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537051515.74.0.956365154283.issue32117@psf.upfronthosting.co.za>


Jordan Chapman <jchapman134569 at gmail.com> added the comment:

Sorry, I could have sworn that I pasted my link... https://github.com/jChapman

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Sat Sep 15 18:53:38 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 22:53:38 +0000
Subject: [issue31779] assertion failures and a crash when using an
 uninitialized struct.Struct object
In-Reply-To: <1507892060.42.0.213398074469.issue31779@psf.upfronthosting.co.za>
Message-ID: <1537052018.6.0.956365154283.issue31779@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

What are the drawbacks of moving all code from __init__ to __new__, at least in master branch (3.8)? IMO it's much more robust than playing whack-a-mole both with ref/memleaks caused by repeated calls to __init__ and absence of initialization checks in all methods.

----------
nosy: +berker.peksag, izbyshev, mark.dickinson, meador.inge, serhiy.storchaka
versions: +Python 2.7, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31779>
_______________________________________

From report at bugs.python.org  Sat Sep 15 19:34:31 2018
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 15 Sep 2018 23:34:31 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537054471.32.0.956365154283.issue34683@psf.upfronthosting.co.za>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +8761
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Sat Sep 15 19:37:00 2018
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 15 Sep 2018 23:37:00 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537054620.29.0.956365154283.issue34683@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Added a PR that is an implementation of Benjamin's suggestion. The column offset returned has been made 0-indexed and errors now point to the start of the parsed token.

This makes errors like `def class` show up as

def class
    ^

instead of

def class
        ^

Also added tests for the original example and some more errors from ast.c

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Sat Sep 15 20:01:10 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 16 Sep 2018 00:01:10 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1537056070.96.0.956365154283.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

New version of runstack.py.

- Reworked code to reflect that Python's sort uses (start_offset, run_length) pairs to record runs.

- Two unbounded-integer power implementations, one using a loop and the other division.  The loop version implies that, in Python's C implementation, size_t arithmetic would always suffice.  The division version shows that 2*d-1 bit unsigned division suffices if the # of array elements fits in d bits (so 64-bit ints in C would suffice for arrays up to 2**32 elements).

- Another power implementation using frexp - unpromising.

- And another that specializes the division method by rounding the array size up to a power of 2, removing the need for division.  Maybe worth looking at more, but offhand the results were significantly poorer.

- Added a "bad case" for powersort - surprising!  timsort and 2-merge are optimal in this case.  powersort "merge cost" is up to a third larger.

----------
Added file: https://bugs.python.org/file47804/runstack.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34561>
_______________________________________

From report at bugs.python.org  Sat Sep 15 20:02:54 2018
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 16 Sep 2018 00:02:54 +0000
Subject: [issue32153] mock.create_autospec fails if an attribute is a partial
 function
In-Reply-To: <1511864595.09.0.213398074469.issue32153@psf.upfronthosting.co.za>
Message-ID: <1537056174.86.0.956365154283.issue32153@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

It seems to me that we have three alternatives : 

  1. Refuse to create the mock object with a suitable Exception (rather than a crash
  2. Copy the object and simply ignore the missing dunder_name (so that funcopy dunder_name is not set
  3. Set funcopy dunder_name to a known string when the source dunder_name is missing

It seems obvious to me that option 3 is correct - just a question of what funcopy dunder_name should be set to. I would imagine there is code that uses funcopy dunder_name in some way ?

----------
nosy: +anthony-flury

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32153>
_______________________________________

From report at bugs.python.org  Sat Sep 15 22:22:43 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 16 Sep 2018 02:22:43 +0000
Subject: [issue32153] mock.create_autospec fails if an attribute is a partial
 function
In-Reply-To: <1511864595.09.0.213398074469.issue32153@psf.upfronthosting.co.za>
Message-ID: <1537064563.71.0.956365154283.issue32153@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I think option 2 is what functools.update_wrapper() does and it may be better to make create_autospec() consistent with it.

Perhaps we can replace _copy_func_details() with functools.update_wrapper():

    assigments = (
        '__name__', '__doc__', '__text_signature__',
        # And the rest of the attributes in _copy_func_details().
    )
    functools.update_wrapper(..., assigned=assignments, updated=())

----------
nosy: +berker.peksag
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32153>
_______________________________________

From report at bugs.python.org  Sat Sep 15 22:29:58 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 16 Sep 2018 02:29:58 +0000
Subject: [issue32153] mock.create_autospec fails if an attribute is a partial
 function
In-Reply-To: <1511864595.09.0.213398074469.issue32153@psf.upfronthosting.co.za>
Message-ID: <1537064998.6.0.956365154283.issue32153@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Or we can special case functools.partial() in _copy_func_details() and use partial_object.func.__name__.

(I'm not sure which solution is better, but we need to the same thing for __doc__ as well.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32153>
_______________________________________

From report at bugs.python.org  Sat Sep 15 23:54:15 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 03:54:15 +0000
Subject: [issue34701] Asyncio documentation for recursive coroutines is lacking
Message-ID: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>


New submission from Azaria Zornberg <a.zornberg96 at gmail.com>:

When an asynchronous coroutine in asyncio awaits or yields from itself, any call to the function is executed somewhat synchronously.

Once the recursive coroutine begins, if it never awaits any other coroutines besides itself, nothing else will be scheduled to run until it has completely finished recursively calling itself and returning.
However, if it ever awaits a different coroutine (even something as small as asyncio.sleep(0)) then other coroutines will be scheduled to run.

It seems, from other documentation, that this is intentional. Other documentation sort of dances around the specifics of how coroutines work with recursion, and only examples of coroutines yielding from each other recursively are provided.

However, this behavior is never explicitly called out. This is confusing for people who write a recursive asyncio coroutine and are perplexed by why it seems to execute synchronously, assuming they ever notice.

I've attached a short script that can be run to exhibit the behavior.
A PR is going to be filed shortly against the python 3.7 branch (as the documentation page for asyncio in 3.8 does not fully exist right now).

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio_await_from_self_example.py
messages: 325468
nosy: asvetlov, azaria.zornberg, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio documentation for recursive coroutines is lacking
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47805/asyncio_await_from_self_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34701>
_______________________________________

From report at bugs.python.org  Sat Sep 15 23:59:43 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 03:59:43 +0000
Subject: [issue34701] Asyncio documentation for recursive coroutines is lacking
In-Reply-To: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>
Message-ID: <1537070383.6.0.956365154283.issue34701@psf.upfronthosting.co.za>


Change by Azaria Zornberg <a.zornberg96 at gmail.com>:


----------
keywords: +patch
pull_requests: +8762
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34701>
_______________________________________

From report at bugs.python.org  Sun Sep 16 00:09:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 16 Sep 2018 04:09:05 +0000
Subject: [issue34701] Asyncio documentation for recursive coroutines is lacking
In-Reply-To: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>
Message-ID: <1537070945.43.0.956365154283.issue34701@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The issue here is not the recursion,  but rather about the fact that coroutines should actually await on IO or other activity in order for the event loop to run them cooperatively.  E.g.

   async def foo():
        await foo()

doesn't really do anything expect calling itself, whereas

   async def foo():
        await sleep(0)
        await foo()

is asking the event loop to sleep for a moment and then recurses into itself.

I'm OK with better clarifying this in the asyncio-dev.rst file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34701>
_______________________________________

From report at bugs.python.org  Sun Sep 16 00:15:11 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 04:15:11 +0000
Subject: [issue34701] Asyncio documentation for recursive coroutines is lacking
In-Reply-To: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>
Message-ID: <1537071311.34.0.956365154283.issue34701@psf.upfronthosting.co.za>


Azaria Zornberg <a.zornberg96 at gmail.com> added the comment:

Ah, thanks for the clarification!

I first encountered this when having some issues with converting large objects to json. json.dumps happens synchronously, and when executed on an object that was dozens of MB in size, it held up everything for a fair bit of time.
I tried to solve it by recursively running json.dumps on smaller pieces of the thing being converted to json. And that was when I realized that this still wasn't letting other things get scheduled.

When I looked for examples online, I didn't see any of a recursive asyncio coroutine, which is why I assumed the recursion was the issue.


Any advice on better ways to phrase the documentation are greatly appreciated! Alternatively, it sounds like you have a much better understanding of this than I do, so I'm happy to defer to whatever you believe is the correct way to document this. Thanks for the help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34701>
_______________________________________

From report at bugs.python.org  Sun Sep 16 01:36:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 Sep 2018 05:36:33 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537076193.33.0.956365154283.issue34603@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7843caeb909bd907e903606414e238db4082315a by Victor Stinner (Vladimir Matveev) in branch 'master':
bpo-34603, ctypes/libffi_msvc: Fix returning structs from functions (GH-9258)
https://github.com/python/cpython/commit/7843caeb909bd907e903606414e238db4082315a


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Sun Sep 16 01:36:45 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Sep 2018 05:36:45 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537076205.68.0.956365154283.issue34603@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8764

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Sun Sep 16 01:36:53 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Sep 2018 05:36:53 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537076213.76.0.956365154283.issue34603@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8765

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Sun Sep 16 01:37:04 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Sep 2018 05:37:04 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537076224.83.0.956365154283.issue34603@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8766

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Sun Sep 16 01:53:16 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Sep 2018 05:53:16 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537077196.69.0.956365154283.issue34603@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e3f6aa7fe48b91f4ff619b2a51d473249d620bcb by Miss Islington (bot) in branch '3.7':
bpo-34603, ctypes/libffi_msvc: Fix returning structs from functions (GH-9258)
https://github.com/python/cpython/commit/e3f6aa7fe48b91f4ff619b2a51d473249d620bcb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Sun Sep 16 01:57:49 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Sep 2018 05:57:49 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537077469.84.0.956365154283.issue34603@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e53632019816749ffd5be0afab2a99d744dbbe35 by Miss Islington (bot) in branch '3.6':
bpo-34603, ctypes/libffi_msvc: Fix returning structs from functions (GH-9258)
https://github.com/python/cpython/commit/e53632019816749ffd5be0afab2a99d744dbbe35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Sun Sep 16 02:09:17 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Sep 2018 06:09: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: <1537078157.35.0.956365154283.issue19417@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 57e70d3802a2a78e638999c6923053c63fe373f8 by Miss Islington (bot) (xdegaye) in branch '2.7':
[2.7] bpo-19417: Add test_bdb.py (GH-5217) (GH-6156)
https://github.com/python/cpython/commit/57e70d3802a2a78e638999c6923053c63fe373f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19417>
_______________________________________

From report at bugs.python.org  Sun Sep 16 03:45:55 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 16 Sep 2018 07:45:55 +0000
Subject: [issue34697] ctypes: Crash if manually-created CField instance is used
In-Reply-To: <1537031593.26.0.956365154283.issue34697@psf.upfronthosting.co.za>
Message-ID: <1537083955.02.0.956365154283.issue34697@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34697>
_______________________________________

From report at bugs.python.org  Sun Sep 16 04:18:19 2018
From: report at bugs.python.org (Guillaume Ayoub)
Date: Sun, 16 Sep 2018 08:18:19 +0000
Subject: [issue34702] urlopen doesn't handle query strings with "file" scheme
Message-ID: <1537085899.9.0.956365154283.issue34702@psf.upfronthosting.co.za>


New submission from Guillaume Ayoub <xovni at wanadoo.fr>:

urlopen includes query strings in the filename with "file"-scheme URLs.

>>> from urllib.request import urlopen
>>> urlopen('file:///tmp/test')
<addinfourl at 140059890562888 whose fp = <_io.BufferedReader name='/tmp/test'>>
>>> urlopen('file:///tmp/test?q')
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1473, in open_local_file
    stats = os.stat(localfile)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/test?q'

This behavior seems to be OK with what RFC 8089 tells, but many other implementations (including browsers and curl) remove query strings from the filename.

----------
messages: 325475
nosy: liZe
priority: normal
severity: normal
status: open
title: urlopen doesn't handle query strings with "file" scheme
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34702>
_______________________________________

From report at bugs.python.org  Sun Sep 16 04:46:21 2018
From: report at bugs.python.org (Riccardo Mottola)
Date: Sun, 16 Sep 2018 08:46:21 +0000
Subject: [issue34560] Backport of uuid1() failure fix
In-Reply-To: <1535754822.12.0.56676864532.issue34560@psf.upfronthosting.co.za>
Message-ID: <1537087581.04.0.956365154283.issue34560@psf.upfronthosting.co.za>


Riccardo Mottola <multix at gmail.com> added the comment:

https://github.com/python/cpython/pull/9125

should close it

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34560>
_______________________________________

From report at bugs.python.org  Sun Sep 16 06:36:19 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 16 Sep 2018 10:36:19 +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: <1537094179.92.0.956365154283.issue32990@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

Andrea, are you still working on this issue? If not, I will submit a PR.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32990>
_______________________________________

From report at bugs.python.org  Sun Sep 16 07:05:14 2018
From: report at bugs.python.org (chengxuncc)
Date: Sun, 16 Sep 2018 11:05:14 +0000
Subject: [issue34703] Unexpected Arithmetic Result
Message-ID: <1537095914.48.0.956365154283.issue34703@psf.upfronthosting.co.za>


New submission from chengxuncc <chengxuncc at gmail.com>:

>>> 2359296/10/1000**2
0.23592960000000002

>>> 2359296/10000000
0.2359296

You can see it.

----------
components: Interpreter Core
messages: 325478
nosy: chengxuncc
priority: normal
severity: normal
status: open
title: Unexpected Arithmetic Result
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34703>
_______________________________________

From report at bugs.python.org  Sun Sep 16 07:14:11 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 16 Sep 2018 11:14:11 +0000
Subject: [issue34703] Unexpected Arithmetic Result
In-Reply-To: <1537095914.48.0.956365154283.issue34703@psf.upfronthosting.co.za>
Message-ID: <1537096451.7.0.956365154283.issue34703@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This isn't a bug; it's a result of Python using the hardware-provided binary floating-point, which can't represent all decimal numbers exactly.

Please take a look at https://docs.python.org/3/tutorial/floatingpoint.html for more information.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34703>
_______________________________________

From report at bugs.python.org  Sun Sep 16 07:24:13 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 16 Sep 2018 11:24:13 +0000
Subject: [issue34382] test_os.test_mode fails when directory base directory
 has g+s set
In-Reply-To: <1533990666.21.0.56676864532.issue34382@psf.upfronthosting.co.za>
Message-ID: <1537097053.01.0.956365154283.issue34382@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Closing this, and my PR, as issue34664 is a repeat and already merged.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34382>
_______________________________________

From report at bugs.python.org  Sun Sep 16 07:54:57 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 16 Sep 2018 11:54:57 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1537098897.17.0.956365154283.issue33608@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I would suggest that sharing of objects between interpreters should be stamped out.  Could we have some #ifdef debug checking that would warn or assert so this doesn't happen?  I know currently we share a lot of objects.  However, in the long term, that does not seem like the correct design.  Instead, each interpreter should have its own objects and any passing or sharing should be tightly controlled.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Sun Sep 16 07:57:42 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 16 Sep 2018 11:57:42 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537099062.98.0.956365154283.issue26979@psf.upfronthosting.co.za>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Sun Sep 16 08:35:23 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 16 Sep 2018 12:35:23 +0000
Subject: [issue34704] Do not access ob_type directly, introduce Py_TP
Message-ID: <1537101322.11.0.956365154283.issue34704@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

My long term goal is to make it possible to make PyObject an opaque structure.  Obviously that would break nearly every 3rd party extension at this point.  However, to allow freedom on certain interpreter implementation strategies, it is helpful if code does not access ob_type, ob_refcnt and ob_size directly.  Cleaning up core Python is not too hard.

There is closed bug #26824 which proposed a similar change.  There was two main issues with that patch.  One, it causes a fair amount of code churn.  This patch does that too.  Second, replace ob->ob_type with Py_TYPE(ob) adds an extra type-cast to PyObject*.  That's not good.

In this patch, I introduce Py_TP() as a non-typecast version of Py_TYPE().  I think the name is nice as it is short and matches the struct field prefix.

This change overlaps with Victor's proposed %t or %T format code change.  The code churn is mostly caused by code that does ob->ob_type->tp_name.  I'm not against the format code idea but personally I think trying to remove borrowed references is a difficult problem and it should not hold up the relatively simple task of allowing PyObject to be opaque.

Also, I doesn't see any immediate need to make PyTypeObject opaque.  The tp_* are used everywhere and so making access macros or functions for those would be hugely disruptive.  PyTypeObject is already opaque for the limited API.  I think that's good enough for now.

If this change gets accepted, I have follow-up patches to fix access to ob_refcnt and ob_size.  Those are much smaller patches since those fields are not often accessed.

----------
components: Interpreter Core
files: py_tp_macro.txt
keywords: needs review, patch
messages: 325482
nosy: nascheme, serhiy.storchaka, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Do not access ob_type directly, introduce Py_TP
type: enhancement
Added file: https://bugs.python.org/file47806/py_tp_macro.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34704>
_______________________________________

From report at bugs.python.org  Sun Sep 16 08:38:55 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 16 Sep 2018 12:38:55 +0000
Subject: [issue34704] Do not access ob_type directly, introduce Py_TP
In-Reply-To: <1537101322.11.0.956365154283.issue34704@psf.upfronthosting.co.za>
Message-ID: <1537101535.71.0.956365154283.issue34704@psf.upfronthosting.co.za>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
pull_requests: +8767

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34704>
_______________________________________

From report at bugs.python.org  Sun Sep 16 09:13:55 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 16 Sep 2018 13:13:55 +0000
Subject: [issue32152] Add pid to .cover filename in lib/trace.py
In-Reply-To: <1511858704.48.0.213398074469.issue32152@psf.upfronthosting.co.za>
Message-ID: <1537103635.34.0.956365154283.issue32152@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

The trace module doesn't get much use.  Have you tried using coverage.py?  https://pypi.org/project/coverage/

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32152>
_______________________________________

From report at bugs.python.org  Sun Sep 16 09:15:56 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 16 Sep 2018 13:15:56 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
Message-ID: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

When a return statement also executes a finally clause, the sequence of lines reported to the trace function is different in 3.8 than it has been before 3.8:

$ cat finally_trace.py
def return_from_finally():
    try:
        print("returning")
        return 17
    finally:
        print("finally")

def trace(frame, event, arg):
    print(frame.f_lineno, event)
    return trace

import sys
sys.settrace(trace)
return_from_finally()

$ python3.7 finally_trace.py
1 call
2 line
3 line
returning
4 line
6 line
finally
6 return

$ python3.8 finally_trace.py
1 call
2 line
3 line
returning
4 line
6 line
finally
4 line
4 return


Is this intentional? Is it a bug? Will it change back before 3.8 is shipped?

----------
components: Interpreter Core
messages: 325484
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.8 changes how returns through finally clauses are traced
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Sun Sep 16 09:16:53 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 16 Sep 2018 13:16:53 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537103813.91.0.956365154283.issue34705@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

This affects coverage.py, as reported in this bug: https://github.com/nedbat/coveragepy/issues/707

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Sun Sep 16 09:55:00 2018
From: report at bugs.python.org (Soumyadipta Das)
Date: Sun, 16 Sep 2018 13:55:00 +0000
Subject: [issue33367] Multiprocessing Pool workers initiated with
 maxtasksperchild do not execute when sharing logging
In-Reply-To: <1524756351.27.0.682650639539.issue33367@psf.upfronthosting.co.za>
Message-ID: <1537106100.61.0.956365154283.issue33367@psf.upfronthosting.co.za>


Change by Soumyadipta Das <das.soumyadipta.81 at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33367>
_______________________________________

From report at bugs.python.org  Sun Sep 16 09:56:16 2018
From: report at bugs.python.org (Soumyadipta Das)
Date: Sun, 16 Sep 2018 13:56:16 +0000
Subject: [issue33367] Multiprocessing Pool workers initiated with
 maxtasksperchild do not execute when sharing logging
In-Reply-To: <1524756351.27.0.682650639539.issue33367@psf.upfronthosting.co.za>
Message-ID: <1537106176.39.0.956365154283.issue33367@psf.upfronthosting.co.za>


Change by Soumyadipta Das <das.soumyadipta.81 at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33367>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:14:50 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sun, 16 Sep 2018 14:14:50 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537107290.03.0.956365154283.issue34660@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

Come on guys. Stop this madness. :(

----------
nosy: +suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:14:59 2018
From: report at bugs.python.org (Anthony Flury)
Date: Sun, 16 Sep 2018 14:14:59 +0000
Subject: [issue32153] mock.create_autospec fails if an attribute is a partial
 function
In-Reply-To: <1511864595.09.0.213398074469.issue32153@psf.upfronthosting.co.za>
Message-ID: <1537107299.18.0.956365154283.issue32153@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

Am not a big fan of special casing, 

I think the functools.update_wrapper is the way to go - will have a look later and produce a pull request with some test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32153>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:26:50 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 16 Sep 2018 14:26:50 +0000
Subject: [issue32490] subprocess: duplicate filename in exception message
In-Reply-To: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>
Message-ID: <1537108010.64.0.956365154283.issue32490@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

There was also some relevant discussion in #22536.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:28:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Sep 2018 14:28:56 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537108136.62.0.956365154283.issue34705@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a side effect of specific optimization. If the return value is constant, it is pushed on the stack after executing the finally code (see LOAD_CONST at offset 14 below). But other opcodes at this line (POP_BLOCK and CALL_FINALLY) are executed after executing the finally code. Thus it looks like the line 4 is executed twice, but actually different opcodes marked with the same line are executed before and after executing the finally code.

Disassembly of <code object return_from_finally at 0x7feff78897c0, file "<stdin>", line 1>:
  2           0 SETUP_FINALLY           16 (to 18)

  3           2 LOAD_GLOBAL              0 (print)
              4 LOAD_CONST               1 ('returning')
              6 CALL_FUNCTION            1
              8 POP_TOP

  4          10 POP_BLOCK
             12 CALL_FINALLY             4 (to 18)
             14 LOAD_CONST               2 (17)
             16 RETURN_VALUE

  6     >>   18 LOAD_GLOBAL              0 (print)
             20 LOAD_CONST               3 ('finally')
             22 CALL_FUNCTION            1
             24 POP_TOP
             26 END_FINALLY
             28 LOAD_CONST               0 (None)
             30 RETURN_VALUE

The benefit of this optimization is that it can make the stack smaller. This decreases the memory consumption of the Python function frame by one pointer and speeds up the Python function frame creation time (one pointer assignment less). It is tiny, but I think it is worth to keep it.

I don't know what is the right solution here.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:36:26 2018
From: report at bugs.python.org (Carol Willing)
Date: Sun, 16 Sep 2018 14:36:26 +0000
Subject: [issue29883] asyncio: Windows Proactor Event Loop UDP Support
In-Reply-To: <1490210881.18.0.553215827239.issue29883@psf.upfronthosting.co.za>
Message-ID: <1537108586.6.0.956365154283.issue29883@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
nosy: +willingc
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29883>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:39:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Sep 2018 14:39:02 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537108742.92.0.956365154283.issue34705@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Humm, the optimization is not related here. Even if it is not involved (replace 17 with []), the line 4 is reported twice, because RETURN_VALUE is executed after CALL_FINALLY.

  4          10 BUILD_LIST               0
             12 POP_BLOCK
             14 CALL_FINALLY             2 (to 18)
             16 RETURN_VALUE

In 3.7 RETURN_VALUE was the opcode executed at line 4. The stack of blocks was unwinded at interpreted loop implicitly when execute RETURN_VALUE. But in 3.8 calling the finally code is explicit.

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Sun Sep 16 10:39:40 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 16 Sep 2018 14:39:40 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1537108780.22.0.956365154283.issue21109@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

For one thing, the new diffs are still missing tests.

Tests should include, at the least:

1. *Safely* testing SafeTarFile against examples of problematic tarballs. Perhaps from Jakub's collection of "sly" tarballs could be used, assuming those could be licensed appropriately.
2. SafeTarFile should pass all of the normal TarFile tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Sun Sep 16 11:01:00 2018
From: report at bugs.python.org (ZooDSS)
Date: Sun, 16 Sep 2018 15:01:00 +0000
Subject: [issue34682] Typo reports on docs@
In-Reply-To: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>
Message-ID: <1537110060.75.0.956365154283.issue34682@psf.upfronthosting.co.za>


ZooDSS <ZooDSS at yandex.ru> added the comment:

Wanted to add a little bit more, but didn't know where to, so here it goes.

https://docs.python.org/3/reference/expressions.html#membership-test-operations

"The operator not in is defined to have the inverse true value of in." may be better to use "... the inverse truth value of in." as it is used in the next section, for identity comparisons explanation:

"x is not y yields the inverse truth value."


https://docs.python.org/3/reference/expressions.html#is-not

In this section "object identity" is used two times. May be better to say "object's identity", as identity is a part of an object. Object has identity.

"...test for object identity" - here.
"Object identity is determined..." - and here.

----------
nosy: +ZooDSS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34682>
_______________________________________

From report at bugs.python.org  Sun Sep 16 11:02:07 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Sep 2018 15:02:07 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537110127.46.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd strongly prefer to just go back to the PEP 538 design. It's much simpler to implement, we don't actually want anyone turning off locale coercion except for debugging purposes (unlike UTF-8 mode), and the only argument against doing this the way PEP 538 describes is a purist one, not a practical one (which was already resolved in favour of practicality when PEP 538 was accepted).

However, if you were willing to do the updates on my PR branch to implement it, then I'd accept an alternative that added a pass through the command line arguments that checks for at least one of the two following cases after a legacy locale has been detected:

- the new option "-X coerce_c_locale=0" (ASCII) is present in the arg list
- neither "-E" nor "-I" (ASCII) are present in the arg list, and PYTHONCOERCECLOCALE is not set to zero

The code that sets warn_on_c_locale in the core config would then look for `-X coerce_c_locale=warn` in addition to looking for `PYTHONCOERCECLOCALE=warn`.

That's quite a bit of code to add for the sake of a flag we don't really want anyone to ever use, though. (If it hadn't been for the debugging-CentOS-7-problems-on-Fedora issue, I doubt I would have included the off switch in PEP 538 at all)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Sun Sep 16 12:27:38 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 16 Sep 2018 16:27:38 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1537115258.44.0.956365154283.issue34363@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> [..] but I think it's the best we can do. It's consistent with any other class derived from tuple or list: [...]

I agree with this argument. Sorry for delay with my response and thank you Eric for taking care about this issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Sun Sep 16 13:42:53 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 16 Sep 2018 17:42:53 +0000
Subject: [issue32313] Wrong inspect.getsource for datetime
In-Reply-To: <1513201599.09.0.213398074469.issue32313@psf.upfronthosting.co.za>
Message-ID: <1537119773.37.0.956365154283.issue32313@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think this is *mostly* the correct behavior (though it may indeed be confusing). Note that `datetime.py` *is* the source of the module `datetime`, it's just that most of the code in there is shadowed by the line you've linked.

If you try and get the source of individual methods that were imported from `_datetime`, you'll get the expected failure:

>>> inspect.getsource(datetime.datetime.fromisoformat)
-- Long traceback --
TypeError: module, class, method, function, traceback, frame, or code object was expected, got builtin_function_or_method


That said, `inspect.getsource` does seem to be erroneously using the Python source for classes, e.g. `print(inspect.getsource(datetime.date))`

This is consistent with the behavior of `functools`, where the Python code for `functools.partial`, even when the C implementation is used.

Not sure if this is something that should be a warning, an exception or if the behavior should simply be documented in the `inspect` documentation.

I'll note that both `inspect.getsource(datetime)` and `inspect.getsource(datetime.date)` were IOError exceptions in Python 2.7, but have been returning the Python source code since at least Python 3.4.

----------
components: +Library (Lib)
nosy: +belopolsky, yselivanov
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/issue32313>
_______________________________________

From report at bugs.python.org  Sun Sep 16 14:01:48 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 16 Sep 2018 18:01:48 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1537120908.33.0.956365154283.issue31635@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think this is the relevant test: https://github.com/python/cpython/blob/3.7/Lib/test/test_strptime.py#L536

The issue seems to be in `strftime` rather than in `strptime`. According to Serhiy's paste, it seems that `datetime.datetime.strftime("%G %V %w")` on BSD results in "1904 53 0", whereas on Linux it results in "1904 52 0".

I suspect the confusion *may* be related to the fact that ISO weekdays go Monday (1) to Sunday (7), where as %w goes Sunday (0) to Saturday (6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Sun Sep 16 14:04:54 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 16 Sep 2018 18:04:54 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1537121094.44.0.956365154283.issue31635@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

This appears to be a duplicate of issue #13414, which was resolved as fixed in BSD. @serhiy Are you using a very old version of BSD?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Sun Sep 16 15:07:22 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 16 Sep 2018 19:07:22 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1537124842.35.0.956365154283.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Another runstack.py adds a bad case for 2-merge, and an even worse (percentage-wise) bad case for timsort.  powersort happens to be optimal for both.

So they all have contrived bad cases now.  powersort's bad cases are the least bad.  So far ;-)  But I expect that to remain so.

----------
Added file: https://bugs.python.org/file47807/runstack.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34561>
_______________________________________

From report at bugs.python.org  Sun Sep 16 16:37:57 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sun, 16 Sep 2018 20:37:57 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537130277.51.0.956365154283.issue34694@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@Mariatta:

> There will be no further discussion about this.

Repeating this over and over again won't solve the (any) issue. This madness reached another level here: https://bugs.python.org/issue34660. That was exactly my point here: https://bugs.python.org/issue34605#msg324825. <sarcasm>But let me guess: There will no (further) discussion about that either.</sarcasm> 

I find this behavior from the Python core developers and representatives simply irresponsible.

----------
nosy: +suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Sun Sep 16 16:52:13 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sun, 16 Sep 2018 20:52:13 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1537131133.79.0.956365154283.issue34605@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@serhiy.storchaka: IMO, the problem isn't the master/slave terminology itself but the way how the changes were introduced (no discussion) and the justification ("diversity reasons"???).

IMO this is the next level: https://bugs.python.org/issue34660 and I can't imagine what comes next. I find this nonsensical and I'm very disappointed that this ideological nonsense is infecting Python.

IMO the core developers should make a clear statement about this (either pro or contra). Once it's made, I'll have no other choice than respect that stance and act accordingly. Saying that "there will be not more discussions" or sending people to twitter like Guido did is not a solution and it's rather damaging the Python community and its reputation. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Sun Sep 16 17:12:01 2018
From: report at bugs.python.org (Buck Evan)
Date: Sun, 16 Sep 2018 21:12:01 +0000
Subject: [issue34706] Signature.from_callable sometimes drops subclassing
Message-ID: <1537132321.64.0.956365154283.issue34706@psf.upfronthosting.co.za>


New submission from Buck Evan <buck.2019 at gmail.com>:

Specifically in the case of a class that does not override its constructor signature inherited from object.

Github PR incoming shortly.

----------
components: Library (Lib)
messages: 325501
nosy: bukzor
priority: normal
severity: normal
status: open
title: Signature.from_callable sometimes drops subclassing
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34706>
_______________________________________

From report at bugs.python.org  Sun Sep 16 17:14:58 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 16 Sep 2018 21:14:58 +0000
Subject: [issue34706] Signature.from_callable sometimes drops subclassing
In-Reply-To: <1537132321.64.0.956365154283.issue34706@psf.upfronthosting.co.za>
Message-ID: <1537132498.76.0.956365154283.issue34706@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8768
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34706>
_______________________________________

From report at bugs.python.org  Sun Sep 16 17:18:45 2018
From: report at bugs.python.org (Lisa Roach)
Date: Sun, 16 Sep 2018 21:18:45 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537132725.23.0.956365154283.issue34659@psf.upfronthosting.co.za>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
keywords: +patch
pull_requests: +8769
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Sun Sep 16 17:19:28 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 16 Sep 2018 21:19:28 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537132768.78.0.956365154283.issue34660@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

David and Brett: I consider part of the actions of the anonymous person using the temporary aliases 25.45 and jonsees to be violations of our Code of Conduct.  I would therefore like you two to issue a warning, if not a ban.

I consider the first part of the initial message to be arrogant and rude.  I let that go, took "The goal of this issue is not to stir up arguments, but to figure out the alternatives and ways to replace those problematic terms." at face value, re-opened the issue, and reviewed the second PR.  In response, 'jonsees' refused to fix the bug and make or discuss the other requested revisions, but instead insulted and lied*.  In other words, 'argument' rather than 'figuring out'.  This treatment of my volunteer efforts makes me less willing to contribute more.

* In the context of Victor's changes on another issue, Raymond merging his first PR, Carol's promise to review the docs for inconsiderate language, and me reviewing the second PR and approving parts thereof, "Python developers have no desire of actually accepting any of these changes" is an insulting lie.
---

Gabriel: From what you wrote here, it was not immediately clear what 'madness' you want stopped.  The presence of certain words in the docs?  Or the blanket removal of certain words from the docs?  I am guessing the latter.  If so, that is not what any core devs that I know of are openly advocating.

The fact that I have to guess illustrates what I wrote in the review: "the 'sin' of these words is that they tend to be vague and say more about the writer's opinion than about the ostensible subject."  Do you think it madness to replace vague (and somewhat sloppy) words with more precise words that better communicate real meaning to users?  That is what Raymond did and what I intended to do.
---

I am leaving this issue open so that I can at least remove "Windows is lunatic" in a new PR.

----------
nosy: +brett.cannon, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sun Sep 16 18:41:07 2018
From: report at bugs.python.org (Buck Evan)
Date: Sun, 16 Sep 2018 22:41:07 +0000
Subject: [issue34706] Signature.from_callable sometimes drops subclassing
In-Reply-To: <1537132321.64.0.956365154283.issue34706@psf.upfronthosting.co.za>
Message-ID: <1537137667.54.0.956365154283.issue34706@psf.upfronthosting.co.za>


Change by Buck Evan <buck.2019 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34706>
_______________________________________

From report at bugs.python.org  Sun Sep 16 18:44:41 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sun, 16 Sep 2018 22:44:41 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537137881.61.0.956365154283.issue34660@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@terry.reedy: By madness I meant:

1. blank replacement of words without relevant justification. Collecting 5 links and labelling some words as pejorative or <whatever>ist or do it for ?diversity reasons? etc. is no justification. I have no problem with changing wording in documentation but it has to be justified.

2. that IMO this is _de facto_ PC/SJW language mutilation/censorship. I've made my main claim about that here: https://bugs.python.org/issue34605#msg324825 and IMO this is a continuation of the BPO34605 which is not any better or even worse than this one. I also expect more BPOs and PRs like this and IMHO _no more BPOs or PRs like this should be accepted or merged_.

If I can advise: There should be a clear statement about how PSF and core developers will handle BPOs and PRs like this or BPO34605 i.e. if you accept/reject them in the future eventually what is going to be the rule of thumb for acceptance. It can bring some clarity into this whole issue/discussion. What I?ve experienced so far is very disappointing. Repeating ?there will be no more discussion about this? is not a solution and I consider this to be damaging for Python community?s reputation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sun Sep 16 18:49:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 16 Sep 2018 22:49:00 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537138140.5.0.956365154283.issue34694@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Jose: The purpose of the tracker is to facilitate patches to the CPython code and docs.  Your post and personal perspective (with 'srecentrly uddenly' corrected),though related, belongs elsewhere, such as python-list.

Gabriel: Insults so not solve issues.  Rather they discourage people from volunteering to improve Python.  They are a violation of the Code of Conduct.  Please consider this a warning and don't repeat.

----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Sun Sep 16 19:40:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 16 Sep 2018 23:40:47 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537141247.36.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 5cc583d94095ed3bb543fa2f032f9593a6315a52 by Yury Selivanov (Bumsik Kim) in branch 'master':
bpo-33649: Clarify protocol_factory as a method parameter (GH-9330)
https://github.com/python/cpython/commit/5cc583d94095ed3bb543fa2f032f9593a6315a52


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Sun Sep 16 21:12:44 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Sep 2018 01:12:44 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537146764.82.0.956365154283.issue34660@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Gabriel, I believe I addressed most your concerns in my previous post.  You might reread it in that light.  

There seems to be a misperception that we have collectively changed how we judge doc proposals.  Should we 'announce' that we proceed as we have been?

Are you are suggesting that we judge proposals by the proposer, rather than the substance of the proposal? In general, I should hope we do not have to.

If you want to be concretely helpful, comment on one or more of the specific proposals in PR9335, forgetting who made the proposal and why.  Or, pretend that I suggested making those changes for better clarity.  (But skip the multiple 'crazy' to 'weird' changes, as I have decided against those.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sun Sep 16 21:41:02 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 17 Sep 2018 01:41:02 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537148462.12.0.956365154283.issue34660@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Hi all,

I'm going to close this issue for now. As I mentioned earlier (sorry Terry for not being clearer), I will be doing a comprehensive review of the docs and source code over the next few months. I will make recommendations as PRs and issues as I go through the review (see #msg325291).

In the review, I will take into account PSF values, clarity in source code as well as testing of code changes, and best practices in documentation.

Thanks everyone for respecting my intent to treat this review in a respectful and thoughtful manner.

----------
resolution:  -> postponed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sun Sep 16 22:04:35 2018
From: report at bugs.python.org (john skaller)
Date: Mon, 17 Sep 2018 02:04:35 +0000
Subject: [issue34707] Python not reentrant
Message-ID: <1537149875.51.0.956365154283.issue34707@psf.upfronthosting.co.za>


New submission from john skaller <skaller at users.sourceforge.net>:

Executive Summary: Python currently is not properly re-entrant. This comment applies to the CAPI and particularly embedding. A fix is not possible in Python 3.x but should be scheduled for Python 4. On Linux all binary plugins are broken as well.

The fault is exhibited by the need to first call PyInitialise(). This is clearly wrong because there is nowhere to put the initialised data. The correct sequence should be to first create an interpreter handle, and then initialise that. Other API calls exhibit the same fault. For example PyErr_Occured().

Use of thread local storage is NOT enough.

A general embedding scenario is this: a thunk program is used to dynamically load a shared library and execute a function in it. That function may load other shared libraries. Note carefully there is no global data, the libraries are pure code. [This is not an imagined scenario, my whole system works this way]

The same library may be loaded several times. For example, A can load B and C, and both B and C can load D. Proper visibility control means A cannot see any symbols of D.

In this scenario if D wishes to run a Python interpreter, it must call PyInitialise(), and it will be called twice, since D is called twice, once from A, and once from B. Indeed, if the top level spawns multiple threads, it can be called many more times than that. 

Remember the libraries are pure code and fully reentrant. There is no way to record if a function has been called already.

In order for Python to be fully re-entrant there is a simple test: if the C code of the Python library contains ANY global variables at all then Python is wrong. Global variables INCLUDE thread local storage. ALL data and ALL functions must hang off a handle so that all functionality and behaviour is fully isolated to each handle.

Exceptions to the rule: poorly designed OS such as Unix have some non-reentrant features. The worst of these in Unix is signal handling. It is not possible to handle signals without a global variable to communicate between the signal handler and application. The right way to do this would have been to use a polling service to detect the signal. In any case systems like Python do have to work with badly designed API's sometimes and therefore these special cases do form legitimate exceptions to the requirement that the API be re-entrant. My recommendation is to provide a cheat API which looks re-entrant but actually isn't, because it delegates to a hidden lower level which isn't, of necessity. YMMV: how to handle bad underlying API's should be open for discussion.

Other consequences: On linux at least ALL plugin extensions are built incorrectly. The correct way to build a plugin requires explicitly linking against the Python library, so that symbols in the Python API can be found. These symbols must NOT be found in the application because this is, quite simply, not possible, if the application does not include those symbols. In my scenario, the top level application is three lines of C than does nothing other than load a library and run a fixed function in it. And that library has no idea that one of the libraries IT loads may call another library which happens to want to run some Python code. Indeed my system can *generate* Python modules, and compile and link them against the Python library, but it cannot load any existing plugins on Linux, because those plugins were incorrectly built and do not link to the Python library as they should. They expect to find symbols in the symbol table magically provided but those symbols are not there.

On OSX, however, it works. That is because on OSX, a --framework is used to contain the Python library and all plugins HAVE to be linked against the framework. I expect the Windows builds to work too, for the same reason (but I'm not sure).

This issue is related to the lack of re-entrancy because the same principle is broken in both cases. If you need a service, you must ask for it, and when you get it, it is exclusively yours.

----------
components: Interpreter Core
messages: 325508
nosy: skaller
priority: normal
severity: normal
status: open
title: Python not reentrant
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34707>
_______________________________________

From report at bugs.python.org  Sun Sep 16 22:53:01 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Mon, 17 Sep 2018 02:53:01 +0000
Subject: [issue34708] Odd crashes/freezes when sys.stdout.shell.console is
 typed
Message-ID: <1537152781.74.0.956365154283.issue34708@psf.upfronthosting.co.za>


New submission from Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au>:

If sys is imported and sys.stdout.shell.console is typed, IDLE does not return to the prompt. Ctrl-C has no effect and after a restart with Ctrl-F6, IDLE does not react after a command is typed in. This also occurs when other variables such as sys.stdout.shell.stdout are used, but not with non-existent variables such as sys.stdout.shell.not_a_variable. No such issue occurs using the command line; however, sys.stdout.shell is not defined in the command line. This behaviour exists in at least Python 3.6.1 and 3.7.0 on Mac OS X 10.9.

This might be related to a similar issue that occurs in at least Python 3.2 on Windows 2000. Entering sys.stdout.shell.console causes IDLE to crash immediately; a crash also occurs when you type sys.stdout.shell.console. and wait for IDLE to bring up the list of attributes.

I know that this bug shouldn't be encountered unless you're using the IDLE PyShell object for some reason, but it still seems weird that getting the value of a variable causes crashes and hangs, especially when I know that the variable exists from looking at idlelib.

This is marked as Python 3.4 to 3.7 because I tested with 3.7, 3.6 and 3.2 and I don't think that this would have been fixed and then broken again. I don't know about 3.8, though.

----------
assignee: terry.reedy
components: IDLE
files: fail.py
messages: 325509
nosy: Harrison Chudleigh, terry.reedy
priority: normal
severity: normal
status: open
title: Odd crashes/freezes when sys.stdout.shell.console is typed
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47808/fail.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34708>
_______________________________________

From report at bugs.python.org  Sun Sep 16 22:57:19 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Mon, 17 Sep 2018 02:57:19 +0000
Subject: [issue34708] Odd crashes/freezes when sys.stdout.shell.console is
 typed
In-Reply-To: <1537152781.74.0.956365154283.issue34708@psf.upfronthosting.co.za>
Message-ID: <1537153039.57.0.956365154283.issue34708@psf.upfronthosting.co.za>


Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au> added the comment:

Edit: I checked Python 3.4 (Windows XP SP3). It hangs in the same way as Python 3.6/3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34708>
_______________________________________

From report at bugs.python.org  Sun Sep 16 22:59:15 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Mon, 17 Sep 2018 02:59:15 +0000
Subject: [issue34708] Odd crashes/freezes when sys.stdout.shell.console is
 typed
In-Reply-To: <1537152781.74.0.956365154283.issue34708@psf.upfronthosting.co.za>
Message-ID: <1537153155.91.0.956365154283.issue34708@psf.upfronthosting.co.za>


Change by Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34708>
_______________________________________

From report at bugs.python.org  Mon Sep 17 00:57:38 2018
From: report at bugs.python.org (Amos S)
Date: Mon, 17 Sep 2018 04:57:38 +0000
Subject: [issue34709] Suggestion: make getuser.getpass() also look at
 SUDO_USER environment variable
Message-ID: <1537160258.21.0.956365154283.issue34709@psf.upfronthosting.co.za>


New submission from Amos S <amos.shapira at gmail.com>:

When doing "sudo python-script.py", the output of "getpass.getuser()" is pretty much useless for what it's used (I assume mainly logging and tracking purposes, that's what we use it for ourselves).

I worked around this limitation by using it in expression likes:

  username = os.environ.get("SUDO_USER") or getpass.getuser()

I think it'll be useful to many other users if getpass.getuser() could integrate this behavior.

I'd love to provide the code change if this is approved.

----------
messages: 325511
nosy: Amos S
priority: normal
severity: normal
status: open
title: Suggestion: make getuser.getpass() also look at SUDO_USER environment variable
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/issue34709>
_______________________________________

From report at bugs.python.org  Mon Sep 17 01:38:13 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 17 Sep 2018 05:38:13 +0000
Subject: [issue34673] make the eval loop more editable
In-Reply-To: <1536898472.44.0.956365154283.issue34673@psf.upfronthosting.co.za>
Message-ID: <1537162693.78.0.956365154283.issue34673@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset ddd1949fea59f256e51191540a4446f75ed608fa by Benjamin Peterson in branch 'master':
closes bpo-34673: Tweaks to make ceval more editable. (GH-9289)
https://github.com/python/cpython/commit/ddd1949fea59f256e51191540a4446f75ed608fa


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34673>
_______________________________________

From report at bugs.python.org  Mon Sep 17 01:54:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 05:54:45 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537163685.56.0.956365154283.issue34659@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a duplicate of issue25193.

See also a long discussion on the Python-ideas mailing list 5 months ago: [Start argument for itertools.accumulate()](https://mail.python.org/pipermail/python-ideas/2018-April/049649.html).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Mon Sep 17 01:57:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 05:57:17 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1537163837.83.0.956365154283.issue31635@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I used OpenBSD 6.1. I'll check on more modern versions when have chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Mon Sep 17 02:22:01 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 06:22:01 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537165321.31.0.956365154283.issue34659@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Mon Sep 17 02:26:26 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 06:26:26 +0000
Subject: [issue33367] Multiprocessing Pool workers initiated with
 maxtasksperchild do not execute when sharing logging
In-Reply-To: <1524756351.27.0.682650639539.issue33367@psf.upfronthosting.co.za>
Message-ID: <1537165586.92.0.956365154283.issue33367@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33367>
_______________________________________

From report at bugs.python.org  Mon Sep 17 02:43:18 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Sep 2018 06:43:18 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537166598.75.0.956365154283.issue34659@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +kristjan.jonsson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Mon Sep 17 03:17:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 07:17:27 +0000
Subject: [issue27572] Support bytes-like objects when base is given to int()
In-Reply-To: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za>
Message-ID: <1537168647.54.0.956365154283.issue27572@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/issue27572>
_______________________________________

From report at bugs.python.org  Mon Sep 17 05:17:39 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Mon, 17 Sep 2018 09:17:39 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537175859.32.0.956365154283.issue34660@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@terry.reedy

> Gabriel, I believe I addressed most your concerns in my previous post.

I don't think so (see below) but we don't have to agree in everything. :)

> Are you are suggesting that we judge proposals _by the proposer_, rather than the substance of the proposal?

Definitely not. It really doesn't matter who has made a proposal if _it makes sense_. However, that doesn't matter either when a proposal doesn't make sense or it's ill-advised or not justified.

> who made the proposal and _why_

I don't care about who but the _why_ is the matter here as I put it in point 1. of my previous post. IMO one has to be clear and explicit about his/her intentions/justifications i.e. if one does something for clarity than he or she should declare it :)

> There seems to be a misperception that we have collectively changed how we judge doc proposals.  Should we 'announce' that we proceed as we have been?

When I use your word: PSF and core developers should address the misperception. To be honest with you, IMO the "Python officials" handled these issues very badly and unprofessionally. Let me clarify. I'm not the only one who has perceived this BPO and V. Stinner's master/slave change (or some "gender neutralizations" of the documentation in the past) as PC/SJW ergo politically/ideologically motivated. So, what is perceived to be the main issue is the motivation. The way these were handled brings quite an _ambiguous_ impression and it's not clear if PSF or core developers are willing to proceed in this PC/SJW (ergo political/ideological) direction or what exactly is their stance. I read the BPOs and GH PRs and also some other articles and discussions where this ambiguity created a lot of confusion. There were statements in those articles and discussions like "GvR were asked to decide this question and he agrees with PC/SJW direction..." Therefore, I don't know how to interpret "that we proceed as we have been" as IMO no clear statement has been made so far.

tl;dr

To conclude: I think we still aren't at the same page. However, I'm not sure if it makes sense to continue in this debate _at the moment_ at least for me. The amount of absurdity, nonsense*  and misconduct, _I've perceived_ while discussing these two BPOs, made me disappointed and discouraged me for any further participation on trying to make Python better at least for now. I want to give it some time and come back to this with a "cool(er) head".

To be specific: merging unjustified politically or ideologically motivated changes without discussion, not addressing factual arguments, silencing and censoring discussions**, sending people to Twitter (even if they don't have an account), using Code of Conduct as a tool***, making "feeling-based" arguments aren't characteristics of rational discourse or open community. I can't imagine what comes next but after all these things, I'm (rather) pessimistic.

* e.g. "cleaning/censoring" language based on its "potential offensiveness" is a nonsense as any language _is_ potentially offensive.
** "no further discussion is needed" (or even welcomed) without further context or clarification _can be perceived_ as arrogant as saying "Shut up! I know it better!"
*** To be clear, I don't mean your warning under issue34694. I can completely agree that I shouldn't/mustn't make sarcastic comments. IMO CoC is a written-down common sense. If it needs to be used as an argument (i.e. a tool) in a discussion, it's a sign of deeper issues or that something went to far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Mon Sep 17 05:25:11 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 17 Sep 2018 09:25:11 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537176311.02.0.956365154283.issue26979@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Ah! It seems you don't need access to all tp_* slots of any type here, but just to PyType.tp_new ? only one specific type, and only one specific slot.
Specifically, you need a way to create class with a metaclass, from C.

Is that right? Or was this only an example of a larger problem?

(Sorry for drawing the discussion out! Dropping the checks in PyType_GetSlot would be a simple change technically, but it doesn't match my mental model of what the stable ABI should be. I'm hoping to get a better solution for your use case, and others like it.)


> To obtain sizeof(PyType_Type), we simply used the Python code
>     type.__basicsize__
> It is a simple trick, but probably very few people know this path
> to get that info. At least, for me it took way too long ;-)

Well, basicsize might be exposed through Python, but it's still not part of the limited API. Which is fine ? all that means is you might need to change the extension for some future version of Python. I'm sure your tests will tell you when the time comes, and I hope we'll have a better solution then!
BTW, I'm honestly very impressed how far PySide got with the limited API!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Mon Sep 17 05:30:17 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 17 Sep 2018 09:30:17 +0000
Subject: [issue34704] Do not access ob_type directly, introduce Py_TP
In-Reply-To: <1537101322.11.0.956365154283.issue34704@psf.upfronthosting.co.za>
Message-ID: <1537176617.47.0.956365154283.issue34704@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

IMHO there doesn't need to be a new API unless the semantics change w.r.t Py_TYPE (for example by adding an API that returns an owned reference instead of a borrowed reference).   Py_TYPE can work with an opaque version of PyObject by turning it into a function.

BTW. Changing PyObject into an opaque structure is non-trivial because every instance currently explicitly contains a PyObject structure as the first field of the object definition.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34704>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:06:35 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Mon, 17 Sep 2018 10:06:35 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
Message-ID: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>


New submission from Alexandru Ardelean <ardeleanalex at gmail.com>:

See: https://github.com/openwrt/packages/pull/7051
The issue seems a bit older ; see comment: 
https://github.com/python/cpython/pull/3943#discussion_r148949292

Build error happens on OpenWrt as well:


---------------------------------------------------------------
<openwrt>/build_dir/target-i386_pentium4_musl/Python-3.7.0/Modules/_ssl.c:4000:5: error: implicit declaration of function 'DH_free'; did you mean 'lh_free'? [-Werror=implicit-function-declaration]
     DH_free(dh);
     ^~~~~~~
     lh_free
cc1: some warnings being treated as errors

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_tkinter              _uuid                 nis
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd
time                  zlib

Failed to build these modules:
_ssl

Makefile:618: recipe for target 'sharedmods' failed

---------------------------------------------------------------

The fix seems to be to include <openssl/dh.h>.

----------
assignee: christian.heimes
components: Build, SSL
messages: 325518
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: SSL Module build fails with more pedantic compiler flags
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:11:34 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Mon, 17 Sep 2018 10:11:34 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537179094.2.0.956365154283.issue34710@psf.upfronthosting.co.za>


Change by Alexandru Ardelean <ardeleanalex at gmail.com>:


----------
keywords: +patch
pull_requests: +8770
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:23:18 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 17 Sep 2018 10:23:18 +0000
Subject: [issue34711] Fix test_httpservers on AIX
Message-ID: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Going back to issue17234 - there has been a test to check that a URL with a trailing slash reports 404 status.

On AIX a trailing-slash is ignored - if the rest of the path is a valid filename.

At a very low-level, in Modules/_io/fileio.c the code could be adjusted to always look for a trailing slash, and if AIX considers the name to be a file (S_ISREG(mode)) then this could be promoted to an error. just as it does for "posix" opens directories with trailing slashes (and fileio.c deals with that in a Python way).

A quick fix is to skip the test issue17324 introduced;
A medium fix would be to modify Lib/http/server.py to verify that a URL with trailing slash is a directory, and otherwise raise an exception;
A deeper fix would be to add "a hack" specific to AIX, and raise (emulate) an OSError when there is a trailing slash and the pathname is a file.

In short, the simple resolution - without impacting core in any way is:
diff --git a/Lib/test/test_httpservers.py b/Lib/test/test_httpservers.py
index cc829a522b..31be9b4479 100644
--- a/Lib/test/test_httpservers.py
+++ b/Lib/test/test_httpservers.py
@@ -13,6 +13,7 @@ import sys
 import re
 import base64
 import ntpath
+import platform
 import shutil
 import email.message
 import email.utils
@@ -29,6 +30,7 @@ from io import BytesIO
 import unittest
 from test import support

+AIX = platform.system() == 'AIX'

 class NoLogRequestHandler:
     def log_message(self, *args):
@@ -417,9 +419,11 @@ class SimpleHTTPServerTestCase(BaseTestCase):
         #constructs the path relative to the root directory of the HTTPServer
         response = self.request(self.base_url + '/test')
         self.check_status_and_reason(response, HTTPStatus.OK, data=self.data)
-        # check for trailing "/" which should return 404. See Issue17324
-        response = self.request(self.base_url + '/test/')
-        self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
+        # AIX open() will open a filename with a trailing slash - as a file
+        if not AIX:
+            # check for trailing "/" which should return 404. See Issue17324
+            response = self.request(self.base_url + '/test/')
+            self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
         response = self.request(self.base_url + '/')
         self.check_status_and_reason(response, HTTPStatus.OK)
         response = self.request(self.base_url)
@@ -519,8 +523,9 @@ class SimpleHTTPServerTestCase(BaseTestCase):
     def test_path_without_leading_slash(self):
         response = self.request(self.tempdir_name + '/test')
         self.check_status_and_reason(response, HTTPStatus.OK, data=self.data)
-        response = self.request(self.tempdir_name + '/test/')
-        self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
+        if not AIX:
+            response = self.request(self.tempdir_name + '/test/')
+            self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
         response = self.request(self.tempdir_name + '/')
         self.check_status_and_reason(response, HTTPStatus.OK)
         response = self.request(self.tempdir_name)

Comments!

----------
components: Tests
messages: 325519
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Fix test_httpservers on AIX
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:25:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 10:25:38 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1537179938.82.0.956365154283.issue26544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems the only difference between PR 8952 and PR 9062 is additional tests. This is not important.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:44:04 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 17 Sep 2018 10:44:04 +0000
Subject: [issue22851] 2.7 core crashes with generator.gi_frame.f_restricted
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1537181044.8.0.956365154283.issue22851@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8771
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:44:29 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 17 Sep 2018 10:44:29 +0000
Subject: [issue22851] 2.7 core crashes with generator.gi_frame.f_restricted
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1537181069.31.0.956365154283.issue22851@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:47:55 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 17 Sep 2018 10:47:55 +0000
Subject: [issue34711] Fix test_httpservers on AIX
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1537181275.78.0.956365154283.issue34711@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

This is also an issue on Windows when the target path resides within a junction, paths outside of a junction respond (err, fail) as expected.

https://developercommunity.visualstudio.com/content/problem/272379/createfile-non-error-on-filename-with-trailing-bac.html

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:24:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 11:24:06 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537183446.08.0.956365154283.issue34610@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e0e5065daef36dafe10a46eaa8b7800274d73062 by Serhiy Storchaka in branch 'master':
bpo-34610: Fixed iterator of multiprocessing.managers.DictProxy. (GH-9113)
https://github.com/python/cpython/commit/e0e5065daef36dafe10a46eaa8b7800274d73062


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:24:27 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 11:24:27 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537183467.24.0.956365154283.issue34610@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8772

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:24:38 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 11:24:38 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537183478.42.0.956365154283.issue34610@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8773

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:35:39 2018
From: report at bugs.python.org (Christian Tismer)
Date: Mon, 17 Sep 2018 11:35:39 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537184139.14.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

> ... Specifically, you need a way to create class with a metaclass, from C.
> 
> Is that right? Or was this only an example of a larger problem?

Yes, you are exactly right. I needed access to very few fields.
In particular:

    PyTypeObject.tp_init
    PyTypeObject.tp_basicsize    (workaround using Python)

    <a_few_types>.tp_dict

The latter would not be necessary for Pep 384, but for my __signature__
extension, but that is another story :)

<basicsize>

> Well, basicsize might be exposed through Python, but it's still not
> part of the limited API. Which is fine ? all that means is you might
> need to change the extension for some future version of Python.

Oh? I thought it is automatically allowed to use if it is exposed
by Python. I thought that the central property of basicsize would be
that it is no longer a constant, but that a size is always there.

Sure, we could have worked without the size and create a more complex 
structure that does not know anything about types. I actually started
with that approach. But in the end I thought it would not hurt to assume 
that there is a (variable) size, as long as we are below Python 4.0 .

> I'm sure your tests will tell you when the time comes, and I hope we'll
> have a better solution then!

Yes, I had a very hard time to convince myself that I _may_ use some
assumptions, as long as I always prove that these assumptions are right.
But in a way, I feel guilty and would prefer to go without any trickery.

> BTW, I'm honestly very impressed how far PySide got with the limited API!

Thank you! I was hoping to get ready after 2 months, when I realized that 
all types needed to be changed. So I pulled teeth, and it took >5 months.
Btw., I don't understand how the PyQt5 guy(s) solved this. Maybe his 
structure is way cleaner and simpler than the PySide mess? I'll ask him.

Ciao -- Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:48:46 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 17 Sep 2018 11:48:46 +0000
Subject: [issue34707] Python not reentrant
In-Reply-To: <1537149875.51.0.956365154283.issue34707@psf.upfronthosting.co.za>
Message-ID: <1537184926.53.0.956365154283.issue34707@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think this is along the lines of a recent discussion on the c-api mailing list about passing a context value (your handle) to every C call. See this message for some discussion: https://mail.python.org/mm3/archives/list/capi-sig at python.org/message/ZN6BJVUGIOGWKHY47PKPX5Z3SGCYUAX5/

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34707>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:53:36 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Sep 2018 11:53:36 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537185216.81.0.956365154283.issue34710@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset b3a271fc0ce3e13e427be8914decfc205a220ca8 by Christian Heimes (Alexandru Ardelean) in branch 'master':
bpo-34710: fix SSL module build (GH-9347)
https://github.com/python/cpython/commit/b3a271fc0ce3e13e427be8914decfc205a220ca8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:53:44 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 11:53:44 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537185224.97.0.956365154283.issue34710@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8774

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:53:55 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 11:53:55 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537185235.56.0.956365154283.issue34710@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8775

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 07:57:54 2018
From: report at bugs.python.org (Christian Tismer)
Date: Mon, 17 Sep 2018 11:57:54 +0000
Subject: [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537185474.48.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

If somebody is interested to see how the transition to the
Limited API was done, here is the documentation that I was
forced to write :)

https://github.com/pyside/pyside2-setup/blob/5.11/sources/shiboken2/libshiboken/pep384impl_doc.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:04:18 2018
From: report at bugs.python.org (john skaller)
Date: Mon, 17 Sep 2018 12:04:18 +0000
Subject: [issue34707] Python not reentrant
In-Reply-To: <1537149875.51.0.956365154283.issue34707@psf.upfronthosting.co.za>
Message-ID: <1537185858.21.0.956365154283.issue34707@psf.upfronthosting.co.za>


john skaller <skaller at users.sourceforge.net> added the comment:

eric: yes, that's relevant. Very happy it is discussed.

Contrary to some indication in the post, passing a context handle around everywhere is NOT a burden at all. My system does exactly that.

I would note, API's which already require, say, an interpreter handle, don't require any modification.

Also, I would note, legacy API's do not have to be broken, you just have a single, legacy, global variable holding the default context, and deprecate any functions using it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34707>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:11:02 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:11:02 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537186262.23.0.956365154283.issue34610@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1d3078849381335008379e3de96d5a81d2131113 by Miss Islington (bot) in branch '3.7':
bpo-34610: Fixed iterator of multiprocessing.managers.DictProxy. (GH-9113)
https://github.com/python/cpython/commit/1d3078849381335008379e3de96d5a81d2131113


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:11:07 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:11:07 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537186267.59.0.956365154283.issue34610@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f35e4d5851555d66f1e7a36b2a37f0d82b3d1706 by Miss Islington (bot) in branch '3.6':
bpo-34610: Fixed iterator of multiprocessing.managers.DictProxy. (GH-9113)
https://github.com/python/cpython/commit/f35e4d5851555d66f1e7a36b2a37f0d82b3d1706


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:15:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:15:07 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186507.11.0.956365154283.issue33216@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5e99b56d6b249995a4fa2bc09c0bb03841f49572 by Serhiy Storchaka in branch 'master':
bpo-33216: Improve the documentation for CALL_FUNCTION_* (GH-8338) (GH-8784)
https://github.com/python/cpython/commit/5e99b56d6b249995a4fa2bc09c0bb03841f49572


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:15:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Sep 2018 12:15:16 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537186516.8.0.956365154283.issue34710@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8776

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:15:20 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:15:20 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186520.39.0.956365154283.issue33216@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8777

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:15:31 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:15:31 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186531.27.0.956365154283.issue33216@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8778

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:15:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:15:51 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186551.16.0.956365154283.issue33216@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset afa591d7748c66831e6e650108024f3293be33f1 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-33216: Clarify the documentation for CALL_FUNCTION_* (GH-8338) (GH-8783)
https://github.com/python/cpython/commit/afa591d7748c66831e6e650108024f3293be33f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:16:04 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 17 Sep 2018 12:16:04 +0000
Subject: [issue34711] Fix test_httpservers on AIX
In-Reply-To: <1537181275.78.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <ada9bf32-7002-28ac-f7a8-2cbaa3c380d3@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 17/09/2018 12:47, Jeremy Kloth wrote:
> Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:
>
> This is also an issue on Windows when the target path resides within a junction, paths outside of a junction respond (err, fail) as expected.
>
> https://developercommunity.visualstudio.com/content/problem/272379/createfile-non-error-on-filename-with-trailing-bac.html
:) Glad to hear I am not the only one facing this. However, looking at
the standard - it looks like it may be "a bug". Not the easiest to read,
but my understanding of this leans to calling opening a file using
"/some/path/to/file/" is wrong:

[ENOTDIR]
    A component of the path prefix names an existing file that is
    neither a directory nor a symbolic link to a directory; or O_CREAT
    and O_EXCL are not specified, the /path/ argument contains at least
    one non- <slash> character and ends with one or more trailing
    <slash> characters, and the last pathname component names an
    existing file that is neither a directory nor a symbolic link to a
    directory; or O_DIRECTORY was specified and the /path/ argument
    resolves to a non-directory file.

from http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

> ----------
> nosy: +jkloth
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34711>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:17:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:17:32 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
 lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1537186652.98.0.956365154283.issue12458@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset da8d72c953369b872a12c13f136ada77a786714a by Serhiy Storchaka in branch 'master':
bpo-12458: Fix line numbers for multiline expressions. (GH-8774)
https://github.com/python/cpython/commit/da8d72c953369b872a12c13f136ada77a786714a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:18:26 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:18:26 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537186706.13.0.956365154283.issue34710@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e2c0aea670d603b187733606a4601d77f355bc47 by Miss Islington (bot) in branch '3.7':
bpo-34710: fix SSL module build (GH-9347)
https://github.com/python/cpython/commit/e2c0aea670d603b187733606a4601d77f355bc47


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:19:11 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:19:11 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537186751.61.0.956365154283.issue34710@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fff869e2a0ee3d2d65973d82e57f05479828f5a3 by Miss Islington (bot) in branch '3.6':
bpo-34710: fix SSL module build (GH-9347)
https://github.com/python/cpython/commit/fff869e2a0ee3d2d65973d82e57f05479828f5a3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:36:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:36:45 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537187805.72.0.956365154283.issue34341@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9bdb7be482aef8f60daa1d36606568a132dcb616 by Serhiy Storchaka in branch 'master':
bpo-34341: Fix appending to ZIP archives with the ZIP64 extension. (GH-8683)
https://github.com/python/cpython/commit/9bdb7be482aef8f60daa1d36606568a132dcb616


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:36:54 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:36:54 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537187814.8.0.956365154283.issue34341@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8779

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:37:04 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:37:04 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537187824.27.0.956365154283.issue34341@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8780

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:41:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:41:55 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537188115.81.0.956365154283.issue33216@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Larry for your rewriting.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:43:02 2018
From: report at bugs.python.org (=?utf-8?b?VGhvbWFzIEdsw6TDn2xl?=)
Date: Mon, 17 Sep 2018 12:43:02 +0000
Subject: [issue34624] -W option does not accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1537188182.91.0.956365154283.issue34624@psf.upfronthosting.co.za>


Change by Thomas Gl??le <thomas at coldfix.de>:


----------
keywords: +patch
pull_requests: +8781
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:43:34 2018
From: report at bugs.python.org (=?utf-8?b?VGhvbWFzIEdsw6TDn2xl?=)
Date: Mon, 17 Sep 2018 12:43:34 +0000
Subject: [issue34624] -W option does not accept module regexes
In-Reply-To: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>
Message-ID: <1537188214.79.0.956365154283.issue34624@psf.upfronthosting.co.za>


Thomas Gl??le <thomas at coldfix.de> added the comment:

Thanks for your response. I have opened a PR at [1] that would remove the re.escape such that the implementation matches the documentation if you decide that this is fine.

[1]: https://github.com/python/cpython/pull/9358

Personally, I would go even further and always add the `(\..*)?$` suffix (instead of only `$`) to make it easier to match all modules in a package which is probably the most important use-case for the case of packages. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34624>
_______________________________________

From report at bugs.python.org  Mon Sep 17 08:52:44 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 12:52:44 +0000
Subject: [issue23278] multiprocessing maxtasksperchild=1 + logging = task loss
In-Reply-To: <1421719372.42.0.719053884187.issue23278@psf.upfronthosting.co.za>
Message-ID: <1537188764.85.0.956365154283.issue23278@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23278>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:08:53 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:08:53 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537189733.27.0.956365154283.issue34341@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset efdf316d23c2bc81f499c46faaba5e1b49509afa by Miss Islington (bot) in branch '3.7':
bpo-34341: Fix appending to ZIP archives with the ZIP64 extension. (GH-8683)
https://github.com/python/cpython/commit/efdf316d23c2bc81f499c46faaba5e1b49509afa


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:09:37 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:09:37 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537189777.07.0.956365154283.issue33216@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f8e34eee74871b3343f6c3545bce41242ba378e8 by Miss Islington (bot) in branch '3.7':
bpo-33216: Improve the documentation for CALL_FUNCTION_* (GH-8338) (GH-8784)
https://github.com/python/cpython/commit/f8e34eee74871b3343f6c3545bce41242ba378e8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:09:45 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:09:45 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537189785.67.0.956365154283.issue33216@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1e7193bd027a5a4aa1a387e3f201a3e465c25f01 by Miss Islington (bot) in branch '3.6':
bpo-33216: Improve the documentation for CALL_FUNCTION_* (GH-8338) (GH-8784)
https://github.com/python/cpython/commit/1e7193bd027a5a4aa1a387e3f201a3e465c25f01


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:11:32 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 13:11:32 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537189892.93.0.956365154283.issue34683@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:11:46 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:11:46 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537189906.19.0.956365154283.issue34341@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 83a0985165abf340294c10d732840e9d46ba218c by Miss Islington (bot) in branch '3.6':
bpo-34341: Fix appending to ZIP archives with the ZIP64 extension. (GH-8683)
https://github.com/python/cpython/commit/83a0985165abf340294c10d732840e9d46ba218c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:37:42 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 17 Sep 2018 13:37:42 +0000
Subject: [issue34676] Guarantee that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1537191462.35.0.956365154283.issue34676@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

@Serhiy I like the "convert to a tuple" idea before returning *better*, though I think I'd prefer to just check that it's tuple-like, something like:

    if not all(hasattr(return_val, attr) for attr in ['__getitem__', '__len__']) or len(return_val) != 2:
        warnings.warn("divmod must return a Sequence of length 2. " +
                      "This will be an exception in Python 3.9+",
                      Deprecationwarning)

Or some similar equivalent to `if not isinstance(return_val, collections.abc.Sequence) or len(return_val) != 2`.

That said, the PR seems to have already run into an issue, which is that `unittest.mock.MagicMock` returns a `unittest.mock.MagicMock` from `divmod`, which is not a 2-tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:42:41 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:42:41 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537191761.6.0.956365154283.issue34710@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5f883fcb9b50b8335953b3849b7f224d5cd59d56 by Miss Islington (bot) (Christian Heimes) in branch '2.7':
[2.7] bpo-34710: fix SSL module build (GH-9347) (GH-9353)
https://github.com/python/cpython/commit/5f883fcb9b50b8335953b3849b7f224d5cd59d56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:56:06 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 17 Sep 2018 13:56:06 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1537192566.95.0.956365154283.issue31635@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

@Serhiy Looking more closely at #13414, I think there's a good chance that we've just discovered a different bug in OpenBSD's implementation of wcsftime (or strftime). Looks like OpenBSD 6.1 was released in 2017, which should have been years after the fix from #13414 was released.

It seems that OpenBSD does not have a bug tracker per se, and I can't see if this bug has been reported. I can try to install OpenBSD in a VM later and try to reproduce it, but if it's a bug in OpenBSD, I see some possible options:

1. Add an exception to the test suite on OpenBSD (to be removed or pinned when it's fixed in OpenBSD)

2. If the bug is just in wcsftime and not in strftime, it may be fixed by switching to using strftime as is done on Windows: https://github.com/python/cpython/blob/master/Modules/timemodule.c#L673

I have never tested it, but it's possible this will impact performance, and if it's a bad enough hit it may not be worth sacrificing general performance to avoid a bug in a corner case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Mon Sep 17 09:57:13 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 17 Sep 2018 13:57:13 +0000
Subject: [issue34711] return ENOTDIR when open() accepts filenames with a
 trailing slash
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1537192633.03.0.956365154283.issue34711@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
components: +IO
title: Fix test_httpservers on AIX -> return ENOTDIR when open() accepts filenames with a trailing slash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 10:00:47 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 17 Sep 2018 14:00:47 +0000
Subject: [issue34711] return ENOTDIR when open() accepts filenames with a
 trailing slash
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1537192847.87.0.956365154283.issue34711@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

OK - issue17324 (not 1 7 2 3 4)

And, as jkloth reported that Windows also has an issue - sometimes, found a way to do this in Modules/_io/fileio.c

diff --git a/Modules/_io/fileio.c b/Modules/_io/fileio.c
index c0e43e0ae4..3623ff16ea 100644
--- a/Modules/_io/fileio.c
+++ b/Modules/_io/fileio.c
@@ -228,6 +228,7 @@ _io_FileIO___init___impl(fileio *self, PyObject *nameobj, const char *mode,
 #endif
     PyObject *stringobj = NULL;
     const char *s;
+    char *rcpt;
     int ret = 0;
     int rwa = 0, plus = 0;
     int flags = 0;
@@ -447,6 +448,23 @@ _io_FileIO___init___impl(fileio *self, PyObject *nameobj, const char *mode,
         }
     }
     else {
+#if defined(S_ISREG) && defined(ENOTDIR)
+        /* On AIX and Windows, open may succeed for files with a trailing slash.
+           The Open Group specifies filenames ending with a trailing slash should
+           be an error - ENOTDIR */
+        if (S_ISREG(fdfstat.st_mode)) {
+#ifdef MS_WINDOWS
+                rcpt= strrch(widename, '\');
+#else
+               rcpt = strrchr(name, '/');
+#endif
+                if ((rcpt != NULL) && (strlen(rcpt) == 1)) {
+                   errno = ENOTDIR;
+                   PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError, nameobj);
+                   goto error;
+               }
+       }
+#endif
 #if defined(S_ISDIR) && defined(EISDIR)
         /* On Unix, open will succeed for directories.
            In Python, there should be no file objects referring to

And, now for the PR tests...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 10:01:41 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 17 Sep 2018 14:01:41 +0000
Subject: [issue34711] return ENOTDIR when open() accepts filenames with a
 trailing slash
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1537192901.39.0.956365154283.issue34711@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8782
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 10:30:13 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Sep 2018 14:30:13 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537194613.57.0.956365154283.issue34710@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 10:30:27 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Sep 2018 14:30:27 +0000
Subject: [issue34710] SSL Module build fails with more pedantic compiler flags
In-Reply-To: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>
Message-ID: <1537194627.6.0.956365154283.issue34710@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34710>
_______________________________________

From report at bugs.python.org  Mon Sep 17 10:46:13 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Mon, 17 Sep 2018 14:46:13 +0000
Subject: [issue30455] Generate C code from token.py and not vice versa
In-Reply-To: <1495628509.86.0.512362155714.issue30455@psf.upfronthosting.co.za>
Message-ID: <1537195573.0.0.956365154283.issue30455@psf.upfronthosting.co.za>


Change by Emily Morehouse <emilyemorehouse at gmail.com>:


----------
pull_requests: +8783

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30455>
_______________________________________

From report at bugs.python.org  Mon Sep 17 11:41:58 2018
From: report at bugs.python.org (Eric Snow)
Date: Mon, 17 Sep 2018 15:41:58 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1537198918.45.0.956365154283.issue33608@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@Neil, we're definitely on the same page.  In fact, in a world where subinterpreters do not share a GIL, we can't ever use an object in one interpreter that was created in another (due to thread safety on refcounts).  The role of "tightly controlling" passing/sharing objects (for a very loose definition of "sharing") falls to the channels described in PEP 554. [1]

However, there are several circumstances where interpreters may collaborate that involves one holding a reference (but not using it) to an object owned by the other.  For instance, see PyBuffer_Release(). [2]  This issue is about addressing that situation safely.  It is definitely not about safely using objects from other interpreters.

[1] The low-level implementation, including channels, already exists in Modules/_xxsubinterpretersmodule.c.
[2] https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_Release

----------
assignee:  -> eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Mon Sep 17 11:54:30 2018
From: report at bugs.python.org (Eric Snow)
Date: Mon, 17 Sep 2018 15:54:30 +0000
Subject: [issue34707] Python not reentrant
In-Reply-To: <1537149875.51.0.956365154283.issue34707@psf.upfronthosting.co.za>
Message-ID: <1537199670.41.0.956365154283.issue34707@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Also see PEP 432 ("Restructuring the CPython startup sequence"), which is still in the process of fine-tuning.

----------
nosy: +eric.snow, ncoghlan, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34707>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:36:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 16:36:30 +0000
Subject: [issue34711] return ENOTDIR when open() accepts filenames with a
 trailing slash
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1537202190.6.0.956365154283.issue34711@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:36:31 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:36:31 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
Message-ID: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>


New submission from Ben Hoyt <benhoyt at gmail.com>:

There are a couple of examples in the "Input and Output" section of the tutorial that use an unusual / non-PEP 8 Python style or whitespace. I think our examples, especially in the tutorial, should reflect good, PEP 8 style. I'll fix these in a PR which I'll attach soon.

----------
assignee: docs at python
components: Documentation
messages: 325550
nosy: akuchling, benhoyt, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Style fixes in examples of "Input and Output" tutorial section
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:37:05 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:37:05 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537202225.55.0.956365154283.issue34712@psf.upfronthosting.co.za>


Change by Ben Hoyt <benhoyt at gmail.com>:


----------
keywords: +patch
pull_requests: +8784
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:37:51 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:37:51 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537202271.53.0.956365154283.issue34712@psf.upfronthosting.co.za>


Ben Hoyt <benhoyt at gmail.com> added the comment:

GitHub PR link with changes and commit notes attached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:53:37 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 17 Sep 2018 16:53:37 +0000
Subject: [issue30140] Binary arithmetic does not always call subclasses first
In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za>
Message-ID: <1537203217.62.0.956365154283.issue30140@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

If anyone cares, here's what I recall of the history of this feature.

Originally my design was just

1. try left arg's __op__
2. if that returns NotImplemented, try right arg's __rop__

That's simple to explain and usually works. But when thinking through edge cases, we found that if the right class is a subclass of the left class, this gives unexpected results, so we added the exception

0. if the right class subclasses the left class *and it overrides __rop__*, try that first

I honestly believe that I didn't realize that it could ever matter if the right class subclasses the left class *without overriding __rop__*. And nobody else realized it either.

I think we decided on the "right class must override __rop__" condition in part to preserve the original, simpler rules for cases where we thought they would suffice, in part because for most users trying __rop__ before __op__ is unexpected, and in part because we didn't realize that it mattered.

And it only matters if the base class uses something like type(self) or self.__class__, which as a design pattern is sometimes dubious and other times useful.

Also note that the language Stephan quoted is somewhat different: it uses "provides" (__rop__) instead of "overrides". I could imagine that this, again, was a difference too subtle for most folks to notice.

If I had to do it over, I agree that if the right class subclasses the left class, we should always try __rop__ first. But now that this has been an ingrained behavior for so long I worry that it will break existing code, esp. in cases where there is an asymmetry between __op__ and __rop__ and the class author did not expect __rop__ ever to be called first.

Whether that's enough to stop this PR I think this is a question for the next BDFL to decide, alas. (I don't think it requires a PEP, it just requires someone to decide.)

----------
nosy: +gvanrossum
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30140>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:55:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 16:55:04 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537203304.31.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'd strongly prefer to just go back to the PEP 538 design. It's much simpler to implement, we don't actually want anyone turning off locale coercion except for debugging purposes (unlike UTF-8 mode), and the only argument against doing this the way PEP 538 describes is a purist one, not a practical one (which was already resolved in favour of practicality when PEP 538 was accepted).
> (...)
> That's quite a bit of code to add for the sake of a flag we don't really want anyone to ever use, though. (If it hadn't been for the debugging-CentOS-7-problems-on-Fedora issue, I doubt I would have included the off switch in PEP 538 at all)

Why did you add PYTHONCOERCECLOCALE=warn if you don't want that people use it?

> The actual functional error is that the following will currently give different outputs on Fedora and CentOS 7, whereas in the original PEP 538 implementation it would always print "C", even if locale coercion would otherwise normally work on your current platform:
>
>    LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -E -c 'import os; print(os.env["LC_CTYPE"])'

You wrote that we need PYTHONCOERCECLOCALE=0 and then that we don't need it, I don't understand :-)

IMHO there are use cases where PYTHONCOERCECLOCALE=0 is important, that's why I propose to add -X coerce_c_locale=0.

There are also cases where you want the warning, so -X coerce_c_locale=warn would help as well, when -E or -I is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 12:58:28 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 16:58:28 +0000
Subject: [issue34691] _contextvars missing in x64 master branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1537203508.74.0.956365154283.issue34691@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

It looks like _contextvars has both its own project and is also built as part of pythoncore.vcxproj.

However, _contextvars.vcxproj is not in PCbuild.sln, which means when you build through Visual Studio (rather than with build.bat via pcbuild.proj), you don't get the separate extension module.

And even though it's built into pythoncore.vcxproj, it hasn't been added to PC/config.c, and so it isn't initialised as a regular builtin module.

Yury - is there a specific reason for it to be a standalone module? How much do you think it hurts to have it always loaded into memory, even if it hasn't truly been imported or used?

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Mon Sep 17 13:00:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 17:00:23 +0000
Subject: [issue34691] _contextvars missing in x64 master branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1537203623.65.0.956365154283.issue34691@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> How much do you think it hurts to have it always loaded into memory, even if it hasn't truly been imported or used?

I'd be fine with that.  Would you be able to do the necessary change (I don't have VS at hand)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Mon Sep 17 13:14:05 2018
From: report at bugs.python.org (Nicholas Chammas)
Date: Mon, 17 Sep 2018 17:14:05 +0000
Subject: [issue34713] csvwriter.writerow()'s return type is undocumented
Message-ID: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>


New submission from Nicholas Chammas <nicholas.chammas at gmail.com>:

It _looks_ like csvwriter.writerow() returns the number of bytes (or is it characters?) written. However, there is no documentation of this:

https://docs.python.org/3.7/library/csv.html#csv.csvwriter.writerow

Is this behavior part of the method's "contract"? And if so, shouldn't we document it?

The same goes for csvwriter.writerows().

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 325557
nosy: docs at python, nchammas
priority: normal
severity: normal
status: open
title: csvwriter.writerow()'s return type is undocumented
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34713>
_______________________________________

From report at bugs.python.org  Mon Sep 17 13:20:25 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Mon, 17 Sep 2018 17:20:25 +0000
Subject: [issue34688] Segfault in pandas that works fine on 3.7
In-Reply-To: <1536954749.8.0.956365154283.issue34688@psf.upfronthosting.co.za>
Message-ID: <1537204825.93.0.956365154283.issue34688@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

somewhat shortened repro that fails with the same error on master:
```
import pandas
import numpy

now = pandas.Timestamp.now()
arr = numpy.array([ ['a', now] for i in range(0, 3)])
arr.sum(0)
```

----------
nosy: +v2m

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34688>
_______________________________________

From report at bugs.python.org  Mon Sep 17 13:20:27 2018
From: report at bugs.python.org (Nicholas Chammas)
Date: Mon, 17 Sep 2018 17:20:27 +0000
Subject: [issue34713] csvwriter.writerow()'s return type is undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1537204827.52.0.956365154283.issue34713@psf.upfronthosting.co.za>


Nicholas Chammas <nicholas.chammas at gmail.com> added the comment:

Looks like it's bytes written, not characters:

```
>>> import csv
>>> with open('test.csv', 'w', newline='') as csv_file:
...     csv_writer = csv.writer(
...         csv_file,
...         dialect='unix',
...     )
...     csv_writer.writerow('? ?')  # 3 characters
... 
12
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34713>
_______________________________________

From report at bugs.python.org  Mon Sep 17 13:22:22 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 17:22:22 +0000
Subject: [issue34691] _contextvars missing in x64 master branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1537204942.46.0.956365154283.issue34691@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Shouldn't need VS for this change (updating the SLN file generally does need it). I'm happy to do it though.

In case someone else gets to it before me:
* delete _contextvars.vcxproj and remove all references from PCbuild and Tools/msi
* add _contextvars entries to PC/config.c

The CI builds will tell you pretty quickly if it worked or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Mon Sep 17 13:53:11 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Mon, 17 Sep 2018 17:53:11 +0000
Subject: [issue34689] Lib/sysconfig.py expands non-variables
In-Reply-To: <1536955893.22.0.956365154283.issue34689@psf.upfronthosting.co.za>
Message-ID: <1537206791.89.0.956365154283.issue34689@psf.upfronthosting.co.za>


Change by Erwan Le Pape <lepaperwan3 at gmail.com>:


----------
keywords: +patch
pull_requests: +8786
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34689>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:29:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 18:29:56 +0000
Subject: [issue34688] Segfault in pandas that works fine on 3.7
In-Reply-To: <1536954749.8.0.956365154283.issue34688@psf.upfronthosting.co.za>
Message-ID: <1537208996.91.0.956365154283.issue34688@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Pandas issue that contains other segfaults : https://github.com/pandas-dev/pandas/issues/22714

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34688>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:31:10 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 18:31:10 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537209070.79.0.956365154283.issue34712@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:31:11 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 18:31:11 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537209071.67.0.956365154283.issue17239@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Ned - I don't think this is necessarily a release blocker, as we've been shipping it for a long time, but it would be nice if we can hold 3.7.1rc1 just long enough to get it in (provided Christian jumps in and says he'll get the last minor concerns on the PRs wrapped up very soon)

----------
nosy: +ned.deily, steve.dower
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:31:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 18:31:58 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537209118.84.0.956365154283.issue34683@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:33:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 18:33:27 +0000
Subject: [issue34713] csvwriter.writerow()'s return type is undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1537209207.24.0.956365154283.issue34713@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34713>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:34:59 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 18:34:59 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1537209299.13.0.956365154283.issue32533@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset c6fd1c1c3a65217958b68df3a4991e4f306e9b7d by Steve Dower in branch 'master':
bpo-32533: Fixed thread-safety of error handling in _ssl. (GH-7158)
https://github.com/python/cpython/commit/c6fd1c1c3a65217958b68df3a4991e4f306e9b7d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:35:05 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 18:35:05 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1537209305.75.0.956365154283.issue32533@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8787

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Mon Sep 17 14:42:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 18:42:08 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537209728.74.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8788

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:06:27 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:06:27 +0000
Subject: [issue34714] timeout in test_multiprocessing_spawn x86 Windows7 3.x
 buildbot
Message-ID: <1537211187.89.0.956365154283.issue34714@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

https://buildbot.python.org/all/#/builders/58/builds/1338/steps/3/logs/stdio

Timeout (0:15:00)!
Thread 0x000009d8 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\popen_spawn_win32.py", line 91 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\process.py", line 140 in join
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 612 in test_error_on_stdio_flush_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 610 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 658 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1900 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1990 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 179 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\__main__.py", line 2 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 192 in _run_module_as_main
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\spawn.py", line 107, in spawn_main
    new_handle = reduction.duplicate(pipe_handle,
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\reduction.py", line 79, in duplicate
    return _winapi.DuplicateHandle(
PermissionError: [WinError 5] Access is denied

----------
components: Tests, Windows
messages: 325564
nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: timeout in test_multiprocessing_spawn x86 Windows7 3.x buildbot
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34714>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:12:22 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 19:12:22 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1537211542.41.0.956365154283.issue32533@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1229664f30dd5fd4da32174a19258f8312464d45 by Miss Islington (bot) in branch '3.7':
bpo-32533: Fixed thread-safety of error handling in _ssl. (GH-7158)
https://github.com/python/cpython/commit/1229664f30dd5fd4da32174a19258f8312464d45


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:32:14 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:32:14 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
Message-ID: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Example:

https://buildbot.python.org/all/#/builders/87/builds/1434

./Modules/timemodule.c:573:24: warning: assigning to 'char *' from 'const char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
            p->tm_zone = PyUnicode_AsUTF8(item);
                       ^ ~~~~~~~~~~~~~~~~~~~~~~
./Modules/timemodule.c:1545:44: warning: incompatible pointer to integer conversion passing 'char *(int, int)' to parameter of type 'long' [-Wint-conversion]
    PyModule_AddIntConstant(m, "timezone", timezone);
                                           ^~~~~~~~
./Include/modsupport.h:118:71: note: passing argument to parameter here
PyAPI_FUNC(int) PyModule_AddIntConstant(PyObject *, const char *, long);
                                                                      ^
./Modules/timemodule.c:1568:44: error: use of undeclared identifier 'daylight'
    PyModule_AddIntConstant(m, "daylight", daylight);
                                           ^
2 warnings and 1 error generated.
*** [Modules/timemodule.o] Error code 1
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd10/build
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd10/build
1 error

----------
components: Build, FreeBSD
messages: 325566
nosy: koobs, pablogsal
priority: normal
severity: normal
status: open
title: timemodule.c fails to compile on BSD
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:32:33 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:32:33 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537212753.67.0.956365154283.issue34715@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Bisecting returns commit 5633c4f342d as possible culprit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:35:29 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 19:35:29 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537212929.11.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 394374e30c85f6eacddbbfc7471aab62b54ce021 by Yury Selivanov in branch 'master':
bpo-33649: Add low-level APIs index. (GH-9364)
https://github.com/python/cpython/commit/394374e30c85f6eacddbbfc7471aab62b54ce021


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:38:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Sep 2018 19:38:09 +0000
Subject: [issue34708] Odd crashes/freezes when sys.stdout.shell.console is
 typed
In-Reply-To: <1537152781.74.0.956365154283.issue34708@psf.upfronthosting.co.za>
Message-ID: <1537213089.17.0.956365154283.issue34708@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.4 and 3.5 only get security fixes and I doubt this qualifies.

I reproduced the described behavior with 3.7 on Win 10, so it is not Mac-specific.

Python sys.stdout: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
IDLE's sys.stdout: <idlelib.run.PseudoOutputFile object at 0x00000246821B1E10>
The PseudoFiles are unusual in being internal objects accessible from user code.

Comparing attributes with public names (not starting with single or double underscore) PseudoOutputFile lacks buffer, line_buffering, mode, reconfigure, and write_through.  #21995 is about fixing or documenting each omission for all 3 streams.

PseudoFiles add shell and tags.  Both should have private names that warn users that their behavior is undocumented and usage is at one's own risk.  'shell' should be double underscored. This minimal fix would be sufficient to close this issue.  Some manual testing should be sufficient for such a change.

'Tags' should be singular, as it is one of 'stdin', 'stdout', or 'stderr'.  The tag is used in the write method to tell Shell whether to display with the configured stdout or stderr colors.

Shell is an idlelib.rpc.RPCProxy object.  As an object in itself, in the run process, it has 2 public attributes: oid ('console') and sockio (an  idlelib.run.MyHandler object).  But as a proxy representing the Shell console object in the IDLE process, it supposedly 'has' all the attributes of the latter.  These are accessed with a custom __getattr__.

    def __getattr__(self, name):
        if self.__methods is None:
            self.__getmethods()
        if self.__methods.get(name):
            return MethodProxy(self.sockio, self.oid, name)
        if self.__attributes is None:
            self.__getattributes()
        if name in self.__attributes:
            value = self.sockio.remotecall(self.oid, '__getattribute__',
                                           (name,), {})
            return value
        else:
            raise AttributeError(name)

Note that self.__attributes is mangled to shell._RPCProxy__attributes when accessed externally.  (Also, it is a set still implemented in this ancient code as a dict with int 1 values.)

More importantly, remote calls to the Shell console can only pass and return objects that can be pickled, and there is currently no provision for graceful failure.  Hence sys.stdout.shell.width is (for me, currently) 80, but .console or .stdout are impossible to return.

I am extremely dubious about trying to fix this in the IDLE side of the link.  Instead, the proxy should be initialized with sets of known usable attributes and methods.  I think the underlying problem is trying to be unnecessarily and impossibly generic.  Run only calls the .readline, .write, and .close methods of the console proxy.  It only calls stack viewer setup on the interp proxy.  A third proxy, for flist, is passed to the stack viewer (I have not yet checked what is needed for that).  Restricting proxies to things that are needed and *should* work would make it more feasible to test them.  But setting up automated tests would still require some work.

----------
stage:  -> needs patch
versions: +Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34708>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:40:22 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:40:22 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537213222.03.0.956365154283.issue34715@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:41:18 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 Sep 2018 19:41:18 +0000
Subject: [issue30140] Binary arithmetic does not always call subclasses first
In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za>
Message-ID: <1537213278.21.0.956365154283.issue30140@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/issue30140>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:42:00 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Mon, 17 Sep 2018 19:42:00 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1537213320.78.0.956365154283.issue34686@psf.upfronthosting.co.za>


Erwan Le Pape <lepaperwan3 at gmail.com> added the comment:

Given that marshal basically only just dumps code objects, the only viable solution I can see is adding a flag that can be passed all the way to the AST from `Python/bltinmodule.c:builtin_compile_impl` that would sort elements when creating code objects of unordered types.

This could be automatically enabled when compiling a file if we assume imported files are trustworthy or add a flag to the `Lib/compileall.py` module.

I only fear that this might break compiled code objects that make use of unordered types. Since I haven't sifted through the AST internals and the implications of such a change yet, so this is largely up for debate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:45:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 19:45:58 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
Message-ID: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

It is documented, that divmod() returns a pair. It is usually used with tuple unpacking:

    x, y = divmod(a, b)

But this doesn't work when one of arguments is a MagicMock.

>>> from unittest.mock import *
>>> x, y = divmod(MagicMock(), 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not enough values to unpack (expected 2, got 0)

I expect that tuple unpacking will work with the result of MagicMock.__divmod__(). There possible following options:

1. Return some constant value, e.g. (1, 0).

2. Return a pair of new MagicMock instances.

3. Define __divmod__ in terms of __floordiv__ and __mod__. This will automatically return a pair of MagicMock instances by default, but setting return values for __floordiv__ and __mod__ will affect the result of __divmod__.

What is more preferable?

----------
components: Library (Lib)
messages: 325571
nosy: michael.foord, serhiy.storchaka
priority: normal
severity: normal
status: open
title: MagicMock.__divmod__ should return a pair
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:49:37 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 17 Sep 2018 19:49:37 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1537213777.26.0.956365154283.issue34716@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:50:10 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 17 Sep 2018 19:50:10 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537213810.31.0.956365154283.issue34715@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:53:01 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:53:01 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537213981.02.0.956365154283.issue34715@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Reverting afde1c1a05c and 5633c4f342d fixes the issue.

----------
nosy:  -p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:55:02 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:55:02 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537214102.94.0.956365154283.issue34715@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 15:55:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 19:55:24 +0000
Subject: [issue34676] Guarantee that divmod() and PyNumber_Divmod() return a
 2-tuple
In-Reply-To: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>
Message-ID: <1537214124.29.0.956365154283.issue34676@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +MagicMock.__divmod__ should return a pair

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34676>
_______________________________________

From report at bugs.python.org  Mon Sep 17 16:18:38 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 20:18:38 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1537215518.25.0.956365154283.issue32533@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8789

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Mon Sep 17 16:33:45 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Sep 2018 20:33:45 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537216425.42.0.956365154283.issue17239@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

We discussed this last week at the sprint.  Christian, it would be great if you could get this merged for 3.7 and possibly 3.6 in the next 24 hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 17 16:38:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 20:38:02 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537216682.79.0.956365154283.issue34715@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8790
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 16:40:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 20:40:27 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537216827.64.0.956365154283.issue34715@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 9366 to fix the compilation of timemodule.c on FreeBSD.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 16:56:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 20:56:20 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537217780.65.0.956365154283.issue34715@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1fb399ba4e977e697d194769070316247237f68e by Victor Stinner in branch 'master':
bpo-34715: Revert "Simplify PyInit_timezone. (GH-9323)" (GH-9366)
https://github.com/python/cpython/commit/1fb399ba4e977e697d194769070316247237f68e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:01:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 21:01:25 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1537218085.54.0.956365154283.issue34587@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7484bdfd1e2e33fdd2c44dd4ffa044aacd495337 by Victor Stinner in branch 'master':
bpo-34587, test_socket: remove RDSTest.testCongestion() (GH-9277)
https://github.com/python/cpython/commit/7484bdfd1e2e33fdd2c44dd4ffa044aacd495337


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:01:45 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 21:01:45 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1537218105.93.0.956365154283.issue34587@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8791

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:01:54 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 21:01:54 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1537218114.58.0.956365154283.issue34587@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8792

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:13:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:13:57 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
Message-ID: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I'd like to remove the ":numbered:" option from Doc/library/index.rst TOC.  Most standard library modules don't have extensive documentation, but some, for example asyncio, have.  For such modules, numbering makes title to contain too much noise.  Sphinx does not allow to opt-out from sections numbering if it's enabled on the top level.

----------
assignee: docs at python
components: Documentation
files: now_2.png
messages: 325577
nosy: docs at python, yselivanov
priority: normal
severity: normal
status: open
title: docs: disable numbered sections for stdlib in html
type: enhancement
Added file: https://bugs.python.org/file47809/now_2.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:14:09 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:09 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218849.38.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


Added file: https://bugs.python.org/file47810/now_1.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:14:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:20 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218860.27.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


Added file: https://bugs.python.org/file47811/after_1.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:14:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:25 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218865.84.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


Added file: https://bugs.python.org/file47812/after_2.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:14:40 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:40 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218880.89.0.956365154283.issue34717@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Please refer to the attached screenshots to see the difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:14:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:47 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218887.79.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:15:06 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Sep 2018 21:15:06 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218906.67.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:15:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:15:53 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218953.5.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8793
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:16:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:16:06 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218966.56.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +willingc -mdk
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:16:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:16:23 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218983.57.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:17:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 21:17:49 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537219069.25.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8794

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:28:03 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 21:28:03 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1537219683.26.0.956365154283.issue34587@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b7f58d7f80f80f0e20cad84773f158a379a19280 by Miss Islington (bot) in branch '3.7':
bpo-34587, test_socket: remove RDSTest.testCongestion() (GH-9277)
https://github.com/python/cpython/commit/b7f58d7f80f80f0e20cad84773f158a379a19280


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:28:18 2018
From: report at bugs.python.org (Julien Palard)
Date: Mon, 17 Sep 2018 21:28:18 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537219698.17.0.956365154283.issue34717@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

In one hand, I already spotted students exchanging paragraphs numbers, when both have the same page open but one want to point a specific paragraph to the other, it goes like "humm that thing is docuemtented in paragraph 3.17.3.12".

Don't mis-read me, they don't *know* the paragraph number, they read it because it's on their screen at the moment they use it, to temporarily exchange a specific location on the page.

On the other hand the numbering is inconsistent between versions, and I also seen students replying to the first one, it goes like: "oooh got it, it's not 3.17.3.12 but 3.17.3.16 in my version" (Obviously I'm make up numbers, too).

Soo... I'm +1 for this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:32:10 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Sep 2018 21:32:10 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537219930.05.0.956365154283.issue32557@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8795
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:40:25 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 21:40:25 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1537220425.82.0.956365154283.issue34587@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 68a8f041051e8387583c66b91c7a3bbda6cf7e63 by Miss Islington (bot) in branch '3.6':
bpo-34587, test_socket: remove RDSTest.testCongestion() (GH-9277)
https://github.com/python/cpython/commit/68a8f041051e8387583c66b91c7a3bbda6cf7e63


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:41:46 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 21:41:46 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1537220506.9.0.956365154283.issue32533@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 1a107eea8e91e50c5c9025e945c78eb1aa9b874d by Steve Dower in branch '3.6':
bpo-32533: Fixed thread-safety of error handling in _ssl. (GH-7158)
https://github.com/python/cpython/commit/1a107eea8e91e50c5c9025e945c78eb1aa9b874d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:41:56 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 21:41:56 +0000
Subject: [issue34267] find_python.bat doesn't find installed Python 3.7
In-Reply-To: <1532820797.37.0.56676864532.issue34267@psf.upfronthosting.co.za>
Message-ID: <1537220516.74.0.956365154283.issue34267@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6750922f8d3428d84a016c34d6fcd99659e8610c by Steve Dower in branch 'master':
bpo-34267: Update find_python.bat to use 3.7 if available (GH-8552)
https://github.com/python/cpython/commit/6750922f8d3428d84a016c34d6fcd99659e8610c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34267>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:42:09 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 21:42:09 +0000
Subject: [issue34267] find_python.bat doesn't find installed Python 3.7
In-Reply-To: <1532820797.37.0.56676864532.issue34267@psf.upfronthosting.co.za>
Message-ID: <1537220529.14.0.956365154283.issue34267@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8796

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34267>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:45:24 2018
From: report at bugs.python.org (Joe Pamer)
Date: Mon, 17 Sep 2018 21:45:24 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537220724.96.0.956365154283.issue32557@psf.upfronthosting.co.za>


Joe Pamer <joe at noteven.org> added the comment:

Hi!

I decided to try fixing this one as a way to get acquainted with the code base. I went ahead and updated the backing NT C function, but please let me know if you'd prefer I update disk_usage as proposed.

Thanks!

----------
nosy: +jopamer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Mon Sep 17 17:55:12 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Sep 2018 21:55:12 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537221312.7.0.956365154283.issue17239@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The external entity patch is ready, but the billion laughs fix need more time. I'm working with an upstream developer on a proper fix.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:10:24 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:10:24 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537222224.85.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8798

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:12:24 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:12:24 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222344.86.0.956365154283.issue34717@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset c62ab2862db2382808bb2228760eebdda3f608bd by Yury Selivanov in branch 'master':
bpo-34717: Stop numbering stdlib titles/sections in the docs (GH-9370)
https://github.com/python/cpython/commit/c62ab2862db2382808bb2228760eebdda3f608bd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:12:34 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 22:12:34 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222354.21.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8799
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:13:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 22:13:21 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537222401.18.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 188ebfa475a6f6aa2d0ea14ca8e1fbe7865b6d27 by Victor Stinner in branch 'master':
bpo-34589: Make _PyCoreConfig.coerce_c_locale private (GH-9371)
https://github.com/python/cpython/commit/188ebfa475a6f6aa2d0ea14ca8e1fbe7865b6d27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:16:13 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:16:13 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222573.13.0.956365154283.issue34717@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks to Julien and Carol for reviews and sharing the opinion!  I'm closing this issue now.

In case someone needs the numbering to be re-enabled for some reason we can re-open this issue and discuss the best approach how to make that happen, while making sure that documentation for modules like asyncio is easy to browse and read.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:16:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:16:28 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222588.42.0.956365154283.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:27:15 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 17 Sep 2018 22:27:15 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537223235.15.0.956365154283.issue17239@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Any reason to not take the current patch for our vendored copy and give it some exposure at least on platforms that rely on it (maybe just Windows)? I don't see any reason to wait on another group to "release" it when we need to manually apply the update to our own repo anyway.

Platforms using system libexpat that hasn't been patched have obviously decided not to patch it themselves :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:39:28 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 22:39:28 +0000
Subject: [issue34267] find_python.bat doesn't find installed Python 3.7
In-Reply-To: <1532820797.37.0.56676864532.issue34267@psf.upfronthosting.co.za>
Message-ID: <1537223968.82.0.956365154283.issue34267@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a8a8cc71c7fc7585e15652ff7ab354665f787d5a by Miss Islington (bot) in branch '3.7':
bpo-34267: Update find_python.bat to use 3.7 if available (GH-8552)
https://github.com/python/cpython/commit/a8a8cc71c7fc7585e15652ff7ab354665f787d5a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34267>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:42:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:42:04 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537224124.87.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 3085534c398e6b181e7a9ac0cb9c80f3c670f2b9 by Yury Selivanov in branch 'master':
bpo-33649: Add a hello world example to asyncio.rst (GH-9374)
https://github.com/python/cpython/commit/3085534c398e6b181e7a9ac0cb9c80f3c670f2b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:42:13 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 22:42:13 +0000
Subject: [issue34717] docs: disable numbered sections for stdlib in html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537224133.43.0.956365154283.issue34717@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c63d81b3feaa008a6be4c7c83c324174e8d95c24 by Miss Islington (bot) in branch '3.7':
bpo-34717: Stop numbering stdlib titles/sections in the docs (GH-9370)
https://github.com/python/cpython/commit/c63d81b3feaa008a6be4c7c83c324174e8d95c24


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34717>
_______________________________________

From report at bugs.python.org  Mon Sep 17 18:54:48 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Mon, 17 Sep 2018 22:54:48 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537224888.45.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
pull_requests: +8800

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:01:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 23:01:53 +0000
Subject: [issue34587] test_socket: testCongestion() hangs on my Fedora 28
In-Reply-To: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>
Message-ID: <1537225313.88.0.956365154283.issue34587@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I removed the test from Python 3.6, 3.7 and master.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34587>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:11:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 23:11:11 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537225871.65.0.956365154283.issue17239@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Any reason to not take the current patch for our vendored copy and give it some exposure at least on platforms that rely on it (maybe just Windows)? I don't see any reason to wait on another group to "release" it when we need to manually apply the update to our own repo anyway.

My policy is upstream fix: first, get a change merged upstream.

If we start with a downstream patch:

* only Windows and macOS will get the fix
* upstream may require changes making the change incompatible, for example change the default limits
* I would prefer to keep Modules/expat/ as close as possible to the upstream

Python is vulnerable for years, it's not like there is an urgency to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:16:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:16:51 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537226211.13.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 1fa2ec49bec50bea1847b558b883c5c904334734 by Yury Selivanov (Elvis Pranskevichus) in branch 'master':
bpo-33649: A copy-editing pass on asyncio documentation (GH-9376)
https://github.com/python/cpython/commit/1fa2ec49bec50bea1847b558b883c5c904334734


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:22:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 23:22:33 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537226553.85.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7a0791b6992d420dc52536257f2f093851ed7215 by Victor Stinner in branch 'master':
bpo-34589: C locale coercion off by default (GH-9073)
https://github.com/python/cpython/commit/7a0791b6992d420dc52536257f2f093851ed7215


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:30:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:30:25 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537227025.8.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8801

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:35:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:35:35 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537227335.05.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 512d7101098b971837cbb406942215244f636547 by Yury Selivanov in branch '3.7':
bpo-33649: Backport asyncio docs from 'master' to 3.7 (GH-9377)
https://github.com/python/cpython/commit/512d7101098b971837cbb406942215244f636547


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:38:31 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:38:31 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537227511.54.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Wow, we did this!  I've just pushed a backport of the new documentation to 3.7.

Thanks to Carol, Elvis, and Andrew for the help!

I think this issue can now be closed, we'll open new ones for:

1. A high-level intro/tutorial for asyncio.

2. A low-level tutorial (say we implement a micro-library for Redis using only low-level APIs)

3. An asyncio "Architecture" section as suggested by Jim DeLaHunt.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 19:45:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Sep 2018 23:45:56 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537227956.7.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8802

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:19:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 00:19:32 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537229972.26.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dbdee0073cf0b88fe541980ace1f650900f455cc by Victor Stinner in branch 'master':
bpo-34589: Add -X coerce_c_locale command line option (GH-9378)
https://github.com/python/cpython/commit/dbdee0073cf0b88fe541980ace1f650900f455cc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:30:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 00:30:11 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537230611.29.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Ned, do we auto run docs build for Python 3.7?  Or do we only build them on release?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:42:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 00:42:19 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537231339.74.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8803

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:45:58 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 18 Sep 2018 00:45:58 +0000
Subject: [issue34691] _contextvars missing in x64 master branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1537231558.19.0.956365154283.issue34691@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

FYI, I bet I didn't see a problem with the Win32 target because I followed instructions ;-) and did my first build using build.bat.  Using that for the x64 too target makes the problem go away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:50:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 00:50:35 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537231835.5.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8804

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:52:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 00:52:32 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537231952.83.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Ned, do we auto run docs build for Python 3.7?  Or do we only build them on release?

Never mind, the docs for 3.7 have been updated!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 20:59:12 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Sep 2018 00:59:12 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537232352.77.0.956365154283.issue33649@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

>> Ned, do we auto run docs build for Python 3.7?  Or do we only build them on release?

The online html docs at https://docs.python.org/, like https://docs.python.org/3.7/, are rebuilt every 3 hours from the current branch heads for feature and maintenance releases.  We also make available archive copies of the docs for each release here:
https://www.python.org/doc/versions/

>Never mind, the docs for 3.7 have been updated!

What's up, Doc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 21:01:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 01:01:44 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537232504.5.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 144f1e2c6f4a24bd288c045986842c65cc289684 by Victor Stinner in branch '3.7':
[3.7] bpo-34589: Add -X coerce_c_locale option; C locale coercion off by default (GH-9379)
https://github.com/python/cpython/commit/144f1e2c6f4a24bd288c045986842c65cc289684


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 21:12:20 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 01:12:20 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1537233140.54.0.956365154283.issue34536@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8805

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Mon Sep 17 21:42:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Sep 2018 01:42:57 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537234977.58.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 21:45:29 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Sep 2018 01:45:29 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537235129.87.0.956365154283.issue34589@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I'm marking this as a 3.7.1 "release blocker" until Nick has had a chance to review the merged PR and he and Victor are in agreement that this is a satisfactory approach for 3.7.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 21:48:02 2018
From: report at bugs.python.org (shashank)
Date: Tue, 18 Sep 2018 01:48:02 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1537235282.58.0.956365154283.issue21109@psf.upfronthosting.co.za>


shashank <shanx.shashank at gmail.com> added the comment:

I can't use Jakub's repo (or Makefile from that repo) directly because it relies on tar, which doesn't look like dependency for building Python. I can make similar tarballs but I am not sure how licensing will work. I can add tarballs for the cases I discovered. 

As of now, I'll move ahead with my version of tarballs and will change them for licensing requirement as needed before merging it to source code.

Would you prefer a PR over a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Mon Sep 17 22:05:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 02:05:11 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537236311.47.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8806

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 22:09:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 02:09:37 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537236577.13.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

test_c_locale_coercion didn't test the -E option: I wrote PR 9382 to test it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Mon Sep 17 23:58:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 03:58:06 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537243086.64.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ac94e38d076aebc56c2ff96a249b5e40f32633ea by Yury Selivanov in branch 'master':
bpo-33649: Note that asyncio.run() calls shutdown_asyncgens() (GH-9380)
https://github.com/python/cpython/commit/ac94e38d076aebc56c2ff96a249b5e40f32633ea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Mon Sep 17 23:58:15 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 03:58:15 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537243095.59.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8807

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:08:25 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 04:08:25 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537243705.43.0.956365154283.issue17239@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

There's also the view that it'll be easier to justify upstreaming a patch if it's been released and tested in a separate app. We require that all the time for Python patches, so why should we expect other projects to be different?

We're totally entitled to only release it for those platforms, because we are responsible for libexpat on those (we could vendor it for all of them? Or switch to platform-supported libraries for macOS and Windows?)

Who normally updates the vendored libexpat? I'd rather let them make the call on how far to diverge from upstream, since it'll be up to them to roll the changes forward or revert them in favour of upstream. I doubt different defaults will be an issue, especially since they aren't configurable anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:08:45 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Sep 2018 04:08:45 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537243725.87.0.956365154283.issue34659@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Tim, do we care about whether "initial=None" versus "initial=_sentinel"?

The former makes for a nice looking pure python equivalent and works nicely with the argument clinic to generate a signature.  However, it precludes using None as the actual start argument (though I don't see why somewone would want to do that), and it isn't parallel to reduce() (not sure I care about that at all). 

Kristjan, do you want to contribute to the update of the pickle/copy code for this API extension?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:12:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 04:12:09 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537243929.06.0.956365154283.issue33649@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1f4ea580675d7b30d3906d78c500997d7d96995d by Miss Islington (bot) in branch '3.7':
bpo-33649: Note that asyncio.run() calls shutdown_asyncgens() (GH-9380)
https://github.com/python/cpython/commit/1f4ea580675d7b30d3906d78c500997d7d96995d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:13:20 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 04:13:20 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537244000.47.0.956365154283.issue32557@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I took a quick look at the patch and the main issue I see is the use of the MAX_PATH constant. We encourage people to disable this limit where possible, so using dynamic allocation where we need to reduce the path will be a better way to avoid this function breaking.

There should be other examples of this pattern in the file, but I don't think it'll matter here if we always copy the string. Better to avoid it, of course, but that complicates things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:37:34 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:37:34 +0000
Subject: [issue34718] Syntax error on factorial example
Message-ID: <1537245454.25.0.956365154283.issue34718@psf.upfronthosting.co.za>


New submission from Miguel ?ngel <miguelangel.garcia at gmail.com>:

In the example on https://docs.python.org/3/library/asyncio-task.html#running-tasks-concurrently, there is a double closing parenthesis, but just one is needed for the `gather` method. This makes the example to fail.

----------
assignee: docs at python
components: Documentation
messages: 325614
nosy: docs at python, magmax
priority: normal
severity: normal
status: open
title: Syntax error on factorial example
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34718>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:45:27 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:45:27 +0000
Subject: [issue34718] Syntax error on factorial example
In-Reply-To: <1537245454.25.0.956365154283.issue34718@psf.upfronthosting.co.za>
Message-ID: <1537245927.36.0.956365154283.issue34718@psf.upfronthosting.co.za>


Miguel ?ngel <miguelangel.garcia at gmail.com> added the comment:

Too trivial to require an issue. Sorry, I'm newbie here :)

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34718>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:47:30 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:47:30 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537246050.03.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Miguel ?ngel <miguelangel.garcia at gmail.com>:


----------
pull_requests: +8808

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:48:48 2018
From: report at bugs.python.org (Danny Hermes)
Date: Tue, 18 Sep 2018 04:48:48 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537246128.45.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Danny Hermes <daniel.j.hermes at gmail.com>:


----------
pull_requests: +8809

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 00:50:11 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 04:50:11 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537246211.93.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8810

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 01:44:05 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 18 Sep 2018 05:44:05 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537249445.5.0.956365154283.issue34659@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Ya, I care:  `None` was always intended to be an explicit way to say "nothing here", and using unique non-None sentinels instead for that purpose is needlessly convoluted.  `initial=None` is perfect.  But then I'm old & in the way ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:01:00 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 06:01:00 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537250460.65.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Miguel ?ngel <miguelangel.garcia at gmail.com>:


----------
pull_requests: +8811

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:02:10 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 06:02:10 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537250530.59.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8812

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:16:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 06:16:31 +0000
Subject: [issue34681] Incorrect class name Pattern in sre_parse.py
In-Reply-To: <1536942152.74.0.956365154283.issue34681@psf.upfronthosting.co.za>
Message-ID: <1537251391.37.0.956365154283.issue34681@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e0c19ddc661e56cc7e694be52d3e47f1dfe5af24 by Serhiy Storchaka in branch 'master':
bpo-34681: Rename class Pattern in sre_parse to State. (GH-9310)
https://github.com/python/cpython/commit/e0c19ddc661e56cc7e694be52d3e47f1dfe5af24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34681>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:16:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 06:16:51 +0000
Subject: [issue34681] Incorrect class name Pattern in sre_parse.py
In-Reply-To: <1536942152.74.0.956365154283.issue34681@psf.upfronthosting.co.za>
Message-ID: <1537251411.18.0.956365154283.issue34681@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/issue34681>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:41:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 06:41:10 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537252870.6.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8813

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:48:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 06:48:00 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537253280.0.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b042cf10c6084d14279c55a7e0d2d7595ff4e694 by Yury Selivanov in branch 'master':
bpo-33649: Fix markup; add another note that asyncio.run is 3.7+ (GH-9389)
https://github.com/python/cpython/commit/b042cf10c6084d14279c55a7e0d2d7595ff4e694


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:48:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 06:48:09 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537253289.83.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8814

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 02:54:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 06:54:29 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1537253669.54.0.956365154283.issue32455@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7bdf28265aa371b39f82dfc6562635801aff15a5 by Serhiy Storchaka in branch 'master':
bpo-32455: Add jump parameter to dis.stack_effect(). (GH-6610)
https://github.com/python/cpython/commit/7bdf28265aa371b39f82dfc6562635801aff15a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32455>
_______________________________________

From report at bugs.python.org  Tue Sep 18 03:00:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 07:00:26 +0000
Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are
 not particularly useful
In-Reply-To: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za>
Message-ID: <1537254026.29.0.956365154283.issue32455@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/issue32455>
_______________________________________

From report at bugs.python.org  Tue Sep 18 03:01:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 07:01:03 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537254063.79.0.956365154283.issue33649@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 45452b738b7f94221a94e903fb5975222fbb7a8f by Miss Islington (bot) in branch '3.7':
bpo-33649: Fix markup; add another note that asyncio.run is 3.7+ (GH-9389)
https://github.com/python/cpython/commit/45452b738b7f94221a94e903fb5975222fbb7a8f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 03:06:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 07:06:28 +0000
Subject: [issue33138] Improve standard error for uncopyable types
In-Reply-To: <1521994898.68.0.467229070634.issue33138@psf.upfronthosting.co.za>
Message-ID: <1537254388.21.0.956365154283.issue33138@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Does anybody have opinion about this issue? Is this option the best of possible? I'm going to merge the PR soon.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33138>
_______________________________________

From report at bugs.python.org  Tue Sep 18 04:29:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 08:29:04 +0000
Subject: [issue33721] os.path.exists() ought to return False if pathname
 contains NUL
In-Reply-To: <1527787165.92.0.682650639539.issue33721@psf.upfronthosting.co.za>
Message-ID: <1537259344.55.0.956365154283.issue33721@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0185f34ddcf07b78feb6ac666fbfd4615d26b028 by Serhiy Storchaka in branch 'master':
 bpo-33721: Make some os.path functions and pathlib.Path methods be tolerant to invalid paths.  (#7695)
https://github.com/python/cpython/commit/0185f34ddcf07b78feb6ac666fbfd4615d26b028


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33721>
_______________________________________

From report at bugs.python.org  Tue Sep 18 04:34:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 08:34:24 +0000
Subject: [issue33721] os.path.exists() ought to return False if pathname
 contains NUL
In-Reply-To: <1527787165.92.0.682650639539.issue33721@psf.upfronthosting.co.za>
Message-ID: <1537259664.85.0.956365154283.issue33721@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

os.path.exists() and similar functions will return now False for invalid paths (non-encodable paths on Unix, non-decodable bytes paths on Windows, and paths containing null characters or bytes).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33721>
_______________________________________

From report at bugs.python.org  Tue Sep 18 05:29:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Sep 2018 09:29:09 +0000
Subject: [issue33138] Improve standard error for uncopyable types
In-Reply-To: <1521994898.68.0.467229070634.issue33138@psf.upfronthosting.co.za>
Message-ID: <1537262949.0.0.956365154283.issue33138@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33138>
_______________________________________

From report at bugs.python.org  Tue Sep 18 06:14:59 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 10:14:59 +0000
Subject: [issue34711] return ENOTDIR when open() accepts filenames with a
 trailing slash
In-Reply-To: <1537192847.87.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <e669f3d2-ea2f-1f93-f899-861232e7e7ed@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 17/09/2018 16:00, Michael Felt wrote:
> And, now for the PR tests...

Had a review - many thanks, but before I press the resolve button -
Ihope someone can help me understand why the "Travis" etc, checks are
failing, e.g.,

./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
clang -pthread -L/home/travis/multissl/openssl/1.1.0h/lib
-L/home/travis/multissl/openssl/1.1.0h/lib -Xlinker -export-dynamic -o
Programs/_testembed Programs/_testembed.o libpython3.8dm.a -lpthread
-ldl -lutil -lm -lm
Segmentation fault (core dumped)
generate-posix-vars failed

I have no clue how my relatively small change can have this kind of a
effect and then nothing moves forward. Very frustrating!
Thx,
Michael

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Tue Sep 18 06:26:44 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Sep 2018 10:26:44 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537266404.31.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

@vstinner: another option is to ignore "use_vfork" on platforms that don't have POSIX_SPAWN_USEVFORK. Using vfork or not is primarily a optimisation, ignoring the flag should not result in different behaviour (other than speed).

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 06:34:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 10:34:43 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537266882.99.0.956365154283.issue34659@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The first issue, with ignoring initial=None, is complex because Argument Clinic and the inspect module don't support optional parameters without default value. It could be possible to use optional groups, but currently Argument Clinic supports optional groups only when all parameters are positional-only. For now, the only way is getting rid from Argument Clinic.

As for pickling/copying, this task is technically difficult, it but I don't see principal problems. The code is already complex (see issue25718) and will be more complex. Since the reduce protocol doesn't support keyword arguments, we will needs to use either partial() for passing the keyword argument, or chain() for imitating it by creating an equivalent object. I can write this code.

Taking to the account the complexity of the implementation and arguments against this feature (see issue25193 and the discussion on Python-ideas), is it worth to add it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Tue Sep 18 06:37:01 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Sep 2018 10:37:01 +0000
Subject: [issue34518] Documentation for coroutine objects
In-Reply-To: <1535359488.51.0.56676864532.issue34518@psf.upfronthosting.co.za>
Message-ID: <1537267021.29.0.956365154283.issue34518@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Since there is work on asyncio docs overhaul I just want to bring this to your attention since I don't know if this has already been resolved with the merged PRs to master and your thoughts on this.

Thanks

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34518>
_______________________________________

From report at bugs.python.org  Tue Sep 18 06:37:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 10:37:54 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537267074.52.0.956365154283.issue34663@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If this is an optimization, what is the downside of always using vfork()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 06:44:10 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Sep 2018 10:44:10 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537267450.45.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Good question. A comment on <https://stackoverflow.com/questions/2731531/faster-forking-of-large-processes-on-linux> says that glibc already uses vfork where appropriate, explicitly using the flag may not be necessary. 

Note that I haven't verified if the comment is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 07:27:00 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 18 Sep 2018 11:27:00 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537270020.68.0.956365154283.issue34663@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The documentation says:

 The child process is created using vfork(2) instead of fork(2) when
       either of the following is true:

       *  the spawn-flags element of the attributes object pointed to by
          attrp contains the GNU-specific flag POSIX_SPAWN_USEVFORK; or

       *  file_actions is NULL and the spawn-flags element of the attributes
          object pointed to by attrp does not contain
          POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF,
          POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER,
          POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS.

So using the flag is necessary if you want to force the use of vfork when passing any of the flags specified in the second point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 07:56:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Sep 2018 11:56:33 +0000
Subject: [issue28908] pydoc getdocloc() is broken
In-Reply-To: <1481225069.67.0.983808754033.issue28908@psf.upfronthosting.co.za>
Message-ID: <1537271793.15.0.956365154283.issue28908@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28908>
_______________________________________

From report at bugs.python.org  Tue Sep 18 07:57:29 2018
From: report at bugs.python.org (Javier Dehesa)
Date: Tue, 18 Sep 2018 11:57:29 +0000
Subject: [issue34719] Deprecate set to frozenset conversion in set.__contains__
Message-ID: <1537271849.84.0.956365154283.issue34719@psf.upfronthosting.co.za>


New submission from Javier Dehesa <javidcf at gmail.com>:

This comes from this SO question: https://stackoverflow.com/q/52382983/1782792

Currently, this works:

    > print({1, 2} in {frozenset({1, 2}))
    # True

This is strange because set is unhashable. Apparently, it is a case-specific feature implemented back in 2003 (https://github.com/python/cpython/commit/19c2d77842290af9b5f470c1eea2a71d1f77c9fe), by which set objects are converted to frozensets when checking for membership in another set. Personally I feel this is a bit surprising and inconsistent, but that is not the only issue with it. In the original implementation, this conversion was basically free because the created frozenset used the same storage as the given one. In the current implementation, however (https://github.com/python/cpython/blob/3.7/Objects/setobject.c#L1888-L1906), a new frozenset object is created, copied from the previous one. It seems this was done for thread-safety. The problem with that is that it is significantly more expensive:

    s = set(range(100000))
    sf = frozenset(s)
    t = { sf }
    %timeit sf in t  # True
    >>> 31.6 ns ? 1.04 ns per loop (mean ? std. dev. of 7 runs, 10000000 loops each)
    %timeit s in t  # True
    >>> 4.9 ms ? 168 ?s per loop (mean ? std. dev. of 7 runs, 100 loops each)

In the above case, using the conversion takes five order of magnitude more time than the regular check. I suppose there is a memory impact too.

I think this (as far as I know) undocumented feature does not provide a significant usability gain, is inconsistent with the documented behavior of set and gives rise to obscurely underperfoming code. Removing it would be a breaking change, but again, affected code would be relying on undocumented behavior (or even "against-documentation" behavior).

----------
components: Interpreter Core
messages: 325631
nosy: Javier Dehesa
priority: normal
severity: normal
status: open
title: Deprecate set to frozenset conversion in set.__contains__
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/issue34719>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:03:05 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 12:03:05 +0000
Subject: [issue34720] Fix test_importlib for AIX
Message-ID: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Issue32374 added a new subtest (test_bad_traverse) in test_importlib. The test succeeds when a script calling a bad_traverse exits with a non-zero status (e.g., crashes because of segmentation violation)

This patch "fixes" Modules/_testmultiphase.c so that it exits with a non-zero status when a NULL pointer is accessed. This is what was causing other systems to 'crash' expectedly - while AIX was not.

A simple demo program to demonstrate the difference behavior of AIX:

/*
 * Program to show whether an executable crashes, or not
 * when a NULL pointer is accessed
 * Author: AIXTOOLS
 */

#include<stdio.h>
main()
{
        long *vpt = NULL;

        fprintf(stdout, "vpt = %08lx\n", (long) vpt);
        if (*vpt)
                fprintf(stdout,"True\n");
        else
                fprintf(stdout,"False\n");

}

On AIX:
root at x066:[/data/prj/python/git]make nullpr; ./nullpr
cc     nullpr.c   -o nullpr
vpt = 00000000
False

On a Linux server:
root at x074:/data/prj/python/git# rm nullpr; make nullpr; ./nullpr
make: Warning: File 'nullpr.c' has modification time 352 s in the future
cc     nullpr.c   -o nullpr
nullpr.c:8:1: warning: return type defaults to 'int' [-Wimplicit-int]
 main()
 ^
make: warning:  Clock skew detected.  Your build may be incomplete.
vpt = 00000000
Segmentation fault

----------
components: Tests
messages: 325632
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Fix test_importlib for AIX
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:04:51 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 12:04:51 +0000
Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX
In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>
Message-ID: <1537272291.14.0.956365154283.issue34720@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
title: Fix test_importlib for AIX -> Fix test_importlib.test_bad_traverse for AIX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:08:21 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 12:08:21 +0000
Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX
In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>
Message-ID: <1537272501.21.0.956365154283.issue34720@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8815
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:31:16 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Sep 2018 12:31:16 +0000
Subject: [issue34719] Deprecate set to frozenset conversion in set.__contains__
In-Reply-To: <1537271849.84.0.956365154283.issue34719@psf.upfronthosting.co.za>
Message-ID: <1537273876.7.0.956365154283.issue34719@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34719>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:37:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Sep 2018 12:37:24 +0000
Subject: [issue34702] urlopen doesn't handle query strings with "file" scheme
In-Reply-To: <1537085899.9.0.956365154283.issue34702@psf.upfronthosting.co.za>
Message-ID: <1537274244.36.0.956365154283.issue34702@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34702>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:39:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 12:39:03 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537274343.47.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cb5778f00ce48631c7140f33ba242496aaf7102b by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146)
https://github.com/python/cpython/commit/cb5778f00ce48631c7140f33ba242496aaf7102b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:39:12 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 12:39:12 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537274352.68.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8816

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:39:20 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 12:39:20 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537274360.1.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8817

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:40:28 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Sep 2018 12:40:28 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537274428.81.0.956365154283.issue34623@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Since it's a security fix, the change should land in 3.4 and 3.5, too.

----------
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:45:06 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Sep 2018 12:45:06 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537274706.4.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8818

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:02:06 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 18 Sep 2018 13:02:06 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1537275726.55.0.956365154283.issue21109@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I am not a lawyer, but to the best of my understanding, using such tarballs would be fine.  Since Jakub's repo only provides code to generate archive files but doesn't include actual archive files, and the generation code is licensed via the MIT license, we are free to use the code to generate archive files, which would then not fall under the copyright of the author of the generation code (Jakub).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:11:13 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 13:11:13 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537276273.88.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 470a435f3b42c9be5fdb7f7b04f3df5663ba7305 by Miss Islington (bot) in branch '3.7':
bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146)
https://github.com/python/cpython/commit/470a435f3b42c9be5fdb7f7b04f3df5663ba7305


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:13:12 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 13:13:12 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537276392.47.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 18b20bad75b4ff0486940fba4ec680e96e70f3a2 by Miss Islington (bot) (Christian Heimes) in branch '2.7':
[2.7] bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146) (GH-9394)
https://github.com/python/cpython/commit/18b20bad75b4ff0486940fba4ec680e96e70f3a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:14:18 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 13:14:18 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537276458.21.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f7666e828cc3d5873136473ea36ba2013d624fa1 by Miss Islington (bot) in branch '3.6':
bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146)
https://github.com/python/cpython/commit/f7666e828cc3d5873136473ea36ba2013d624fa1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:18:10 2018
From: report at bugs.python.org (zack)
Date: Tue, 18 Sep 2018 13:18:10 +0000
Subject: [issue34721] json module loads function
Message-ID: <1537276690.81.0.956365154283.issue34721@psf.upfronthosting.co.za>


New submission from zack <j9001552 at gmail.com>:

the json.loads function think a string variable is a json type, but the variable is "123"

----------
components: Library (Lib)
files: json_test.py
messages: 325639
nosy: jaihong
priority: normal
severity: normal
status: open
title: json module loads function
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file47813/json_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34721>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:19:45 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 18 Sep 2018 13:19:45 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1537276785.19.0.956365154283.issue31635@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I do think this is an active bug in OpenBSD's ISO calculations, here: https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/lib/libc/time/wcsftime.c#L326

I re-created this algorithm in Python and at the beginning of the year it gives the wrong answer at the beginning of the year in about 50% of years. I have spent some time trying to understand the way the algorithm is *supposed* to work, but I don't totally understand what it's doing. I'll report this to OpenBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:26:54 2018
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 18 Sep 2018 13:26:54 +0000
Subject: [issue34721] json module loads function
In-Reply-To: <1537276690.81.0.956365154283.issue34721@psf.upfronthosting.co.za>
Message-ID: <1537277214.23.0.956365154283.issue34721@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

This is intentional, the parsed in JSON doesn't necessarily have to have an object at the root. This is also what allows you to do:

>>> json.loads("[]")
[]

This behavior is also consistent with browsers, try this in your browser's dev console:

> JSON.parse("123")
123
> JSON.parse('"123"')
"123"
> JSON.parse('[]')
[]

More technically, look at the JSON standard here: https://www.json.org/

As you can see, the root value is an "element", which is of type "value" surrounded by some whitespace. Values can be any of these:

value
    object
    array
    string
    number
    "true"
    "false"
    "null"

----------
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34721>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:33:34 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Sep 2018 13:33:34 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1537277614.49.0.956365154283.issue34542@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8819

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:38:35 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Sep 2018 13:38:35 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1537277915.92.0.956365154283.issue34542@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8820

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:39:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 13:39:19 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537277959.11.0.956365154283.issue17239@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Who normally updates the vendored libexpat?

I made the 3 latest libexpat updates, and each of them was painful :-)

My notes on vendored libraries:
https://pythondev.readthedocs.io/cpython.html#vendored-external-libraries

I wrote a tool to get the version of all vendored libraries, and a script to updated libexpat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:45:45 2018
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 18 Sep 2018 13:45:45 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537278345.6.0.956365154283.issue34659@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <sweskman at gmail.com> added the comment:

I think I'll pass Raymond, its been so long since I've contributed, in the mean time there is github and argument clinic and whatnot so I'm out of training.  I?m lurking around these parts and maybe shall return one day :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:53:47 2018
From: report at bugs.python.org (Peter Ebden)
Date: Tue, 18 Sep 2018 13:53:47 +0000
Subject: [issue34722] Non-deterministic bytecode generation
Message-ID: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>


New submission from Peter Ebden <peter.ebden at gmail.com>:

We've found that the following code produces non-deterministic bytecode,
even post PEP-552:

def test(x):
    if x in {'ONE', 'TWO', 'THREE'}:
        pass

It's not too hard to test it:

$ python3.7 -m compileall --invalidation-mode=unchecked-hash test.py
Compiling 'test.py'...
$ sha1sum __pycache__/test.cpython-37.pyc
61e5682ca95e8707b4ef2a79f64566664dafd800  __pycache__/test.cpython-37.pyc
$ rm __pycache__/test.cpython-37.pyc
$ python3.7 -m compileall --invalidation-mode=unchecked-hash test.py
Compiling 'test.py'...
$ sha1sum __pycache__/test.cpython-37.pyc
222a06621b491879e5317b34e9dd715bacd89b7d  __pycache__/test.cpython-37.pyc

It looks like the peephole optimiser is converting the LOAD_CONST instructions
for the set into a single LOAD_CONST for a frozenset which then serialises in
nondeterministic order. One can hence work around it by setting PYTHONHASHSEED
to a known value.

I'm happy to help out with this if needed, although I don't have a lot of
familiarity with the relevant code.

----------
components: Interpreter Core
messages: 325644
nosy: Peter Ebden
priority: normal
severity: normal
status: open
title: Non-deterministic bytecode generation
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Tue Sep 18 09:54:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 13:54:56 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537278895.99.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Serhiy Storchaka: "If this is an optimization, what is the downside of always using vfork()?"

I don't know the vfork() function, but you can find articles like:
"vfork considered dangerous" (old article of 2012)
https://ewontfix.com/7/

But it's unclear to me if vfork() drawbacks also affect posix_spawn(). posix_spawn() is well defined: call vfork() and then immediately exec().

Another article:

"First is that vfork pauses the parent thread while the child executes and eventually calls an exec family function, this is a huge latency problem for applications."

https://developers.redhat.com/blog/2015/08/19/launching-helper-process-under-memory-and-latency-constraints-pthread_create-and-vfork/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:02:16 2018
From: report at bugs.python.org (Dogan)
Date: Tue, 18 Sep 2018 14:02:16 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
Message-ID: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>


New submission from Dogan <dogankocabas at gmail.com>:

Hey there,

I believe I've come across a bug. It occurs when you try to lower() the Turkish uppercase letter "?". Gonna explain it with example code since it's easier:

>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
2

When you lower() the Turkish uppercase letter ???, it returns a 2 chars long string with the first character being ?i?, and the second being chr(775).

Should it not simply return ?i??

----------
components: Unicode
messages: 325646
nosy: ezio.melotti, vstinner, zamsalak
priority: normal
severity: normal
status: open
title: lower() on Turkish letter "?" returns a 2-chars-long string
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:05:55 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Sep 2018 14:05:55 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537279555.56.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

vfork() is more dangerous than fork() because the parent and child processes share memory (not copy-on-write, but really the same memory). Whether or not this affects posix_spawn depends on its implementation (to give a very vague statement).

Glibc already uses vfork() in a number of cases, I'd expect that those are the cases where it is safe to use vfork() in the implementation of posix_spawn in the context of glibc.  I'd therefore carefully test the use of vfork() in other cases to make sure those don't affect the parent process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:14:29 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 18 Sep 2018 14:14:29 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537280069.36.0.956365154283.issue17239@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

> * only Windows and macOS will get the fix

Modules/expat can be used on all platforms. A downstream patch is only a problem for platforms that compile Python with "./configure --with-system-expat".

The security fixes for entity expansion blowup and external entity loading are backwards incompatible fixes. Technically they also violate XML standards. In practice the vast majority of users will never run into the issue, because external entities are scarcely used. The expat parser is a non-validating XML parser, so DTDs aren't useful at all. I'd rather break a handful of users than to keep the majority of users vulnerable.

To fix billion laughs and quadratic blowup once and for all, we also have to break backwards compatibility and require expat >= 2.3.0. For now the modules still work with old versions of expat. IMO it's fine. Vendors either have to update their libraries or use our copy of expat.

Ultimately it's Benjamin's, Larry's, and Ned's decision. They are release managers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:15:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 14:15:43 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1537280143.02.0.956365154283.issue34723@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Should it not simply return ?i??

Python implements the Unicode standard.

>>> "U+%04x" % ord("?")
'U+0130'
>>> ["U+%04x" % ord(ch) for ch in "?".lower()]
['U+0069', 'U+0307']

>>> unicodedata.name("?")
'LATIN CAPITAL LETTER I WITH DOT ABOVE'
>>> [unicodedata.name(ch) for ch in "?".lower()]
['LATIN SMALL LETTER I', 'COMBINING DOT ABOVE']

At the C level(), lower_ucs4() calls _PyUnicode_ToLowerFull() which lookup into Python internal Unicode database.

U+0130 character enters the EXTENDED_CASE_MASK case: use _PyUnicode_ExtendedCase secondary database for "extended case".

Well, at the end, Python uses the following data file from the Unicode standard:

https://www.unicode.org/Public/9.0.0/ucd/SpecialCasing.txt

Extract:
"""
# Preserve canonical equivalence for I with dot. Turkic is handled below.

0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE
"""


If you want to convert strings differently for the special case of Turkish, you need to use a different standard than Unicode...

I close the issue as NOT A BUG.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:16:38 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Sep 2018 14:16:38 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1537280198.72.0.956365154283.issue34597@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

@Zorg: you don't need to sell the usefulness of this functionality. Its just that the python developers are volunteers and hence have limited time to work on python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:18:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 14:18:02 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537280282.17.0.956365154283.issue34663@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If glibc already uses vfork() if it is safe, I suppose that using vfork() in other cases is unsafe, and we shouldn't support this nonstandard option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:34:22 2018
From: report at bugs.python.org (Zorg)
Date: Tue, 18 Sep 2018 14:34:22 +0000
Subject: [issue34597] Python needs to check existence of functions at runtime
 for targeting older macOS platforms
In-Reply-To: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>
Message-ID: <1537281262.57.0.956365154283.issue34597@psf.upfronthosting.co.za>


Zorg <zorgiepoo at gmail.com> added the comment:

I understand that. I was mainly responding to a question that was asked with information I felt was important to provide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34597>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:37:36 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 18 Sep 2018 14:37:36 +0000
Subject: [issue31635] test_strptime failure on OpenBSD
In-Reply-To: <1506677537.11.0.213398074469.issue31635@psf.upfronthosting.co.za>
Message-ID: <1537281456.65.0.956365154283.issue31635@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Bug reported to BSD here: https://marc.info/?l=openbsd-bugs&m=153728102618747&w=2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31635>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:46:05 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 14:46:05 +0000
Subject: [issue25825] AIX shared library extension modules installation broken
In-Reply-To: <1470842572.94.0.363425551546.issue25825@psf.upfronthosting.co.za>
Message-ID: <a3dc190b-b6a8-8ef0-e675-6eea2b012fc2@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/08/2016 17:22, David Edelsohn wrote:
> David Edelsohn added the comment:
Hi, Just thought I would mention that I have a branch with all the test
PR fixes I have made in the last two months.

a) would appreciate your testig them with gcc - to be sure all is good
there as well.
b) If all test also pass for you - maybe if you make a bit of noise
python may be a bit quicker to actually merge them.

Hope this helps (AIX :) )

Michael

Links:
https://github.com/python/cpython/pulls?q=is%3Apr+is%3Aopen+AIX+author%3Aaixtools
https://github.com/aixtools/cpython/tree/aix-pr

----------
title: AIX shared library extension modules installation broken: wrong dir names -> AIX shared library extension modules installation broken

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25825>
_______________________________________

From report at bugs.python.org  Tue Sep 18 10:48:56 2018
From: report at bugs.python.org (Joe Pamer)
Date: Tue, 18 Sep 2018 14:48:56 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537282136.25.0.956365154283.issue32557@psf.upfronthosting.co.za>


Joe Pamer <joe at noteven.org> added the comment:

Got it - thanks! That sounds good to me, so I'll take a look at how other functions are working around MAX_PATH and update the diff to also avoid the copy when possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:08:46 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 15:08:46 +0000
Subject: [issue25825] AIX shared library extension modules installation broken
In-Reply-To: <a3dc190b-b6a8-8ef0-e675-6eea2b012fc2@felt.demon.nl>
Message-ID: <65a0ba95-cc28-b129-ff55-12d112038405@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 18/09/2018 16:46, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:

Ignore this. If only I could remove stuff!

Good day all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25825>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:19:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Sep 2018 15:19:31 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1537283971.94.0.956365154283.issue34722@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Have a look at line 512 in Python/marshal.c which calls PyObject_GetIter().  We would need to add PySequence_List() and PyList_Sort().  This will slow down marshaling but would make the bytecode deterministic.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:27:30 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Sep 2018 15:27:30 +0000
Subject: [issue34719] Deprecate set to frozenset conversion in set.__contains__
In-Reply-To: <1537271849.84.0.956365154283.issue34719@psf.upfronthosting.co.za>
Message-ID: <1537284450.21.0.956365154283.issue34719@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34719>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:27:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Sep 2018 15:27:36 +0000
Subject: [issue34719] Deprecate set to frozenset conversion in set.__contains__
In-Reply-To: <1537271849.84.0.956365154283.issue34719@psf.upfronthosting.co.za>
Message-ID: <1537284456.87.0.956365154283.issue34719@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
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/issue34719>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:29:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 15:29:44 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1537284584.35.0.956365154283.issue34722@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Not all types are orderable.

>>> sorted({'', None})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'NoneType' and 'str'

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:38:59 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 18 Sep 2018 15:38:59 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1537285139.35.0.956365154283.issue34722@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:56:11 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Sep 2018 15:56:11 +0000
Subject: [issue34719] Deprecate set to frozenset conversion in set.__contains__
In-Reply-To: <1537271849.84.0.956365154283.issue34719@psf.upfronthosting.co.za>
Message-ID: <1537286171.85.0.956365154283.issue34719@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The feature was first implemented in Lib/sets.py (arising from PEP 218) in pure python. It was found to be useful and carried forward to the C implementation for the built-in type.  The feature is documented but not highlighted in the Library Reference, "Both set and frozenset support set to set comparisons."

You are correct that feature became less performant when the swap-bodies code was eliminated; however, the feature still has value so that a user can write "s in t" rather than "frozenset(s) in t".

Thank you for the suggestion, but I'm going to elect to leave the code as-is. There's no reason break other people's code and remove a feature that is intentional, guaranteed, tested, and sometimes useful in applications that have sets of frozensets.

If you don't like the feature, it is okay to not use it ;-)

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34719>
_______________________________________

From report at bugs.python.org  Tue Sep 18 11:57:02 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 18 Sep 2018 15:57:02 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537286222.24.0.956365154283.issue34663@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

You still need to allow the flag as being safe or unsafe depends on the user code as glibc cannot know about the details of what is going to be executed. That is the reason they have the flag, so the user can disambiguate if is safe or not. If we don't expose the flag, the user may know that what is going to do is safe or acceptable but then they cannot activate the use of vfork.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 12:04:51 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 18 Sep 2018 16:04:51 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537286691.39.0.956365154283.issue34663@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Some interesting read:

Go is using vfork/posix_spawn when possible:

https://github.com/golang/go/issues/5838

And it seems that have interesting results:

https://about.gitlab.com/2018/01/23/how-a-fix-in-go-19-sped-up-our-gitaly-service-by-30x/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 12:10:32 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 16:10:32 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537287032.44.0.956365154283.issue34582@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d0f49d2f5085ca68e3dc8725f1fb1c9674bfb5ed by Steve Dower in branch 'master':
bpo-34582: Adds JUnit XML output for regression tests (GH-9210)
https://github.com/python/cpython/commit/d0f49d2f5085ca68e3dc8725f1fb1c9674bfb5ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Tue Sep 18 12:49:27 2018
From: report at bugs.python.org (Jeremiah Rosen)
Date: Tue, 18 Sep 2018 16:49:27 +0000
Subject: [issue34724] argparse subparser help indent too short
Message-ID: <1537289367.73.0.956365154283.issue34724@psf.upfronthosting.co.za>


New submission from Jeremiah Rosen <takingitcasual at gmail.com>:

The help is indented too early for subparsers with long argument names. I'm currently using the ProperIndentParser class from the following gist to create my top level parser, which fixes the issue:

https://gist.github.com/TakingItCasual/df40932dcc30012325bfed241bdaabd0

----------
components: Library (Lib)
messages: 325663
nosy: Jeremiah Rosen
priority: normal
severity: normal
status: open
title: argparse subparser help indent too short
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34724>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:00:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 17:00:09 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537290009.85.0.956365154283.issue34472@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4ba3b50bfe6d50cd82d208023ea23e203ab50589 by Serhiy Storchaka (Silas Sewell) in branch 'master':
bpo-34472: Add data descriptor signature to zipfile (GH-8871)
https://github.com/python/cpython/commit/4ba3b50bfe6d50cd82d208023ea23e203ab50589


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:03:31 2018
From: report at bugs.python.org (TakingItCasual)
Date: Tue, 18 Sep 2018 17:03:31 +0000
Subject: [issue34724] argparse subparser help indent too short
In-Reply-To: <1537289367.73.0.956365154283.issue34724@psf.upfronthosting.co.za>
Message-ID: <1537290211.59.0.956365154283.issue34724@psf.upfronthosting.co.za>


TakingItCasual <takingitcasual at gmail.com> added the comment:

More detailed explanation on the SO post I found the HelpFormatter class from:

https://stackoverflow.com/q/32888815/2868017

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34724>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:04:17 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 17:04:17 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537290257.85.0.956365154283.issue34472@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8821

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:04:34 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 17:04:34 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537290274.44.0.956365154283.issue34472@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8822

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:26:47 2018
From: report at bugs.python.org (Mario)
Date: Tue, 18 Sep 2018 17:26:47 +0000
Subject: [issue34725] Py_GetProgramFullPath() odd behaviour in Windows
Message-ID: <1537291607.58.0.956365154283.issue34725@psf.upfronthosting.co.za>


New submission from Mario <mariofutire at gmail.com>:

According to the doc Py_GetProgramFullPath() should return the full path of the program name as set by Py_SetProgramName().

https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath

This works well in Linux, but in Windows it is always the name of the current executable (from GetModuleFileNameW).

This is because the 2 files Modules/getpath.c and PC/getpathp.c have completely different logic in calculate_program_full_path() vs get_program_full_path().

This difference is harmless when running in the normal interpreter (python.exe), but can be quite dramatic when embedding python into a C application.

The value returned by Py_GetProgramFullPath() is the same as sys.executable in python.

Why this matters? For instance in Linux virtual environments work out of the box for embedded applications, while they are completely ignored in Windows.

python -m venv abcd

and then if I run my app inside the (activated) abcd environment in Linux I can access the same modules as if I were executing python, while in Windows I still get the system module search path.

If you execute the attached program in Linux you get

EXECUTABLE /tmp/abcd/bin/python3
PATH ['/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/tmp/abcd/lib/python3.7/site-packages']

in Windows

EXECUTABLE c:\TEMP\vsprojects\ConsoleApplication1\x64\Release\ConsoleApplication1.exe
PATH ['C:\\TEMP\\venv\\abcd\\Scripts\\python37.zip', 'C:\\Python37\\Lib', 'C:\\Python37\\DLLs', 'c:\\TEMP\\vsprojects\\ConsoleApplication1\\x64\\Relea
se', 'C:\\Python37', 'C:\\Python37\\lib\\site-packages']

with a mixture of paths from the venv, system and my app folder.
But more importantly site-packages comes from the system (bad!).

This is because site.py at lines 454 uses the path of the interpreter to locate the venv configuration file.

So in the end, virtual environments work out of the box in Linux even for an embedded python, but not in Windows.

----------
components: Interpreter Core, Windows
files: poc.c
messages: 325666
nosy: mariofutire, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Py_GetProgramFullPath() odd behaviour in Windows
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47814/poc.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34725>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:33:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 17:33:01 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537291981.31.0.956365154283.issue34341@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8823

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Tue Sep 18 13:34:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 17:34:32 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537292072.9.0.956365154283.issue34472@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Silas.

Since popular ZIP file implementation like Info-ZIP and Java write this signature unconditionally, I think most unzipping software support it if they support reading ZIP files in streaming mode at all, at it is safe to backport this change to all maintained versions.

----------
type:  -> behavior
versions: +Python 2.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:19:43 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 18:19:43 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537294783.17.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8824

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:19:52 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 18:19:52 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537294792.36.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8825

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:24:38 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 18:24:38 +0000
Subject: [issue34725] Py_GetProgramFullPath() odd behaviour in Windows
In-Reply-To: <1537291607.58.0.956365154283.issue34725@psf.upfronthosting.co.za>
Message-ID: <1537295078.42.0.956365154283.issue34725@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

That executable doesn't appear to be in a virtual environment - you should be running C:\TEMP\venv\abcd\Scripts\python.exe

Does that resolve your problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34725>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:25:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 18:25:53 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537295153.34.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8826

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:26:18 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 18:26:18 +0000
Subject: [issue34725] Py_GetProgramFullPath() odd behaviour in Windows
In-Reply-To: <1537291607.58.0.956365154283.issue34725@psf.upfronthosting.co.za>
Message-ID: <1537295178.83.0.956365154283.issue34725@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

(Also, the behavior of Py_GetProgramFullPath is intentional, but we do have another bug somewhere to be able to override it for embedding purposes. sys.executable should be None when it does not contain a suitable path for running the normal Python interpreter again. I haven't searched for that bug just now, but we should find it and track the issue there, rather than creating a different issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34725>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:48:34 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 18:48:34 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537296514.31.0.956365154283.issue34582@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 1a89cb5c479d8e4f467d7f96e1781c7275cefa88 by Steve Dower (Miss Islington (bot)) in branch '3.7':
bpo-34582: Adds JUnit XML output for regression tests (GH-9210)
https://github.com/python/cpython/commit/1a89cb5c479d8e4f467d7f96e1781c7275cefa88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Tue Sep 18 14:58:14 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Sep 2018 18:58:14 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537297094.71.0.956365154283.issue34582@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset c9276495fc497898544a38b244b38ff61797f32d by Steve Dower (Miss Islington (bot)) in branch '3.6':
bpo-34582: Adds JUnit XML output for regression tests (GH-9210)
https://github.com/python/cpython/commit/c9276495fc497898544a38b244b38ff61797f32d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:22:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 19:22:35 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1537298555.24.0.956365154283.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 79d1c2e6c9d1bc1cf41ec3041801ca1a2b9a995b by Serhiy Storchaka in branch 'master':
bpo-25711: Rewrite zipimport in pure Python. (GH-6809)
https://github.com/python/cpython/commit/79d1c2e6c9d1bc1cf41ec3041801ca1a2b9a995b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:32:01 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Sep 2018 19:32:01 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537299121.53.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I get the impression that go uses vfork on Linux, not posix_spawn, because go doesn't use libc (based on reading the referenced issue, not on deep knowledge of go and its implementation).

I do wonder why glibc's implementation of posix_spawn doesn't use vfork more often, and in which cases it is safe to explicitly use vfork even when glibc won't do so by default.

Enabling the use of vfork without determining when it safe to do so is asking for problems, and hard to debug/reproduce ones at that (due to vfork semantics).  Adding a "use_vfork" keyword argument to posix_spawn is IMHO not the right way to go, it would be better to determine when using vfork is safe and then unconditionally enable it.  Otherwise users will have to do the research.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:32:41 2018
From: report at bugs.python.org (Thomas Sibley)
Date: Tue, 18 Sep 2018 19:32:41 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537299161.56.0.956365154283.issue9148@psf.upfronthosting.co.za>


Change by Thomas Sibley <python at zulutango.org>:


----------
nosy: +trs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:34:56 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 18 Sep 2018 19:34:56 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537299296.2.0.956365154283.issue9148@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:42:11 2018
From: report at bugs.python.org (Mario)
Date: Tue, 18 Sep 2018 19:42:11 +0000
Subject: [issue34725] Py_GetProgramFullPath() odd behaviour in Windows
In-Reply-To: <1537295078.42.0.956365154283.issue34725@psf.upfronthosting.co.za>
Message-ID: <ffa2b0af-ac13-1efb-37e1-72c885a84458@gmail.com>


Mario <mariofutire at gmail.com> added the comment:

On 18/09/2018 19:24, Steve Dower wrote:
> 
> Steve Dower <steve.dower at python.org> added the comment:
> 
> That executable doesn't appear to be in a virtual environment - you should be running C:\TEMP\venv\abcd\Scripts\python.exe
> 
> Does that resolve your problem?
> 

Nope,

I am *not* running python, I am running a C app which embeds the python interpreter.
I am running exactly

c:\TEMP\vsprojects\ConsoleApplication1\x64\Release\ConsoleApplication1.exe

In a later comment you say the behaviour of Py_GetProgramFullPath is intentional: which behaviour? 
Windows? Linux? or the fact that they behave differently?

I guess that if there were a way to force Py_GetProgramFullPath() it would solve my problem, because 
I could direct site.py towards the correct virtual environment.

If sys.executable becomes None for embedded python (without the ability to set it), then virtual 
environments wont work at all, which would be sad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34725>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:49:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 19:49:50 +0000
Subject: [issue34726] Add support of checked hash-based pycs in zipimport
Message-ID: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently zipimport refuses to handle checked hash-based pycs (PEP 552).

----------
components: Library (Lib)
messages: 325675
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Add support of checked hash-based pycs in zipimport
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34726>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:54:36 2018
From: report at bugs.python.org (cowlinator)
Date: Tue, 18 Sep 2018 19:54:36 +0000
Subject: [issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts
 with cmd console
Message-ID: <1537300476.3.0.956365154283.issue34727@psf.upfronthosting.co.za>


New submission from cowlinator <cowlinator at gmail.com>:

I can consistently reproduce a bug in 2.7.15 on Windows which causes an unexpected IOError.

Steps to reproduce:

Enter the following code in a plain-vanilla windows command line console:

>>> import sys
>>> while True:
...     sys.stdout.write('.')

Then, pause the output, either by clicking and holding the scrollbar for 10 seconds, or by highlighting text with the mouse for 10 seconds and then pressing 'enter' to un-highlight.
Upon resuming, the following error is seen:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
IOError: [Errno 0] Error

----------
components: IO, Windows
messages: 325676
nosy: cowlinator, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows/2.7.15 IOError [Errno 0] when user interacts with cmd console
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34727>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:56:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 19:56:36 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1537300596.34.0.956365154283.issue25711@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8827

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Tue Sep 18 15:57:24 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 18 Sep 2018 19:57:24 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537300644.57.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I did some more research:

* <https://sourceware.org/bugzilla/show_bug.cgi?id=10354> seems to indicate that glibc switched to a different implementation of posix_spawn that uses clone(2) instead of fork()/vfork() to avoid some problems with vfork(). 

The start of the issue also contains some information on why glibc is (was?) so conservative about using vfork, and a possible work around (disable cancelation points around the call to posix_spawn).

* <https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/spawni.c> is the source for the guts of posix_spawn for some version of glibc, and that indeed does use clone(...|CLONE_VFORK...) unconditionally and does not appear to test for POSIX_SPAWN_USEVFORK. 



It looks like the advise to use POSIX_SPAWN_USEVFORK is outdated, although I'm not 100% sure of my conclusion.  A glibc expert should be able to confirm or refute this. 

@pablogsal: do you have more information on why you want to enable this flag? Do you have measurements that show that adding this flag helps?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:05:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2018 20:05:04 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537301104.4.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh wow, I didn't expect that exposing a constant would be a source of such deep debate!

(I'm not saying that the debate is useless or negative, it's useful and constructive, just I'm surprised how system programming can be hard sometimes!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:20:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:20:02 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1537302002.87.0.956365154283.issue25711@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:26:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:26:03 +0000
Subject: [issue34726] Add support of checked hash-based pycs in zipimport
In-Reply-To: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>
Message-ID: <1537302363.39.0.956365154283.issue34726@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8829
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34726>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:27:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:27:22 +0000
Subject: [issue34726] Add support of checked hash-based pycs in zipimport
In-Reply-To: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>
Message-ID: <1537302442.0.0.956365154283.issue34726@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -8829

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34726>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:27:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:27:30 +0000
Subject: [issue34726] Add support of checked hash-based pycs in zipimport
In-Reply-To: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>
Message-ID: <1537302450.03.0.956365154283.issue34726@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34726>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:28:31 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 18 Sep 2018 20:28:31 +0000
Subject: [issue32245] OSError: raw write() returned invalid length on latest
 Win 10 Consoles
In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za>
Message-ID: <1537302511.84.0.956365154283.issue32245@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> third party
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32245>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:28:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:28:38 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537302518.25.0.956365154283.issue34341@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 29034baf58156e2462b0680e9092c0a3cccb0798 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-34341: Fix appending to ZIP archives with the ZIP64 extension. (GH-8683). (GH-9400)
https://github.com/python/cpython/commit/29034baf58156e2462b0680e9092c0a3cccb0798


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:33:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:33:39 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537302819.05.0.956365154283.issue34472@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8830

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:34:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 20:34:16 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1537302856.72.0.956365154283.issue34341@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:36:52 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 18 Sep 2018 20:36:52 +0000
Subject: [issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts
 with cmd console
In-Reply-To: <1537300476.3.0.956365154283.issue34727@psf.upfronthosting.co.za>
Message-ID: <1537303012.68.0.956365154283.issue34727@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

This may be the same problem as issue 32245, which was a third-party bug that Microsoft fixed in the last Spring update of Windows 10. Which version of Windows are you using?

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34727>
_______________________________________

From report at bugs.python.org  Tue Sep 18 16:59:11 2018
From: report at bugs.python.org (cowlinator)
Date: Tue, 18 Sep 2018 20:59:11 +0000
Subject: [issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts
 with cmd console
In-Reply-To: <1537300476.3.0.956365154283.issue34727@psf.upfronthosting.co.za>
Message-ID: <1537304351.37.0.956365154283.issue34727@psf.upfronthosting.co.za>


cowlinator <cowlinator at gmail.com> added the comment:

I think you are probably right.  
I'm using Windows 10 Version 1709 (OS Build 16299.611)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34727>
_______________________________________

From report at bugs.python.org  Tue Sep 18 17:03:09 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 18 Sep 2018 21:03:09 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537304589.32.0.956365154283.issue9148@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Python doesn't go out of its way to fake a cross-platform POSIX environment in Windows, complete with emulated fork and exec. I don't recommend using nt.execv[e] or the os.exec* functions in Windows. Their behavior is almost always undesired. I'd be in favor of deprecating them and eventually removing them. Use subprocess instead.

----------
nosy: +eryksun
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 17:42:20 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 18 Sep 2018 21:42:20 +0000
Subject: [issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts
 with cmd console
In-Reply-To: <1537300476.3.0.956365154283.issue34727@psf.upfronthosting.co.za>
Message-ID: <1537306940.28.0.956365154283.issue34727@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

With Windows 10 release 1803, I can't reproduce either this problem or the problems from issue 32245. I'm marking this issue closed as a duplicate. Open a new issue if you still experience the problem after updating to Windows 10 release 1803 or 1809.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> OSError: raw write() returned invalid length on latest Win 10 Consoles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34727>
_______________________________________

From report at bugs.python.org  Tue Sep 18 17:44:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 21:44:05 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
Message-ID: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.sleep is a coroutine; passing a *loop* argument to it makes no sense anymore.

We should raise a DeprecationWarning in Python 3.8 and 3.9 and remove it in 4.0.

----------
components: asyncio
keywords: easy
messages: 325684
nosy: asvetlov, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: deprecate *loop* argument for asyncio.sleep
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Tue Sep 18 17:49:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 21:49:28 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
In-Reply-To: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>
Message-ID: <1537307368.53.0.956365154283.issue34728@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Same for asyncio.wait and asyncio.wait_for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Tue Sep 18 17:55:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 21:55:48 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537307748.17.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 471503954a91d86cf04228c38134108c67a263b0 by Yury Selivanov in branch 'master':
bpo-33649: Add a high-level section about Futures; few quick fixes (GH-9403)
https://github.com/python/cpython/commit/471503954a91d86cf04228c38134108c67a263b0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 17:55:55 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 21:55:55 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537307755.53.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8831

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 18:09:55 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 22:09:55 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537308595.64.0.956365154283.issue33649@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 73c0006e71683b7d5b28192f18a2b9796e4195ef by Miss Islington (bot) in branch '3.7':
bpo-33649: Add a high-level section about Futures; few quick fixes (GH-9403)
https://github.com/python/cpython/commit/73c0006e71683b7d5b28192f18a2b9796e4195ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Tue Sep 18 18:17:30 2018
From: report at bugs.python.org (Thomas Sibley)
Date: Tue, 18 Sep 2018 22:17:30 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537309050.11.0.956365154283.issue9148@psf.upfronthosting.co.za>


Thomas Sibley <python at zulutango.org> added the comment:

What about using _execv*() and friends, as documented at <https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/execvp-wexecvp?view=vs-2017>?

They appear to use the process overlay feature of _spawnv*() et al., as described at <https://docs.microsoft.com/en-us/cpp/c-runtime-library/spawn-wspawn-functions?view=vs-2017> and <https://docs.microsoft.com/en-gb/cpp/c-runtime-library/process-and-environment-control?view=vs-2017>.

----------
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 18:27:15 2018
From: report at bugs.python.org (Thomas Sibley)
Date: Tue, 18 Sep 2018 22:27:15 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537309635.62.0.956365154283.issue9148@psf.upfronthosting.co.za>


Thomas Sibley <python at zulutango.org> added the comment:

It seems like it would be very nice to provide compat if its possible with a minimum of effort.

At the very least, a doc patch to os.exec*() seems warranted.  I expected to find notes on platform compat in the doc and was pleasantly surprised to see the indication of Windows support!  Only later did I find out that it is not meaningfully supported.  :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 18:42:06 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 18 Sep 2018 22:42:06 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537310526.91.0.956365154283.issue9148@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

nt.execv[e] wraps calling the C runtime _wexecv[e] function. The other os.exec* functions are in turn based on these calls. As to spawn, for Windows _P_OVERLAY just means to exit the current process. The source code is published, so you can see how simple the implementation is in ucrt\exec\spawnv.cpp:

    if (mode == _P_OVERLAY)
    {
        // Destroy ourselves:
        _exit(0);
    }

If I recall correctly, in the early 80s, Microsoft's C runtime was used for both MS-DOS and Xenix (Unix) development. One assumes that the overlay option was actually useful in Xenix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 18:49:05 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 18 Sep 2018 22:49:05 +0000
Subject: [issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is
 not called
Message-ID: <1537310945.11.0.956365154283.issue34729@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The compressor/decompressor classes from bz2 and lzma modules rely on __init__() for initialization, but it is not guaranteed to be called. Method calls on an uninitialized object crash:

>>> from bz2 import BZ2Compressor as C
>>> c = C.__new__(C)
>>> c.compress(b'')
Segmentation fault (core dumped)

I see two ways to fix this:

1) Move some initialization (notably, for "lock" field) to __new__() and add initialization checks to other methods. This should be backwards-compatible.

2) Move all initialization to __new__(). Since compressor/decompressor classes are not subclassable, it'll break only code than repeatedly calls __init__() on the same object. The simplicity of the fix might outweigh the necessity to support such code.
(However, in 2.7, classes in bz2 *are* subclassable; lzma is not present in 2.7).

Which way is more preferable?

----------
components: Extension Modules
messages: 325691
nosy: berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: bz2/lzma: Compressor/decompressor crash if __init__ is not called
type: crash
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34729>
_______________________________________

From report at bugs.python.org  Tue Sep 18 18:52:38 2018
From: report at bugs.python.org (Thomas Sibley)
Date: Tue, 18 Sep 2018 22:52:38 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1537311158.95.0.956365154283.issue9148@psf.upfronthosting.co.za>


Thomas Sibley <python at zulutango.org> added the comment:

Thanks for taking the time to explain.  I was just discovering the same myself experimentally.  The MS docs I linked to seem a little misleading. orz

In that case, do you think a doc patch for os.exec* adding a more nuanced take on Windows support would be considered?  I'd be glad to write it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9148>
_______________________________________

From report at bugs.python.org  Tue Sep 18 19:09:12 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 18 Sep 2018 23:09:12 +0000
Subject: [issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is
 not called
In-Reply-To: <1537310945.11.0.956365154283.issue34729@psf.upfronthosting.co.za>
Message-ID: <1537312152.22.0.956365154283.issue34729@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I think we usually went with option 1 when we fixed similar issues in the past.

See also issue 23224 for the same problem in *Decompressor classes of lzma and bz2 modules. It looks like the attached PR to that issue went with option 2: PR 7822.

Perhaps we can combine this and issue 23224.

----------
resolution:  -> duplicate
stage:  -> needs patch
superseder:  -> LZMADecompressor object is only initialized in __init__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34729>
_______________________________________

From report at bugs.python.org  Tue Sep 18 19:29:21 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 18 Sep 2018 23:29:21 +0000
Subject: [issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is
 not called
In-Reply-To: <1537310945.11.0.956365154283.issue34729@psf.upfronthosting.co.za>
Message-ID: <1537313361.34.0.956365154283.issue34729@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I somehow failed to notice #23224 when I searched the tracker. You're right, it's the same, and, moreover, PR 7822 fixes problem with both compressors and decompressors (though it includes tests only for the latter for some reason).

I think that this report should be closed as duplicate, but should we also change the title of #23224 to be more general?

----------
resolution: duplicate -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34729>
_______________________________________

From report at bugs.python.org  Tue Sep 18 19:30:54 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 18 Sep 2018 23:30:54 +0000
Subject: [issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is
 not called
In-Reply-To: <1537310945.11.0.956365154283.issue34729@psf.upfronthosting.co.za>
Message-ID: <1537313454.52.0.956365154283.issue34729@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Reclosing (browser cache problem).

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34729>
_______________________________________

From report at bugs.python.org  Tue Sep 18 19:35:38 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 18 Sep 2018 23:35:38 +0000
Subject: [issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is
 not called
In-Reply-To: <1537310945.11.0.956365154283.issue34729@psf.upfronthosting.co.za>
Message-ID: <1537313738.25.0.956365154283.issue34729@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

We can definitely make the title of that issue more descriptive. Feel free to change it -- IIRC, you don't need additional permissions to change the title of an issue. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34729>
_______________________________________

From report at bugs.python.org  Tue Sep 18 19:38:04 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 18 Sep 2018 23:38:04 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537313884.31.0.956365154283.issue34663@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Give all of this, the lesson I'd take away is perhaps that we should just provide the constant in the os module when available at build time (a configure check) and let people who find a need to use it on their system check for its presence and use it in their code.

The general theme of the posix / os module is intentionally low level:  Expose the APIs and let people make decisions about when to use what at a higher level.

It sounds like a use_vfork=XXX parameter is undesirable at this point unless you wanted to make it clear by its name that it is a glibc only thing feature glibc_use_vfork=XXX perhaps (if exposing the POSIX_SPAWN_USEVFORK flag name itself to be or'ed in is undesirable from a Pythonic API point of view).

The problem with a parameter such named is that you then have to decide on error semantics and need a way for people to know when they can or can't use it prior to calling posix_spawn() itself.

With a constant that you or into flags, you can use hasattr to check the presence of the constant to determine if you can try using it.  (the libc call could still return an error which we'd turn into an OSError exception if the API call doesn't support that flag or otherwise doesn't like the combination of flags you passed - but that situation is always possible in any API)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Tue Sep 18 19:51:59 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 18 Sep 2018 23:51:59 +0000
Subject: [issue23224] bz2/lzma: Compressor/Decompressor objects are only
 initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1537314719.9.0.956365154283.issue23224@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

bz2 in 2.7 is also affected.

Victor, do we want to fix the crash at all in stable branches? If yes, IMHO taking the slight risk of __init__ -> __new__ change is preferable to taking the trouble to implement the alternative backwards-compatible fix (init checks in all methods) for stable branches.

----------
nosy: +izbyshev
title: LZMADecompressor object is only initialized in __init__ -> bz2/lzma: Compressor/Decompressor objects are only initialized in __init__
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23224>
_______________________________________

From report at bugs.python.org  Tue Sep 18 20:27:26 2018
From: report at bugs.python.org (Devin Fee)
Date: Wed, 19 Sep 2018 00:27:26 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
Message-ID: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>


New submission from Devin Fee <devin at devinfee.com>:

I expected an async-generator's aclose() method to cancel it's __anext__(). Instead, the task isn't cancelled, and (it seems) manually cleanup is necessary.


@pytest.mark.asyncio
async def test_aclose_cancels():
    done = False
    event = asyncio.Event()
    agen = None

    async def make_agen():
        try:
            await event.wait()
            raise NotImplementedError()
            yield  # pylint: disable=W0101, unreachable
        finally:
            nonlocal done
            done = True

    async def run():
        nonlocal agen
        agen = make_agen()
        await agen.__anext__()

    task = asyncio.ensure_future(run())
    await asyncio.sleep(.01)

    await agen.aclose()
    await asyncio.sleep(.01)

    assert done
    assert task.done() and task.exception()


Looking at the tests for CPython, the implementation seems to expect it, but I'm unclear if PEP-525 actually intends for this to be the case: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/test/test_asyncgen.py#L657

Alternatively, maybe I shouldn't be calling aclose, and instead I should be cancelling the task:

@pytest.mark.asyncio
async def test_cancel_finalizes():
    done = False
    event = asyncio.Event()
    agen = None

    async def make_agen():
        try:
            await event.wait()
            raise NotImplementedError()
            yield  # pylint: disable=W0101, unreachable
        finally:
            nonlocal done
            done = True

    async def run():
        nonlocal agen
        agen = make_agen()
        await agen.__anext__()

    task = asyncio.ensure_future(run())
    await asyncio.sleep(.01)
    task.cancel()
    await asyncio.sleep(.01)

    assert done
    assert task.done()

So the "bug" here is one of PEP-525 clarification.

----------
components: asyncio
messages: 325699
nosy: asvetlov, dfee, yselivanov
priority: normal
severity: normal
status: open
title: aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Tue Sep 18 21:51:28 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Sep 2018 01:51:28 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537321888.14.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 00:00:05 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 19 Sep 2018 04:00:05 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1537329605.93.0.956365154283.issue13285@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Here's another case where this bug bites us: https://github.com/python-trio/trio/issues/673

At startup, Trio checks if SIGINT is currently being handled by Python's default SIGINT handler, and if so it substitutes its own SIGINT handler (which works just like the default SIGINT handler, except with some added magic [1]).

However, this user has a C library that installs its own handler for SIGINT. When this happens, the Python signal.getsignal() function returns stale, incorrect information (claiming that the Python signal handler is still working, even though it isn't), and this causes Trio to do the wrong thing.

Vilya's "magic cookie" approach above is the one that I was going to suggest before I saw this bug :-).

Jeroen's version seems more complicated than necessary to me, and also it doesn't seem to work for my case: I need to check what the current signal handler is and make some decision based on that result. In Jeroen's API, I can see what the Python-level signal handler is, but there's no way to find out whether that signal handler is actually in use or not. Instead, we should make signal.getsignal() do something like:

  c_handler = PyOS_getsig(signalnum);
  if c_handler == the_python_signal_handler:
      # Python is handling this signal; return the Python-level handler
      return Handlers[signalnum].func
  elif c_handler in [SIG_DFL, SIG_IGN]:
      return c_handler
  else:
      return OpaqueCookie(c_handler)

[1] https://vorpus.org/blog/control-c-handling-in-python-and-trio/

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Wed Sep 19 01:34:46 2018
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 19 Sep 2018 05:34:46 +0000
Subject: [issue34731] pathlib path.match misshandles multiple `**`
Message-ID: <1537335286.28.0.956365154283.issue34731@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <bugs.python.org at ronnypfannschmidt.de>:

when porting parts of pytest to pathlib we noted that `path.match` does not quite match normal fnmatch for usages of `**`

i believe this is related to always splitting the patter completely and not handling `**` in that case

Bruno wrote https://github.com/pytest-dev/pytest/pull/3980/files#diff-63fc5ed688925b327a5af20405bf4b09R19 as a workaround

----------
components: Library (Lib)
messages: 325701
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: pathlib path.match misshandles multiple `**`

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34731>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:10:00 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 Sep 2018 06:10:00 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1537277959.11.0.956365154283.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537337396.228987.1513063536.539AFEBA@webmail.messagingengine.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Tue, Sep 18, 2018, at 06:39, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at redhat.com> added the comment:
> 
> > Who normally updates the vendored libexpat?
> 
> I made the 3 latest libexpat updates, and each of them was painful :-)

Oh? I've updated it twice (4e21100fa7bf66e0b32146d3f46ae16afc73fee1 and 5033aa77aacaa5505636f150e8d54baac5bdca9c), and it didn't seem so bad. I just copied the upstream files in. Did I do it wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:11:36 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 06:11:36 +0000
Subject: [issue34731] pathlib path.match misshandles multiple `**`
In-Reply-To: <1537335286.28.0.956365154283.issue34731@psf.upfronthosting.co.za>
Message-ID: <1537337496.74.0.956365154283.issue34731@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report. This looks like a duplicate of issue 29249.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34731>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:12:34 2018
From: report at bugs.python.org (Devin Fee)
Date: Wed, 19 Sep 2018 06:12:34 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
In-Reply-To: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>
Message-ID: <1537337554.33.0.956365154283.issue34730@psf.upfronthosting.co.za>


Devin Fee <devin at devinfee.com> added the comment:

I've worked around this problem by doing something like this:

async def close_cancelling(agen):
    while True:
        try:
            task = asyncio.ensure_future(agen.__anext__())
            await task
            yield task.result()
        except (GeneratorExit, StopAsyncIteration):
            await agen.aclose()
            task.cancel()
            break


async def run():
    try:
        async for v in close_cancelling(agen):
            received.append(v)
    except asyncio.CancelledError:
        # handle finalization
        pass

Though, I'm still convinced that `aclose()` should call raise `StopAsyncIteration` on `agen.ag_await`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:25:56 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 Sep 2018 06:25:56 +0000
Subject: [issue34585] Don't use AC_RUN_IFELSE to determine float endian
In-Reply-To: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>
Message-ID: <1537338356.24.0.956365154283.issue34585@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 2a9c3805ddedf282881ef7811a561c70b74f80b1 by Benjamin Peterson (Ross Burton) in branch 'master':
closes bpo-34585: Don't do runtime test to get float byte order. (GH-9085)
https://github.com/python/cpython/commit/2a9c3805ddedf282881ef7811a561c70b74f80b1


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34585>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:28:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 06:28:11 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1537338491.34.0.956365154283.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9da3961f364da2a3ced740230b85ffb4309238d3 by Serhiy Storchaka in branch 'master':
bpo-25711: Move _ZipImportResourceReader from importlib to zipimport. (GH-9406)
https://github.com/python/cpython/commit/9da3961f364da2a3ced740230b85ffb4309238d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:33:06 2018
From: report at bugs.python.org (jophine antony)
Date: Wed, 19 Sep 2018 06:33:06 +0000
Subject: [issue34732] uuid returns version more than 5
Message-ID: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>


New submission from jophine antony <jophinep at gmail.com>:

When I validate the invalid uuid (RFC 4122 variant) for example '481a8de5-f0d1-f211-b425-e41f134196da'. It returns version number as 15 which is invalid. We need to retrun None in this case as we do for invalid UUIDs  based on RFC 4122.

------snip snip-------
from uuid import UUID
test_uuid_str = '481a8de5-f0d1-f211-b425-e41f134196da'
print("UUID version: {}".format(UUID(test_uuid_str).version))
print("UUID variant: {}".format(UUID(test_uuid_str).variant))
------snip snip-------

------Result----------
UUID version: 15
UUID variant: specified in RFC 4122
------Result----------

----------
messages: 325707
nosy: jophine pranjal
priority: normal
severity: normal
status: open
title: uuid returns version more than 5
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:49:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 Sep 2018 06:49:08 +0000
Subject: [issue34585] Don't use AC_RUN_IFELSE to determine float endian
In-Reply-To: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>
Message-ID: <1537339748.83.0.956365154283.issue34585@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b3b8cb419e496629873fa7dda82a01863f58617a by Benjamin Peterson in branch 'master':
run autoconf (GH-9411)
https://github.com/python/cpython/commit/b3b8cb419e496629873fa7dda82a01863f58617a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34585>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:53:14 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 06:53:14 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537339994.91.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Victor, no - you've completely broken PEP 538 now.

Please just give up, and implement the PEP as written, and stop trying to use your copious amounts of available development time to railroad me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:54:02 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 06:54:02 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537340042.88.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

3.7.1 should not ship until PEP 538 is once more implemented as documented, without Victor's personal editorialising and feature additions to a maintenance release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:55:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 06:55:14 +0000
Subject: [issue23327] zipimport to import from non-ascii pathname on Windows
In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za>
Message-ID: <1537340114.9.0.956365154283.issue23327@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your patch Swapneel, but this issue was fixed in issue25758.

----------
nosy: +serhiy.storchaka
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23327>
_______________________________________

From report at bugs.python.org  Wed Sep 19 02:59:12 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 06:59:12 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537340352.47.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The only reason this got through my original review was because PEP 540 was implemented when I was going through a personal situation that lead to me quitting my job cold without a new one to go to, so my review of Victors changes to the PEP 538 implementation was pretty cursory.

Now that I've finally reviewed it properly, I can see those changes were fundamentally misguided, and completely missed the intent and purpose of the PEP - it's deliberately designed to work completely differently from PEP 540, but Victor's now turned it into a pale shadow of the latter. (Victor's patch even had to change the locale coercion tests because it broke the isolated mode behaviour described in the PEP)

I was trying to be nice about it, but given that Victor is starting to just go ahead and change things further, I'm going to go with the hardline veto option: make PEP 538 work the it is described in the PEP and stop trying to change it on an arbitrary whim without writing a new PEP to overrule the original one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:00:35 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 07:00:35 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537340435.89.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Note: I won't have time to work on this myself until this weekend at the earliest)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:04:42 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 07:04:42 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537340682.07.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

test_c_locale_coercion *did* test the -E and -I options, by running everything in isolated mode. This was only broken by Victor's changes to the test suite (which broke locale coercion in isolated mode, and hence broke the tests).

As for why PYTHONCLOCALECOERCION=0 and PYTHONCLOCALECOERCION=warn exist even though I don't actually want people to use them, it's because they're a potentially necessary debugging tool if you're seeing an issue that you suspect may be due to locale coercion working on one platform (e.g Fedora), and not working on another (e.g. CentOS 7). You can't easily hide the C.UTF-8 locale from the Python interpreter on Fedora, but you *can* tell the interpreter not to use it.

UTF-8 mode is different, as folks may want to opt in to that regardless of their current locale setting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:11:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:11:29 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1537341089.32.0.956365154283.issue14678@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:12:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:12:47 +0000
Subject: [issue19699] Update zipimport for PEP 451
In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za>
Message-ID: <1537341167.85.0.956365154283.issue19699@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19699>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:13:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:13:04 +0000
Subject: [issue19699] Update zipimport for PEP 451
In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za>
Message-ID: <1537341184.43.0.956365154283.issue19699@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19699>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:18:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:18:32 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537341512.37.0.956365154283.issue5950@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:19:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:19:25 +0000
Subject: [issue32959] zipimport fails when the ZIP archive contains more than
 65535 files
In-Reply-To: <1519679331.45.0.467229070634.issue32959@psf.upfronthosting.co.za>
Message-ID: <1537341565.11.0.956365154283.issue32959@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32959>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:20:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:20:52 +0000
Subject: [issue32075] Expose ZipImporter Type Object in the include header
 files.
In-Reply-To: <1511121369.3.0.213398074469.issue32075@psf.upfronthosting.co.za>
Message-ID: <1537341652.15.0.956365154283.issue32075@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32075>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:21:25 2018
From: report at bugs.python.org (Decorater)
Date: Wed, 19 Sep 2018 07:21:25 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1537341685.08.0.956365154283.issue25711@psf.upfronthosting.co.za>


Change by Decorater <seandhunt_7 at yahoo.com>:


----------
pull_requests: +8832

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:22:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:22:32 +0000
Subject: [issue31531] crash and SystemError in case of a bad
 zipimport._zip_directory_cache
In-Reply-To: <1505914409.29.0.875431371472.issue31531@psf.upfronthosting.co.za>
Message-ID: <1537341752.95.0.956365154283.issue31531@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711). All crashes are gone with the C code.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31531>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:23:41 2018
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 19 Sep 2018 07:23:41 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537341821.91.0.956365154283.issue5950@psf.upfronthosting.co.za>


Dima Tisnek <dimaqq at gmail.com> added the comment:

Very glad to hear!
Let's document what Python version(s) are "fixed".
Perhaps this issue deserves a test case in issue25711.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:30:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:30:50 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1537342250.69.0.956365154283.issue19081@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:30:54 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 07:30:54 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537342254.95.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(The other reason this change should be reverted is because it added a new feature to Python 3.7.1, even though in the earlier discussion we had agreed to leave the as-shipped implementation in 3.7.0 alone for the rest of the Python 3.7.x releases, and only discuss how we wanted it to work in Python 3.8, precisely so that we could have the discussion on a timeline that was amenable to me, without impacting the 3.7.1 release schedule)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:31:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:31:05 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
 'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1537342265.52.0.956365154283.issue14905@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:31:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:31:28 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
 'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1537342288.82.0.956365154283.issue14905@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
stage: patch review -> needs patch
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:32:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:32:15 +0000
Subject: [issue15713] PEP 3121, 384 Refactoring applied to zipimport module
In-Reply-To: <1345154035.4.0.564693100383.issue15713@psf.upfronthosting.co.za>
Message-ID: <1537342335.08.0.956365154283.issue15713@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport have been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15713>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:34:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:34:58 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1537342498.2.0.956365154283.issue18307@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport has been rewritten in pure Python (issue25711).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:36:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:36:02 +0000
Subject: [issue32866] zipimport loader.get_data() requires absolute zip file
 path
In-Reply-To: <1518922161.55.0.467229070634.issue32866@psf.upfronthosting.co.za>
Message-ID: <1537342562.82.0.956365154283.issue32866@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport has been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32866>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:43:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:43:06 +0000
Subject: [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537342986.58.0.956365154283.issue29013@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think we should just revert this. The zipfile module can handle ZIP files up to 4 GiB without the ZIP64 extensions, but it requires the ZIP64 extensions for creating ZIP files larger than 2 GiB. The ZIP64 extensions is required also for ZIP files with more than 65535 files.

----------
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29013>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:53:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:53:50 +0000
Subject: [issue17004] Expand zipimport to include other compression methods
In-Reply-To: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za>
Message-ID: <1537343630.48.0.956365154283.issue17004@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport has been rewritten in pure Python (issue25711). Now it is easier to add support of other compression methods. Although I don't think that reducing the size by 3-8% is worth complicating the code.

If you still need this, I think that the simplest way is importing the zipfile module and monkey patching the simple ZIP file implementation in the zipimport module with zipfile-based implementation. This can be made only after importing zipfile itself, i.e. in case of zipping the stdlib, the zipfile module and its dependencies should be stored uncompressed or with the deflate compression.

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17004>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:54:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:54:42 +0000
Subject: [issue23734] zipimport should not check pyc timestamps against zipped
 py files
In-Reply-To: <1426964347.09.0.21067648462.issue23734@psf.upfronthosting.co.za>
Message-ID: <1537343682.78.0.956365154283.issue23734@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport has been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23734>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:55:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:55:23 +0000
Subject: [issue23769] valgrind reports leaks for test_zipimport
In-Reply-To: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>
Message-ID: <1537343723.37.0.956365154283.issue23769@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport has been rewritten in pure Python (issue25711).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23769>
_______________________________________

From report at bugs.python.org  Wed Sep 19 03:57:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:57:03 +0000
Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant
In-Reply-To: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za>
Message-ID: <1537343823.28.0.956365154283.issue25710@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

zipimport has been rewritten in pure Python (issue25711).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25710>
_______________________________________

From report at bugs.python.org  Wed Sep 19 04:00:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 08:00:47 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537344047.49.0.956365154283.issue5950@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not fixed yet. But it is now easier to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Wed Sep 19 04:13:51 2018
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 19 Sep 2018 08:13:51 +0000
Subject: [issue34731] pathlib path.match misshandles multiple `**`
In-Reply-To: <1537335286.28.0.956365154283.issue34731@psf.upfronthosting.co.za>
Message-ID: <1537344831.66.0.956365154283.issue34731@psf.upfronthosting.co.za>


Ronny Pfannschmidt <bugs.python.org at ronnypfannschmidt.de> added the comment:

indeed it is, thanks for the reference i searched only for match and missed the glob

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34731>
_______________________________________

From report at bugs.python.org  Wed Sep 19 04:15:57 2018
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 19 Sep 2018 08:15:57 +0000
Subject: [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1537344957.38.0.956365154283.issue29249@psf.upfronthosting.co.za>


Ronny Pfannschmidt <bugs.python.org at ronnypfannschmidt.de> added the comment:

issue34731 was a duplicate of this

pytest was affected, as we port more bits to pathlib we hit this as well

bruno kindly implemented a local workaround in https://github.com/pytest-dev/pytest/pull/3980/files#diff-63fc5ed688925b327a5af20405bf4b09R19

----------
nosy: +Ronny.Pfannschmidt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29249>
_______________________________________

From report at bugs.python.org  Wed Sep 19 05:01:05 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 09:01:05 +0000
Subject: [issue34731] pathlib path.match misshandles multiple `**`
In-Reply-To: <1537335286.28.0.956365154283.issue34731@psf.upfronthosting.co.za>
Message-ID: <1537347665.05.0.956365154283.issue34731@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
superseder:  -> Pathlib glob ** bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34731>
_______________________________________

From report at bugs.python.org  Wed Sep 19 05:11:37 2018
From: report at bugs.python.org (Peter Ebden)
Date: Wed, 19 Sep 2018 09:11:37 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1537348297.53.0.956365154283.issue34722@psf.upfronthosting.co.za>


Peter Ebden <peter.ebden at gmail.com> added the comment:

Thanks for the pointer, I'll have a bit more of a dig into it (although Serhiy makes a good point too...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Wed Sep 19 05:13:51 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Sep 2018 09:13:51 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537348431.91.0.956365154283.issue34732@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8833
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 05:28:10 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Wed, 19 Sep 2018 09:28:10 +0000
Subject: [issue34733] Missing search bar on docs.python.org
Message-ID: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>


New submission from Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au>:

The search bar is missing from docs.python.org, probably as a result of a minor error in the webpage. This is a quite recent change, as the search bar is still there in a web.archive.org snapshot from the 13th of September (last week). Could someone please fix this? Thanks.

----------
assignee: docs at python
components: Documentation
messages: 325737
nosy: Harrison Chudleigh, docs at python
priority: normal
severity: normal
status: open
title: Missing search bar on docs.python.org
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 05:35:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 09:35:53 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537349753.78.0.956365154283.issue17239@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Oh? I've updated it twice (4e21100fa7bf66e0b32146d3f46ae16afc73fee1 and 5033aa77aacaa5505636f150e8d54baac5bdca9c), and it didn't seem so bad. I just copied the upstream files in. Did I do it wrong?

Let me remind what I did...

bpo-30694 (expat 2.2.1):

* I wrote a script to rebuild Modules/expat/ from the upstream code
* I had to manually keep our old pyexpatns.h file since it's a downstream change
* Then you have to add againt #include "pyexpatns.h" in Modules/expat/expat_external.h
* It broke buildbots: bpo-29591
* The change introduced a compilation warning: bpo-30797

bpo-30947 (expat 2.2.3):

* "If libexpat is upgraded in Python 2.7, the new Modules/expat/loadlibrary.c should also be added to PC/VS9.0/ project files, as I did for PCbuild."
* "Expat 2.2.3 has a bug: see bpo-31170 :-("
* etc.

There are different issues:

* We have some small downstream changes
* We still support VS 2008 for Python 2.7 whereas upstream doesn't care of this old legacy compiler
* Each release introduces its own set of bugs :-D
* Each release comes with its own set of new warnings...

At least for me, each update was painful. It's also painful to have to make the same change in all supported branches (2.7, 3.4, 3.5, 3.6, 3.7, master).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Wed Sep 19 05:51:51 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 09:51:51 +0000
Subject: [issue34734] Azure linux buildbot failure
Message-ID: <1537350711.76.0.956365154283.issue34734@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

It seems there is a sporadic failure in Azure linux buildbots while installing dependencies with the following error. It also fails sporadically on separate PRs that trigger the build. I noticed it for the few days since README Azure badge had the error for a couple of days with Linux builds passing on Travis.

Error message : 

2018-09-19T09:08:43.7414966Z Hit:17 http://packages.erlang-solutions.com/debian xenial Release
2018-09-19T09:08:45.1584376Z Reading package lists...
2018-09-19T09:08:45.2045716Z E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
2018-09-19T09:08:45.2063210Z E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
2018-09-19T09:08:45.2200826Z ##[error]Bash exited with code '100'.
2018-09-19T09:08:45.2734828Z ##[section]Finishing: Install dependencies

Reference buildbot failure : https://dev.azure.com/python/cpython/_build/results?buildId=30061&view=logs

Adding Victor and Pablo for notification. I don't think this is a requirement but just something I noticed and it also blocks miss-islington from auto-merging backport PRs in some cases like https://github.com/python/cpython/pull/9401#issuecomment-422505327

Thanks

----------
components: Build
messages: 325739
nosy: pablogsal, vstinner, xtreak
priority: normal
severity: normal
status: open
title: Azure linux buildbot failure
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34734>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:06:32 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 10:06:32 +0000
Subject: [issue34125] Profiling depends on whether **kwargs is given
In-Reply-To: <1531761360.51.0.56676864532.issue34125@psf.upfronthosting.co.za>
Message-ID: <1537351592.77.0.956365154283.issue34125@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e89de7398718f6e68848b6340830aeb90b7d582c by Miss Islington (bot) (jdemeyer) in branch 'master':
bpo-34125: Enable profiling of method_descriptor in all cases (GH-8416)
https://github.com/python/cpython/commit/e89de7398718f6e68848b6340830aeb90b7d582c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34125>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:15:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 10:15:18 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537352118.35.0.956365154283.issue34732@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:27:53 2018
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 19 Sep 2018 10:27:53 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537352873.18.0.956365154283.issue34732@psf.upfronthosting.co.za>


Richard Neumann <mail at richard-neumann.de> added the comment:

I'm not sure whether the property method should be changed.
I think it'd be more appropriate to raise a value error upon __init__ in this case as it is done with other checks.

----------
nosy: +conqp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:28:31 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 10:28:31 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537352911.86.0.956365154283.issue34712@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3705b9862025705ea60041a9e310f99a164db722 by Miss Islington (bot) (Ben Hoyt) in branch 'master':
bpo-34712: Fix style in examples in "Input and Output" (GH-9361)
https://github.com/python/cpython/commit/3705b9862025705ea60041a9e310f99a164db722


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:28:55 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 10:28:55 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537352935.59.0.956365154283.issue34712@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8834

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:29:47 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Sep 2018 10:29:47 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
In-Reply-To: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>
Message-ID: <1537352987.48.0.956365154283.issue34728@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8835
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:43:03 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 19 Sep 2018 10:43:03 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537353783.72.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Note that the POSIX_SPAWN_USEVFORK may not do anything at this point (see the link in my previous message, if I read the code correctly POSIX_SPAWN_USEVFORK is no longer used in the implementation of posix_spawn(3)).

Even if it did do something the user that uses the flag needs to evaluate whether or not it is safe to do so, and this requires inspecting the os.posix_spawn implementation and not just the Python code that calls it. 

IMHO we shouldn't expose or use this flag.

If it were useful to do anything with the flag the os.posix_spawn implementation should do so automatically when it is safe to do so (which may require additional steps around calling posix_spawn(3)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:53:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 10:53:03 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537354383.63.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm discussing with Pablo to see how to use posix_spawn() in the Python subprocess module. IMHO we should consider the specific case of subprocess.

What is the expected API?

kw = {}
if hasattr(os, 'POSIX_SPAWN_USEVFORK'):
   kw['flags'] = os.POSIX_SPAWN_USEVFORK
posix_spawn(*args, **kw)

or

posix_spawn(*args, use_vfork=True)

or

kw = {}
if sys.platform == 'linux':
   kw['use_vfork'] = True
posix_spawn(*args, **kw)

?

For example, if we consider that it's safe to use POSIX_SPAWN_USEVFORK in all cases for posix_spawn(), maybe we should not add an option at the Python level, and hardcode the POSIX_SPAWN_USEVFORK flag in the C code?


--

> if I read the code correctly POSIX_SPAWN_USEVFORK is no longer used in the implementation of posix_spawn(3))

Ok, now I'm confused: what's the point of this issue if the flag became useless? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 06:56:53 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Sep 2018 10:56:53 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1537354613.26.0.956365154283.issue34690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Something else this would need is a different name that better distinguishes it from the existing frozen modules, which freeze the bytecode rather than the resulting module state. (That existing approach avoids the stat overhead, but still incurs the module level bytecode execution overhead)

My suggestion would be to use the terms "preexec builtin module" and "preexec extension module", as the concept is similar to precompiled bytecode, just taken a step further: actually executing the module in advance and caching the result, not just compiling it.

This means the preexecuted module can't have any module level conditional logic that depends on runtime state if the resulting binary is going to remain portable across different environments, but there'd be a lot of standard library modules that could satisfy that constraint.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Wed Sep 19 07:08:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 11:08:14 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537355294.9.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8836

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 07:25:12 2018
From: report at bugs.python.org (Prabhakar)
Date: Wed, 19 Sep 2018 11:25:12 +0000
Subject: [issue31652] make install fails: no module _ctypes
In-Reply-To: <1506812661.87.0.213398074469.issue31652@psf.upfronthosting.co.za>
Message-ID: <1537356312.53.0.956365154283.issue31652@psf.upfronthosting.co.za>


Prabhakar <prabs003 at gmail.com> added the comment:

Hi All,

Iam using centos 7. And as mentioned in this thread, though this error came, Iam able to go to python3.7 interpreter fine.

However, when i wanted to install pip, I get the same _ctype error as below.

So, I think, this needs to be resolved in order to use python3.7 in centos.

 File "get-pip.py", line 20651, in <module>
    main()
  File "get-pip.py", line 197, in main
    bootstrap(tmpdir=tmpdir)
  File "get-pip.py", line 82, in bootstrap
    import pip._internal
  File "/tmp/tmpu88jadkc/pip.zip/pip/_internal/__init__.py", line 42, in <module>
  File "/tmp/tmpu88jadkc/pip.zip/pip/_internal/cmdoptions.py", line 16, in <module>
  File "/tmp/tmpu88jadkc/pip.zip/pip/_internal/index.py", line 24, in <module>
  File "/tmp/tmpu88jadkc/pip.zip/pip/_internal/download.py", line 38, in <module>
  File "/tmp/tmpu88jadkc/pip.zip/pip/_internal/utils/glibc.py", line 3, in <module>
  File "/usr/local/lib/python3.7/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'


Looking for advice.

----------
nosy: +prabs003

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31652>
_______________________________________

From report at bugs.python.org  Wed Sep 19 07:26:03 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 19 Sep 2018 11:26:03 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537356363.47.0.956365154283.issue34663@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The removal of POSIX_SPAWN_USEVFORK in glibc was somewhat recent. There is also multiple implementations of posix_spawn in glibc source tree.

vfork was introduced in
commit 9ad684229e7cf2f0b3c6068b2122701d167a5794
Author: Ulrich Drepper <drepper at redhat.com>
Date:   Sun Sep 12 18:05:37 2004 +0000

The new implementation of posix_spawn for unix (/sysdeps/unix/sysv/linux/spawni.c) was introduced in
commit 9ff72da471a509a8c19791efe469f47fa6977410
Author: Adhemerval Zanella <adhemerval.zanella at linaro.org>
Date:   Tue Jan 19 17:33:32 2016 -0200

The new implementation of posix_spawn for posix (sysdeps/posix/spawni.c) was introduced in
commit ccfb2964726512f6669fea99a43afa714e2e6a80
Author: Adhemerval Zanella <adhemerval.zanella at linaro.org>
Date:   Mon Apr 24 15:50:19 2017 -0300

In these two last commits, posix_spawn removed the flag and made it a no-op. But notice that these commits are "recent" (2016 and 2017). Any older version of glibc that uses python will not benefit from these changes and if it wants to use vfork, it needs the flag.

At this point and after this interesting discussion I am not sure that we should expose the flag or not, but I still want to remark that even if glibc removed the flag for both implementations (unix and posix) we may want to expose the flag for older versions of glibc. I discover this problem when I was benchmarking posix_spawn in different platforms and systems and I notice a performance decrease in some older version of ubuntu from 2015. In that platform (older version of glibc) you need the flag to activate vfork and get the performance benefit. The glibc version for this systems is straightforward:

-  if ((flags & POSIX_SPAWN_USEVFORK) != 0
-      /* If no major work is done, allow using vfork.  Note that we
-        might perform the path searching.  But this would be done by
-        a call to execvp(), too, and such a call must be OK according
-        to POSIX.  */
-      || ((flags & (POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF
-                   | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER
-                   | POSIX_SPAWN_SETPGROUP | POSIX_SPAWN_RESETIDS
-                   | POSIX_SPAWN_SETSID)) == 0
-         && file_actions == NULL))
-    new_pid = __vfork ();
-  else
-    new_pid = __fork ();

I am happy to close the issue if everyone agrees that we should look at the future and not care about these older versions of glibc < 2017/2016 (depending on posix/unix version) or this does not worth the hassle.

I am still happy with this great and interesting discussion, so thank you everyone :)


Complete story of posix_spawn in glibc:

Whole story of posix_spawn:

commit c181840c93d3a8fcb50991b2326c40f34eb5e82b
commit c22845744cd931267e0d7cb2e2b35a0da9c9510a
commit db6b2f25220f1cf345656164211fd549c22189dd
commit ccfb2964726512f6669fea99a43afa714e2e6a80
commit daeb1fa2e1b33323e719015f5f546988bd4cc73b
commit 1a2325c06cf309d1d8b4aafcfb1a3d43905baf9b
commit ecb1482ffd85fd3279642b1dc045aa867ad4d415
commit d96de9634a334af16c0ac711074c15ac1762b23c
commit f574184a0e4b6ed69a5d9a3234543fba6d2a7367
commit cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca
commit 1b8373f475105307ee3b64d423ffec995ddd6cde
commit 7231452e5cffcd506f7e7402484708740bc07c18
commit a334319f6530564d22e775935d9c91663623a1b4
commit 0ecb606cb6cf65de1d9fc8a919bceb4be476c602
commit 9ad684229e7cf2f0b3c6068b2122701d167a5794
commit 73299943388c0eebf6a9c8d6288e9da8289f9dca
commit 284128f68f27567f9cad0078c97d7d807475e0a7
commit ba3752d5322448ab54b71c82e63a09542042a3b6
commit 2958e6cc5f39ac2487b4fcbc2db48462a34ce23d
commit 4aebaa6bd906383aca1b7a5e1251b0d1652f9f7c
commit 08c7f6b0082b1b645348518fdc42643b5580d87c
commit a5a6f9262eeffab9f78622258fae306d1bf99d04

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 07:48:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 11:48:22 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537357702.64.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The issue is now discussed on python-dev. My latest email:
https://mail.python.org/pipermail/python-dev/2018-September/155242.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:04:28 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Sep 2018 12:04:28 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537358668.39.0.956365154283.issue34732@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +8837

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:06:59 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 12:06:59 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537358819.07.0.956365154283.issue34732@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this is a valid UUID and trying this on JDK 9 also returns 15 for the version like Python. Am I missing something here?

?  ~ jshell
|  Welcome to JShell -- Version 9.0.4
|  For an introduction type: /help intro

jshell> import java.util.*

jshell> UUID.fromString("481a8de5-f0d1-f211-b425-e41f134196da").version()
$2 ==> 15

jshell> UUID.fromString("481a8de5-f0d1-f211-b425-e41f134196da").variant()
$3 ==> 2

JDK implementation : http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/UUID.java#l247


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:11:50 2018
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 19 Sep 2018 12:11:50 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537359110.48.0.956365154283.issue34732@psf.upfronthosting.co.za>


Richard Neumann <mail at richard-neumann.de> added the comment:

@xtreak RFC 4122, section 4.1.3. specifies only versions 1 to 5.
For explicitely checking the version, there is already a test in UUID.__init__, raising a ValueError on not 1<= verision 1<=5.
I moved it to the bottom of __init__, i.e. after setting the "int" property, causing the test to run on the actual instance's property value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:18:05 2018
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 19 Sep 2018 12:18:05 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537359485.4.0.956365154283.issue34732@psf.upfronthosting.co.za>


Richard Neumann <mail at richard-neumann.de> added the comment:

Typos:
"For explicitely checking the version" ? "For explicitely *setting* the version".
"on not 1<= verision 1<=5" ? "on not 1 <= version <= 5".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:35:36 2018
From: report at bugs.python.org (Felipe Rodrigues)
Date: Wed, 19 Sep 2018 12:35:36 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
In-Reply-To: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>
Message-ID: <1537360536.36.0.956365154283.issue34728@psf.upfronthosting.co.za>


Change by Felipe Rodrigues <felipe at felipevr.com>:


----------
nosy: +fbidu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:35:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 12:35:50 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537360550.2.0.956365154283.issue34732@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems there is an open issue about this : https://bugs.python.org/issue31958

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:39:35 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 12:39:35 +0000
Subject: [issue31958] UUID versions are not validated to lie in the documented
 range
In-Reply-To: <1509967887.83.0.213398074469.issue31958@psf.upfronthosting.co.za>
Message-ID: <1537360775.19.0.956365154283.issue31958@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Related issue : https://bugs.python.org/issue34732 . It has a PR to raise an exception in the constructor and it seems to cause tests to fail at https://ci.appveyor.com/project/python/cpython/build/3.8build22654

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31958>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:41:02 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 12:41:02 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
In-Reply-To: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>
Message-ID: <1537360862.2.0.956365154283.issue34728@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:55:23 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 19 Sep 2018 12:55:23 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
Message-ID: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

There is a missing PyMem_Free(format) in time_strftime(). I'll create a PR.

----------
components: Extension Modules
messages: 325754
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Modules/timemodule.c: Memory leak in time_strftime()
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:58:36 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 19 Sep 2018 12:58:36 +0000
Subject: [issue31652] make install fails: no module _ctypes
In-Reply-To: <1506812661.87.0.213398074469.issue31652@psf.upfronthosting.co.za>
Message-ID: <1537361916.93.0.956365154283.issue31652@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

As mentioned before, this is due to missing libffi-devel on a Centos 7 system. Verified it as well on one of my systems.

Could you try again, but before just do a 'yum install libffi-devel'?

Maybe a warning could be added to the install output when it can't find libffi.

----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31652>
_______________________________________

From report at bugs.python.org  Wed Sep 19 08:59:53 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 12:59:53 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537361993.89.0.956365154283.issue34733@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Strange it's present on both 3.8.a0 and for 3.6.6 but not for 3.7.0

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:00:20 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 19 Sep 2018 13:00:20 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537362020.17.0.956365154283.issue34735@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8838
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:00:53 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Sep 2018 13:00:53 +0000
Subject: [issue34736] Confusing base64.b64decode output
Message-ID: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The following error message in Python 3.7 is confusing and unhelpful:

    >>> s = "FS9qzW_oliGH_Yo="
    >>> base64.b64decode(s)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/base64.py", line 87, in b64decode
        return binascii.a2b_base64(s)
    binascii.Error: Invalid base64-encoded string: length cannot be 1 more than a multiple of 4
    >>> len(s) % 4
    0

This had me staring at the string s and scratching my head, thinking: "s doesn't have length 1 more than a multiple of 4, either with or without the "=" padding byte. What's this talking about?"

The actual user error here is a failure to use the "altchars" argument correctly:

>>> base64.b64decode(s, altchars="-_")
b'\x15/j\xcdo\xe8\x96!\x87\xfd\x8a'

The error message in versions prior to Python 3.7 is no more helpful, but it's not quite as misleading, either.

Python 3.6.6 (default, Jun 28 2018, 05:43:53) 
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> s = "FS9qzW_oliGH_Yo="
>>> base64.b64decode(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/base64.py", line 87, in b64decode
    return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

Related: #1466065, #33770

----------
messages: 325757
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Confusing base64.b64decode output
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:06:25 2018
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 19 Sep 2018 13:06:25 +0000
Subject: [issue31958] UUID versions are not validated to lie in the documented
 range
In-Reply-To: <1509967887.83.0.213398074469.issue31958@psf.upfronthosting.co.za>
Message-ID: <1537362385.63.0.956365154283.issue31958@psf.upfronthosting.co.za>


Richard Neumann <mail at richard-neumann.de> added the comment:

@xtreak Indeed. It fails on _windll_getnode().

======================================================================
ERROR: test_windll_getnode (test.test_uuid.TestInternalsWithoutExtModule)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_uuid.py", line 748, in test_windll_getnode
    node = self.uuid._windll_getnode()
  File "C:\projects\cpython\lib\uuid.py", line 659, in _windll_getnode
    return UUID(bytes=bytes_(_buffer.raw)).node
  File "C:\projects\cpython\lib\uuid.py", line 208, in __init__
    raise ValueError('illegal version number')
ValueError: illegal version number
----------------------------------------------------------------------

Apparently on Windows systems, there are UUIDs of type RFC_4122 being used which have versions not in 1..5, which actually makes them non-RFC 4122 compliant.
Unfortunately I cannot investigate this further, since I do not have a windows machine available right now.

----------
nosy: +conqp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31958>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:09:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 13:09:36 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537362576.51.0.956365154283.issue33937@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

This issue just occurred on a 3.7 PR:
https://github.com/python/cpython/pull/9416#pullrequestreview-156769445
https://travis-ci.org/python/cpython/jobs/430490176

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:42:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 13:42:54 +0000
Subject: [issue31958] UUID versions are not validated to lie in the documented
 range
In-Reply-To: <1509967887.83.0.213398074469.issue31958@psf.upfronthosting.co.za>
Message-ID: <1537364574.03.0.956365154283.issue31958@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31958>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:44:34 2018
From: report at bugs.python.org (Jatin Goel)
Date: Wed, 19 Sep 2018 13:44:34 +0000
Subject: [issue34737] Python upgrade with SYSTEM account uninstalls python
Message-ID: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>


New submission from Jatin Goel <jatingoel1037 at gmail.com>:

Team,

I have some Windows machines where Python version 3.6.2 is installed.

We are now upgrading them to 3.6.6

As part of our Install process, we launch the installation script with the SYSTEM account with the command:

python-3.6.6-amd64.exe /quiet InstallAllUsers=1 log "[logpath]\InstallPython"

This command works fine if I launch it interactively, i.e., from an Administrator account from command prompt, and version is upgraded successfully.


But when launching the same command from the SYSTEM account, it tries to install Just for Me, and not all users and some checks fails, and it removes the installed python as well.



[1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable 'InstallLauncherAllUsers' to value 1
[1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable 'Include_launcher' to value 1
[1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable 'DetectedLauncher' to value 1
[1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable 'Include_launcherState' to value 'disable'
[1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable 'InstallLauncherAllUsersState' to value 'disable'

[1C18:1F24][2018-09-19T16:25:58]w208: Plan disabled rollback for package: tcltk_JustForMe, due to incomplete cache: None, original rollback action: Install
[1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable 'WixBundleLog_tcltk_JustForMe' to value 'C:\ProgramData\Commvault Systems\Galaxy\LogFiles\Instance001\\InstallPython_007_tcltk_JustForMe.log'
[1C18:1F24][2018-09-19T16:25:58]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1C18:1F24][2018-09-19T16:25:58]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1C18:1F24][2018-09-19T16:25:58]i204: Plan 1 msi features for package: tcltk_JustForMe_pdb
[1C18:1F24][2018-09-19T16:25:58]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove

[1C18:1F24][2018-09-19T16:26:03]i319: Applied execute package: dev_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:26:03]i329: Removed package dependency provider: {5CE3EB5B-1823-4B8E-BE10-95262BDD1148}, package: exe_JustForMe
[1C18:1F24][2018-09-19T16:26:03]i301: Applying execute package: exe_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:26:04]i319: Applied execute package: exe_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:26:04]i329: Removed package dependency provider: {4D137679-6FB4-446B-9BDB-279292FA2D2C}, package: lib_JustForMe
[1C18:1F24][2018-09-19T16:26:04]i301: Applying execute package: lib_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:26:47]i319: Applied execute package: lib_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:26:47]i329: Removed package dependency provider: {C9596636-022D-4123-B369-98819F772985}, package: test_JustForMe
[1C18:1F24][2018-09-19T16:26:47]i301: Applying execute package: test_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:15]i319: Applied execute package: test_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:27:15]i329: Removed package dependency provider: {16EF5AB7-4A89-4F06-B20B-209DA4FE0533}, package: doc_JustForMe
[1C18:1F24][2018-09-19T16:27:16]i301: Applying execute package: doc_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:17]i319: Applied execute package: doc_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:27:17]i329: Removed package dependency provider: {E95CEC86-EFB3-47B8-A5F6-C8FB757AD060}, package: tools_JustForMe
[1C18:1F24][2018-09-19T16:27:17]i301: Applying execute package: tools_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:23]i319: Applied execute package: tools_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:27:23]i329: Removed package dependency provider: {44EC13CA-E201-433B-B2D3-386B9609B859}, package: tcltk_JustForMe
[1C18:1F24][2018-09-19T16:27:23]i301: Applying execute package: tcltk_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:23]e000: Error 0x80070643: Failed to uninstall MSI package.
[1C18:1F24][2018-09-19T16:27:23]e000: Error 0x80070643: Failed to configure per-user MSI package.
[1C18:1F24][2018-09-19T16:27:23]i319: Applied execute package: tcltk_JustForMe, result: 0x80070643, restart: None



Any help would be much appreciated on this.


Regards,
Jatin Goel

----------
components: Installation, Windows
messages: 325760
nosy: JatinGoel, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python upgrade with SYSTEM account uninstalls python
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34737>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:47:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 13:47:27 +0000
Subject: [issue34738] Distutils: ZIP files don't include directory entries
Message-ID: <1537364847.56.0.956365154283.issue34738@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

ZIP files created by distutils don't include entries for directories. For example, if the directory structure is

    dist/
        file1.py
        sub/
            file2.py

the ZIP file will contain entries 'dist/file1.py' and 'dist/sub/file2.py', but not 'dist/' and 'dist/sub/'.

This only when use the zipfile module. If it is not available for some reasons, the zip command is used. In that case directory entries are created. The are created also in TAR files.

All other methods of packing a tree to a ZIP in the stdlib (shutil.make_archive(), zipfile CLI, zipapp, Tools/msi/make_zip.py) create directory entries too.

zipimport doesn't support implicit namespace packages if directory entries are not added (issue14905).

The proposed PR makes distutils adding directory entries in a ZIP file.

----------
components: Distutils
messages: 325761
nosy: dstufft, eric.araujo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Distutils: ZIP files don't include directory entries
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/issue34738>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:47:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 13:47:34 +0000
Subject: [issue34734] Azure linux buildbot failure
In-Reply-To: <1537350711.76.0.956365154283.issue34734@psf.upfronthosting.co.za>
Message-ID: <1537364854.92.0.956365154283.issue34734@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Remove myself. VSTS is not my duty :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34734>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:49:13 2018
From: report at bugs.python.org (Jatin Goel)
Date: Wed, 19 Sep 2018 13:49:13 +0000
Subject: [issue34737] Python upgrade with SYSTEM account uninstalls python
In-Reply-To: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>
Message-ID: <CAMgth8S8ueEe3zPLP65zJhmawaGGDxvT+0tPMMseV7UAK1PDJA@mail.gmail.com>


Jatin Goel <jatingoel1037 at gmail.com> added the comment:

Correction to the install command:

python-3.6.6-amd64.exe /quiet InstallAllUsers=1 /log
"[logpath]\InstallPython"

On Wed, Sep 19, 2018 at 7:14 PM Jatin Goel <report at bugs.python.org> wrote:

>
> New submission from Jatin Goel <jatingoel1037 at gmail.com>:
>
> Team,
>
> I have some Windows machines where Python version 3.6.2 is installed.
>
> We are now upgrading them to 3.6.6
>
> As part of our Install process, we launch the installation script with the
> SYSTEM account with the command:
>
> python-3.6.6-amd64.exe /quiet InstallAllUsers=1 log
> "[logpath]\InstallPython"
>
> This command works fine if I launch it interactively, i.e., from an
> Administrator account from command prompt, and version is upgraded
> successfully.
>
>
> But when launching the same command from the SYSTEM account, it tries to
> install Just for Me, and not all users and some checks fails, and it
> removes the installed python as well.
>
>
>
> [1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable
> 'InstallLauncherAllUsers' to value 1
> [1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable
> 'Include_launcher' to value 1
> [1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable
> 'DetectedLauncher' to value 1
> [1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable
> 'Include_launcherState' to value 'disable'
> [1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable
> 'InstallLauncherAllUsersState' to value 'disable'
>
> [1C18:1F24][2018-09-19T16:25:58]w208: Plan disabled rollback for package:
> tcltk_JustForMe, due to incomplete cache: None, original rollback action:
> Install
> [1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable
> 'WixBundleLog_tcltk_JustForMe' to value 'C:\ProgramData\Commvault
> Systems\Galaxy\LogFiles\Instance001\\InstallPython_007_tcltk_JustForMe.log'
> [1C18:1F24][2018-09-19T16:25:58]i052: Condition 'not InstallAllUsers and
> Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
> [1C18:1F24][2018-09-19T16:25:58]i052: Condition 'not InstallAllUsers and
> Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
> [1C18:1F24][2018-09-19T16:25:58]i204: Plan 1 msi features for package:
> tcltk_JustForMe_pdb
> [1C18:1F24][2018-09-19T16:25:58]i203: Planned feature: Symbols, state:
> Absent, default requested: Unknown, ba requested: Local, execute action:
> AddLocal, rollback action: Remove
>
> [1C18:1F24][2018-09-19T16:26:03]i319: Applied execute package:
> dev_JustForMe, result: 0x0, restart: None
> [1C18:1F24][2018-09-19T16:26:03]i329: Removed package dependency provider:
> {5CE3EB5B-1823-4B8E-BE10-95262BDD1148}, package: exe_JustForMe
> [1C18:1F24][2018-09-19T16:26:03]i301: Applying execute package:
> exe_JustForMe, action: Uninstall, path: (null), arguments: '
> ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program
> Files\Python36\"
> OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
> [1C18:1F24][2018-09-19T16:26:04]i319: Applied execute package:
> exe_JustForMe, result: 0x0, restart: None
> [1C18:1F24][2018-09-19T16:26:04]i329: Removed package dependency provider:
> {4D137679-6FB4-446B-9BDB-279292FA2D2C}, package: lib_JustForMe
> [1C18:1F24][2018-09-19T16:26:04]i301: Applying execute package:
> lib_JustForMe, action: Uninstall, path: (null), arguments: '
> ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program
> Files\Python36\"
> OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
> [1C18:1F24][2018-09-19T16:26:47]i319: Applied execute package:
> lib_JustForMe, result: 0x0, restart: None
> [1C18:1F24][2018-09-19T16:26:47]i329: Removed package dependency provider:
> {C9596636-022D-4123-B369-98819F772985}, package: test_JustForMe
> [1C18:1F24][2018-09-19T16:26:47]i301: Applying execute package:
> test_JustForMe, action: Uninstall, path: (null), arguments: '
> ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program
> Files\Python36\"
> OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
> [1C18:1F24][2018-09-19T16:27:15]i319: Applied execute package:
> test_JustForMe, result: 0x0, restart: None
> [1C18:1F24][2018-09-19T16:27:15]i329: Removed package dependency provider:
> {16EF5AB7-4A89-4F06-B20B-209DA4FE0533}, package: doc_JustForMe
> [1C18:1F24][2018-09-19T16:27:16]i301: Applying execute package:
> doc_JustForMe, action: Uninstall, path: (null), arguments: '
> ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program
> Files\Python36\"
> OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
> [1C18:1F24][2018-09-19T16:27:17]i319: Applied execute package:
> doc_JustForMe, result: 0x0, restart: None
> [1C18:1F24][2018-09-19T16:27:17]i329: Removed package dependency provider:
> {E95CEC86-EFB3-47B8-A5F6-C8FB757AD060}, package: tools_JustForMe
> [1C18:1F24][2018-09-19T16:27:17]i301: Applying execute package:
> tools_JustForMe, action: Uninstall, path: (null), arguments: '
> ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program
> Files\Python36\"
> OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
> [1C18:1F24][2018-09-19T16:27:23]i319: Applied execute package:
> tools_JustForMe, result: 0x0, restart: None
> [1C18:1F24][2018-09-19T16:27:23]i329: Removed package dependency provider:
> {44EC13CA-E201-433B-B2D3-386B9609B859}, package: tcltk_JustForMe
> [1C18:1F24][2018-09-19T16:27:23]i301: Applying execute package:
> tcltk_JustForMe, action: Uninstall, path: (null), arguments: '
> ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program
> Files\Python36\"
> OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
> [1C18:1F24][2018-09-19T16:27:23]e000: Error 0x80070643: Failed to
> uninstall MSI package.
> [1C18:1F24][2018-09-19T16:27:23]e000: Error 0x80070643: Failed to
> configure per-user MSI package.
> [1C18:1F24][2018-09-19T16:27:23]i319: Applied execute package:
> tcltk_JustForMe, result: 0x80070643, restart: None
>
>
>
> Any help would be much appreciated on this.
>
>
> Regards,
> Jatin Goel
>
> ----------
> components: Installation, Windows
> messages: 325760
> nosy: JatinGoel, paul.moore, steve.dower, tim.golden, zach.ware
> priority: normal
> severity: normal
> status: open
> title: Python upgrade with SYSTEM account uninstalls python
> versions: Python 3.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34737>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34737>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:53:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 13:53:23 +0000
Subject: [issue34738] Distutils: ZIP files don't include directory entries
In-Reply-To: <1537364847.56.0.956365154283.issue34738@psf.upfronthosting.co.za>
Message-ID: <1537365203.97.0.956365154283.issue34738@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8839
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34738>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:54:17 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 13:54:17 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
 'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1537365257.22.0.956365154283.issue14905@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue34738 fixes distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Wed Sep 19 09:58:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 13:58:18 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537365498.78.0.956365154283.issue34736@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:06:36 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 19 Sep 2018 14:06:36 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537365996.0.0.956365154283.issue34735@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:15:37 2018
From: report at bugs.python.org (Florian Weimer)
Date: Wed, 19 Sep 2018 14:15:37 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537366537.93.0.956365154283.issue34663@psf.upfronthosting.co.za>


Florian Weimer <fweimer at redhat.com> added the comment:

I wouldn't bother with POSIX_SPAWN_USEVFORK on GNU/Linux.  Current versions of glibc always use a vfork-style clone call, so there would be a difference on older versions only.  But there, the vfork code has subtle bugs, so using POSIX_SPAWN_USEVFORK there is not a good idea, either.

----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:25:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:25:12 +0000
Subject: [issue34739] Get rid of tp_getattro in xml.etree.ElementTree.XMLParser
Message-ID: <1537367112.3.0.956365154283.issue34739@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently xml.etree.ElementTree.XMLParser has the tp_getattro slot for handling some attributes. The proposed PR replaces it with tp_members and tp_getset.

Benefits: constant time access, names of these attributes are added to the result of dir() and help(), better structured code.

----------
components: Extension Modules
messages: 325766
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of tp_getattro in xml.etree.ElementTree.XMLParser
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34739>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:25:20 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 19 Sep 2018 14:25:20 +0000
Subject: [issue34726] Add support of checked hash-based pycs in zipimport
In-Reply-To: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>
Message-ID: <1537367120.57.0.956365154283.issue34726@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/issue34726>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:27:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:27:08 +0000
Subject: [issue34739] Get rid of tp_getattro in xml.etree.ElementTree.XMLParser
In-Reply-To: <1537367112.3.0.956365154283.issue34739@psf.upfronthosting.co.za>
Message-ID: <1537367228.76.0.956365154283.issue34739@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8840
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34739>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:28:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:28:21 +0000
Subject: [issue34726] Add support of checked hash-based pycs in zipimport
In-Reply-To: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>
Message-ID: <1537367301.54.0.956365154283.issue34726@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue23734 may be related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34726>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:31:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:31:29 +0000
Subject: [issue34740] Get rid of tp_getattro in ossaudiodev.oss_audio_device
Message-ID: <1537367489.08.0.956365154283.issue34740@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently ossaudiodev.oss_audio_device has the tp_getattro slot for handling some attributes. The proposed PR replaces it with tp_members and tp_getset.

Benefits: constant time access, names of these attributes are added to the result of dir() and help(), better structured code.

----------
components: Extension Modules
messages: 325768
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of tp_getattro in ossaudiodev.oss_audio_device
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34740>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:33:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:33:56 +0000
Subject: [issue34740] Get rid of tp_getattro in ossaudiodev.oss_audio_device
In-Reply-To: <1537367489.08.0.956365154283.issue34740@psf.upfronthosting.co.za>
Message-ID: <1537367636.05.0.956365154283.issue34740@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8841
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34740>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:38:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:38:57 +0000
Subject: [issue34741] Get rid of tp_getattro and tp_setattro in
 pyexpat.xmlparser
Message-ID: <1537367937.72.0.956365154283.issue34741@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently pyexpat.xmlparser has the tp_getattro and tp_setattro slot for handling some attributes. The proposed PR replaces it with tp_members and tp_getset.

Benefits: constant time access, names of these attributes are added to the result of help(), no need of the __dir__() method, better structured code.

----------
components: Extension Modules
messages: 325769
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of tp_getattro and tp_setattro in pyexpat.xmlparser
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34741>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:41:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:41:08 +0000
Subject: [issue34741] Get rid of tp_getattro and tp_setattro in
 pyexpat.xmlparser
In-Reply-To: <1537367937.72.0.956365154283.issue34741@psf.upfronthosting.co.za>
Message-ID: <1537368068.57.0.956365154283.issue34741@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8842
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34741>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:41:35 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 19 Sep 2018 14:41:35 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537368095.97.0.956365154283.issue34663@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, I am going to close the issue and the PR unless someone comments on this issue in 24h saying that we still need to expose the flag and providing an explanation.

Thank you everyone for this interesting discussion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:43:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:43:39 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1537368219.58.0.956365154283.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b2984ab9a7c458f8b7ed8978c0c95b109116895d by Serhiy Storchaka in branch 'master':
bpo-25711: Remove outdated zipimport tests. (GH-9404)
https://github.com/python/cpython/commit/b2984ab9a7c458f8b7ed8978c0c95b109116895d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Wed Sep 19 11:02:37 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 19 Sep 2018 15:02:37 +0000
Subject: [issue34737] Python upgrade with SYSTEM account uninstalls python
In-Reply-To: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>
Message-ID: <1537369357.03.0.956365154283.issue34737@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

This looks like something particular to Tcl/Tk, and my best guess from a very quick look at your logs is that there's a malware scanner preventing the files from being deleted for some reason (perhaps it's triggering an extended scan of one of the files?). Or perhaps there's an app running that is using those file (though that's unlikely given the rest of Python uninstalled)?

Nothing is particularly special about the installer for this component, so my guess is it's something about your configuration. If you can find the tcltk uninstall log file (in your %TEMP% directory, near the one you quoted from) that may provide some more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34737>
_______________________________________

From report at bugs.python.org  Wed Sep 19 11:12:18 2018
From: report at bugs.python.org (ppperry)
Date: Wed, 19 Sep 2018 15:12:18 +0000
Subject: [issue14905] zipimport needs to support namespace packages when no
 'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1537369938.34.0.956365154283.issue14905@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: zipimport.c needs to support namespace packages when no 'directory' entry exists -> zipimport needs to support namespace packages when no 'directory' entry exists

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Wed Sep 19 11:14:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 15:14:55 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537370095.64.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I rely on Florian Weimer who maintains the glibc for Red Hat, and so I agree to close the issue. It seems like Pablo wants to keep the issue open 24h, so I let him close it later ;-)

The good news is that calling posix_spawn() with no flag is safe in all glibc versions and it's fast by default on recent glibc versions ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 12:23:18 2018
From: report at bugs.python.org (Devin Fee)
Date: Wed, 19 Sep 2018 16:23:18 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
In-Reply-To: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>
Message-ID: <1537374198.78.0.956365154283.issue34730@psf.upfronthosting.co.za>


Change by Devin Fee <devin at devinfee.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Wed Sep 19 12:27:23 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 19 Sep 2018 16:27:23 +0000
Subject: [issue34739] Get rid of tp_getattro in xml.etree.ElementTree.XMLParser
In-Reply-To: <1537367112.3.0.956365154283.issue34739@psf.upfronthosting.co.za>
Message-ID: <1537374443.65.0.956365154283.issue34739@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Nice. Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34739>
_______________________________________

From report at bugs.python.org  Wed Sep 19 13:02:14 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Sep 2018 17:02:14 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537376534.89.0.956365154283.issue34733@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 13:23:57 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Sep 2018 17:23:57 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537377837.81.0.956365154283.issue34694@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/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 13:38:08 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Sep 2018 17:38:08 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537378688.02.0.956365154283.issue34660@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

> David and Brett: I consider part of the actions of the anonymous person using the temporary aliases 25.45 and jonsees to be violations of our Code of Conduct.  I would therefore like you two to issue a warning, if not a ban.

I am not interested in being a community policeman, nor do I have time to do it.  I will no longer be making any non-technical contributions to Python.  I will no longer hand out tracker permissions or revoke them, and I will not participate in any of these non-technical discussions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Wed Sep 19 13:38:19 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Sep 2018 17:38:19 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537378699.54.0.956365154283.issue34660@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/issue34660>
_______________________________________

From report at bugs.python.org  Wed Sep 19 13:39:05 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 19 Sep 2018 17:39:05 +0000
Subject: [issue34738] Distutils: ZIP files don't include directory entries
In-Reply-To: <1537364847.56.0.956365154283.issue34738@psf.upfronthosting.co.za>
Message-ID: <1537378745.21.0.956365154283.issue34738@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I don't see a problem with this. If the zip file has 'dist/file1.py' then you know to create a directory when unzipping. If you want to indicate that there's an empty directory 'foo', then put 'foo/' in the zip file.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34738>
_______________________________________

From report at bugs.python.org  Wed Sep 19 13:57:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 17:57:24 +0000
Subject: [issue34738] Distutils: ZIP files don't include directory entries
In-Reply-To: <1537364847.56.0.956365154283.issue34738@psf.upfronthosting.co.za>
Message-ID: <1537379844.9.0.956365154283.issue34738@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There are two problems:

1. This is inconsistent with TAR files and the zip utility.

2. This is not compatible with zipimport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34738>
_______________________________________

From report at bugs.python.org  Wed Sep 19 14:19:43 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Sep 2018 18:19:43 +0000
Subject: [issue34738] Distutils: ZIP files don't include directory entries
In-Reply-To: <1537364847.56.0.956365154283.issue34738@psf.upfronthosting.co.za>
Message-ID: <1537381183.34.0.956365154283.issue34738@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IMO inconsistency with tarfile is not very relevant.

About the zip utility: are you saying that the unix unzip command is not able to inspect or extract distutils sdists?

About zipimport, the question is: are sdists meant to be directly importable (IMO no).

That said, if it is a minor change with no downsides, I wouldn?t oppose it.  I just wanted to be clear on the reasons / benefits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34738>
_______________________________________

From report at bugs.python.org  Wed Sep 19 14:27:14 2018
From: report at bugs.python.org (Ankit Goel)
Date: Wed, 19 Sep 2018 18:27:14 +0000
Subject: [issue34742] Add optional argument for exit status in
 argparse.ArgumentParser.error
Message-ID: <1537381633.99.0.956365154283.issue34742@psf.upfronthosting.co.za>


New submission from Ankit Goel <ankitgoel616 at gmail.com>:

argparse.ArgumentParser.error currently uses a hard coded exit status (2).
An optional argument (with default value 2) would be useful to change the status without needing to overwrite the method in a subclass like here: 
https://github.com/pytest-dev/pytest/pull/3925

----------
components: Library (Lib)
messages: 325779
nosy: Ankit Goel
priority: normal
severity: normal
status: open
title: Add optional argument for exit status in argparse.ArgumentParser.error
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/issue34742>
_______________________________________

From report at bugs.python.org  Wed Sep 19 14:45:24 2018
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 19 Sep 2018 18:45:24 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537382724.09.0.956365154283.issue34694@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

@Mariatta:
> There will be no further discussion about this.

Mariatta, why do you say that?  As long as the participants in the discussion are respectful I'm not aware of any mechanism in the CPython developer guidelines that would require shutting down the discussion.


@terry.reedy:
> The purpose of the tracker is to facilitate patches to the CPython code and docs.

I'm pretty sure the issue tracker gets used for more than strictly facilitating patches.  And TBH this conversation got a little toxic in other areas online.  I don't think it's hurting anything to have a quiet discussion about it here on the issue tracker.


>  Insults so not solve issues.  [...]  Please consider this a warning and don't repeat.

I agree that insults are bad, and I too hope that nobody engages in being insulting.  But I read Gabriel's post twice and I don't see where he insulted anybody.  I found his remarks aggressive and a bit sarcastic, sure.  But not "insulting".  Can you be specific--what was the remark where he insulted somebody?

Gabriel, I agree that you should try to curb your more inflammatory tendencies in your correspondence.  But that's as much a tactical suggestion as it is a CoC reminder.  I assume that your point in writing is to win people over to your point of view--and that's best achieved by being reasonable and making good points.  As the old saying goes, "you'll attract more flies with honey than with vinegar".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 14:48:45 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Wed, 19 Sep 2018 18:48:45 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537382925.05.0.956365154283.issue34603@psf.upfronthosting.co.za>


Change by Vladimir Matveev <desco.by at gmail.com>:


----------
pull_requests: +8843

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Wed Sep 19 14:49:23 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Sep 2018 18:49:23 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537382963.29.0.956365154283.issue34694@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the idea here is: don?t feed the trolls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 14:54:44 2018
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 19 Sep 2018 18:54:44 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383284.41.0.956365154283.issue34694@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

@eric.araujo:
> I think the idea here is: don?t feed the trolls.

I understand this as a general-purpose metaphor.  But I don't understand how that translates into CPython issue tracker policy.  And so far I wouldn't describe anybody corresponding on this issue as "trolling".  Did I miss something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:01:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 19:01:56 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537383716.61.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 95cc3ee00cfa079751ae2bb9a8d3387053b50489 by Victor Stinner in branch '3.7':
Revert "[3.7] bpo-34589: Add -X coerce_c_locale option; C locale coercion off by default (GH-9379)" (GH-9416)
https://github.com/python/cpython/commit/95cc3ee00cfa079751ae2bb9a8d3387053b50489


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:02:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 19:02:02 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383722.34.0.956365154283.issue34694@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I think the idea here is: don?t feed the trolls.

+1.  Please stop this.

Larry, IMHO, if you seriously want to discuss this issue (and bring more attention to it) I think you should email to python-commiters.  Otherwise this is just a pointless distraction to those of us who ended up randomly added to the nosy list and have no interest in this topic.

A restricted (but open) mailing list to discuss controversial topics like this is a common practice.

> But I don't understand how that translates into CPython issue tracker policy.

Selecting all "components" and adding random people to the nosy list goes pretty much against the issue tracker policy.  It should have been closed right from the beginning, because the person who opened it used the wrong medium to convey their message to begin with.

P.S. Please don't add me to the nosy list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:02:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 19:02:25 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383745.75.0.956365154283.issue34694@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/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:04:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 19:04:17 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383857.48.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:05:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 19:05:03 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383903.44.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:11:11 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 19 Sep 2018 19:11:11 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537384271.31.0.956365154283.issue34694@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/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:21:13 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 19 Sep 2018 19:21:13 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537384873.75.0.956365154283.issue34733@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Confirming that I see the same behavior as reported by @xtreak.

----------
nosy: +willingc
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:36:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 19:36:44 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
Message-ID: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>


New submission from Berker Peksag <berker.peksag at gmail.com>:

======================================================================
FAIL: test_database_source_name (sqlite3.test.backup.BackupTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython/master/Lib/sqlite3/test/backup.py", line 144, in test_database_source_name
    self.assertIn(
AssertionError: 'unrecognized error code: 1' not found in ['SQL logic error', 'SQL logic error or missing database']

A PR is on the way.

----------
assignee: berker.peksag
components: Extension Modules
messages: 325786
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: test_database_source_name fails with SQLite 3.7.9
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:40:21 2018
From: report at bugs.python.org (Joe Pamer)
Date: Wed, 19 Sep 2018 19:40:21 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537386021.21.0.956365154283.issue32557@psf.upfronthosting.co.za>


Joe Pamer <joe at noteven.org> added the comment:

Just to loop back, I updated the PR to avoid MAX_PATH and only allocate  in the "not a directory" case. Thanks for getting back to me so quickly!

One question, though, is that it *does* seem like MAX_PATH is still referenced in several places in posixmodule.c. Is the ultimate goal to remove those references as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:42:18 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 19:42:18 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
In-Reply-To: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>
Message-ID: <1537386138.63.0.956365154283.issue34743@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8844
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:44:40 2018
From: report at bugs.python.org (helmsman helmsman)
Date: Wed, 19 Sep 2018 19:44:40 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
Message-ID: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>


New submission from helmsman helmsman <whalebot.helmsman at gmail.com>:

Sometimes you want to provide format description in help message for argparse.add_argument, e.g. for comma-separated key/value set "--flag key1=value1,key2=value2". At this moment there is no format specifier for flag or name of arguments.
I propose add new %(flag)s specifier for help strings, see example.py

----------
components: Library (Lib)
files: example.py
messages: 325788
nosy: helmsman helmsman
priority: normal
severity: normal
status: open
title: New %(flag)s format specifier for argparse.add_argument help string
type: enhancement
Added file: https://bugs.python.org/file47815/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:54:23 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 19:54:23 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537386863.07.0.956365154283.issue34733@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

I can reproduce it locally [1]. The Python logo at the left dissapear to, it goes from "[LOGO] Python ?" to "3.7.0 Documentation ?".

Did not spotted recent changes in the theme / docsbuild-scripts / cpython/Doc for the moment, but now I can inspect locally.

Local reproduction with a fresh clone of docsbuild-scripts:

    $ mkdir -p www logs build_root
    $ python3 -m venv build_root/venv/
    $ build_root/venv/bin/python -m pip install -r requirements.txt
    $ python3 ./build_docs.py --quick --build-root build_root --www-root www --log-directory logs --group $(id -g) --branch 3.7
    $ (cd www/3.7/; python3 -m http.server)

----------
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:57:48 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Sep 2018 19:57:48 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1537387068.84.0.956365154283.issue34744@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8845
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:05:11 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:05:11 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537387511.05.0.956365154283.issue34733@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

I got it back by building with 90f7d455b (7 days ago), so I'm git bisecting...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:11:59 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 19 Sep 2018 20:11:59 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537387919.77.0.956365154283.issue34733@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

@mdk The asyncio folks did make a change to the layout in https://github.com/python/cpython/pull/9364 . It's a bit weird that 3.7 is the release that is missing the search bar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:13:44 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:13:44 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388024.28.0.956365154283.issue34733@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Yes, got it too : 512d7101098b971837cbb406942215244f636547, they literally removed the searchbox:

$ git show 512d7101098b971837cbb406942215244f636547 | grep searchbox
-{%- macro searchbox() %}
-{# modified from sphinx/themes/basic/searchbox.html #}
-        {{ searchbox() }}
-            '<input type="text" value="" id="searchbox" style="width: 50%">',
-            '<input type="submit" id="searchbox-submit" value="Filter"></p>'
-                  var query = new RegExp($('#searchbox').val(), 'i');
-          $('#searchbox').keyup(dofilter);
-          $('#searchbox-submit').click(dofilter);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:13:55 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:13:55 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388035.82.0.956365154283.issue34733@psf.upfronthosting.co.za>


Change by Julien Palard <julien+python at palard.fr>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:16:44 2018
From: report at bugs.python.org (Kurt Roeckx)
Date: Wed, 19 Sep 2018 20:16:44 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1537388204.73.0.956365154283.issue32947@psf.upfronthosting.co.za>


Kurt Roeckx <kurt at roeckx.be> added the comment:

Christian,

Do you have any update on this? Any idea when we can expect relased python versions that work with OpenSSL 1.1.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:16:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Sep 2018 20:16:57 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537388217.7.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:18:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 20:18:25 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537388035.84.0.249678724859.issue34733@psf.upfronthosting.co.za>
Message-ID: <E5BE206C-4B76-47E3-A621-78063B419F4A@gmail.com>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Oh, this is a result of asyncio docs 3.8 -> 3.7 backport. I'll fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:18:37 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 19 Sep 2018 20:18:37 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1537388317.16.0.956365154283.issue32947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Soonish, I'm still working on post handshake auth.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:19:46 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 19 Sep 2018 20:19:46 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388386.07.0.956365154283.issue34733@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:

Does master and 3.7 branch build the docs at different times? It's odd to me that master still shows the search box and 3.7 does not.

I'm getting on a flight soon. Yury would be a good person to ping re: changing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:20:24 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:20:24 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388424.37.0.956365154283.issue34733@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Thanks Yuri (and thanks for the rewrite!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:30:47 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 20:30:47 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537389047.55.0.956365154283.issue34712@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d9c89111bd82979ce8716f7ca68c69cf0f46e679 by Miss Islington (bot) in branch '3.7':
bpo-34712: Fix style in examples in "Input and Output" (GH-9361)
https://github.com/python/cpython/commit/d9c89111bd82979ce8716f7ca68c69cf0f46e679


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:32:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Sep 2018 20:32:40 +0000
Subject: [issue34712] Style fixes in examples of "Input and Output" tutorial
 section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537389160.23.0.956365154283.issue34712@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the improvement!

----------
nosy: +ned.deily
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34712>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:48:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 20:48:26 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537390106.45.0.956365154283.issue34603@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b63a16febbd1c943c9dbc5c651326b410aa50698 by Victor Stinner (Vladimir Matveev) in branch '2.7':
[2.7] bpo-34603, ctypes/libffi_msvc: Fix returning structs from functions (GH-9258) (GH-9425)
https://github.com/python/cpython/commit/b63a16febbd1c943c9dbc5c651326b410aa50698


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Wed Sep 19 16:49:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 20:49:26 +0000
Subject: [issue34603] ctypes on Windows: error calling C function that returns
 a struct containing 3 bools
In-Reply-To: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>
Message-ID: <1537390166.51.0.956365154283.issue34603@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks MatteoL for the bug report, it has been fixed in 2.7, 3.6, 3.7 and master. Thanks Vladimir Matveev for the fix!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34603>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:20:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Sep 2018 21:20:42 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537392042.42.0.956365154283.issue34694@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If this issue were not to be immediately closed, then cleaning the components and nosy lists should have been the first response.

I was tempted to do the latter now, to cut short the cavalcade of un-nosy emails, but anticipated that someone would object.  But I will remove myself again after this post.

Larry: Victor's recent issue and action pulled us further into a verbally violent and occasionally physically violent American Cultural war.  The result has already been pretty ugly.  We have been and will be attacked from extremists on both sides if consider changes on a case-by-case basis, accepting some and rejecting others.  I don't want the tracker ruined as a usable workspace.

We have been and will be attacked from extremists on both sides for considering changes on a case-by-case basis, accepting some and rejecting others.  On #34660, Raymond Hettinger merged one PR and I reviewed the other.  Marko called our actions 'madness' and here called us 'irresponsible'.  On the other hand, the OP criticized me for wanting change and huffed away with the claim that like it or not, we will somehow eventually be *forced* to change (as he wishes).  I do not volunteer for this sort of treatment.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:21:04 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Sep 2018 21:21:04 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537392064.49.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:23:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 21:23:45 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537392225.1.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8847

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:24:30 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 19 Sep 2018 21:24:30 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537392270.79.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee: docs at python -> 
nosy:  -docs at python, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:45:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:45:38 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393538.32.0.956365154283.issue34733@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8848
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:47:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:47:28 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393648.86.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Does master and 3.7 branch build the docs at different times? It's odd to me that master still shows the search box and 3.7 does not.

layout.html was refactored in 3.8: scripts were moved into separate files.  I accidentally copied it from 3.8 to 3.7, where those new scripts are not available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:51:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:51:20 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393880.67.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 581890cda36f60cd46185c6e184abe35a95813a2 by Yury Selivanov in branch '3.7':
bpo-34733: Return of the docs search bar (GH-9431)
https://github.com/python/cpython/commit/581890cda36f60cd46185c6e184abe35a95813a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:52:50 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:52:50 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393970.96.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Closing this now, please reopen if there's still no search bar in a few hours.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 17:56:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 21:56:40 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537394200.15.0.956365154283.issue34589@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 06e7608207daab9fb82d13ccf2d3664535442f11 by Victor Stinner in branch 'master':
Revert "bpo-34589: Add -X coerce_c_locale command line option (GH-9378)" (GH-9430)
https://github.com/python/cpython/commit/06e7608207daab9fb82d13ccf2d3664535442f11


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:20:19 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Sep 2018 22:20:19 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537395619.68.0.956365154283.issue34663@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Agreed on not exposing it.

It seems obsolete in recent glibc and the older glibc implementations that had it may have made questionable decisions. :)

Thanks for chiming in Florian, and thanks Pablo for your detailed investigation. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:20:26 2018
From: report at bugs.python.org (paul j3)
Date: Wed, 19 Sep 2018 22:20:26 +0000
Subject: [issue34724] argparse subparser help indent too short
In-Reply-To: <1537289367.73.0.956365154283.issue34724@psf.upfronthosting.co.za>
Message-ID: <1537395626.89.0.956365154283.issue34724@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

Looks like I had my say on this in the Stackoverflow link (3 yrs ago).

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34724>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:25:53 2018
From: report at bugs.python.org (paul j3)
Date: Wed, 19 Sep 2018 22:25:53 +0000
Subject: [issue34742] Add optional argument for exit status in
 argparse.ArgumentParser.error
In-Reply-To: <1537381633.99.0.956365154283.issue34742@psf.upfronthosting.co.za>
Message-ID: <1537395953.7.0.956365154283.issue34742@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34742>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:33:43 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 22:33:43 +0000
Subject: [issue31958] UUID versions are not validated to lie in the documented
 range
In-Reply-To: <1509967887.83.0.213398074469.issue31958@psf.upfronthosting.co.za>
Message-ID: <1537396423.46.0.956365154283.issue31958@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Issue 34732 is actually a duplicate of this issue, but I'm going to close this one instead since the former has already two open pull requests. Thanks for the report!

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> uuid returns version more than 5
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31958>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:39:22 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 22:39:22 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537396762.53.0.956365154283.issue34732@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report and for the PRs. The approach in PR 9417 seems reasonable to me, but we need to add some tests for all supported platforms and fix the test_windll_getnode test.

I'm removing Python 3.6 from the versions list since it's nearly end of its bugfix maintenance period and fixing this relatively harmless bug may break people's code in the wild.

----------
components: +Library (Lib)
nosy: +berker.peksag
type:  -> behavior
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:41:00 2018
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 19 Sep 2018 22:41:00 +0000
Subject: [issue34745] asyncio ssl memory leak
Message-ID: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>


New submission from Alexander Mohr <thehesiod at gmail.com>:

I've been trying to track down a leak in aiohttp: https://github.com/aio-libs/aiohttp/issues/3010

it seems like this leak now occurs with raw asyncio SSL sockets.

when the gist script is run like so: python3.7 `which mprof` run --interval=1 ~/dev/test_leak.py -test asyncio_test

it slowly leaks memory.  This is effectively doing the following:

URLS = {
    'https://s3.us-west-2.amazonaws.com/archpi.dabase.com/style.css': {
        'method': 'get',
        'headers': {'User-Agent': 'Botocore/1.8.21 Python/3.6.4 Darwin/17.5.0', 'X-Amz-Date': '20180518T025044Z', 'X-Amz-Content-SHA256': 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855', 'Authorization': f'AWS4-HMAC-SHA256 Credential={CREDENTIAL}/20180518/us-west-2/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=ae552641b9aa9a7a267fcb4e36960cd5863e55d91c9b45fd39b30fdcd2e81489', 'Accept-Encoding': 'identity'}
    },

    'https://s3.ap-southeast-1.amazonaws.com/archpi.dabase.com/doesnotexist': {
        'method': 'GET' if sys.argv[1] == 'get_object' else 'HEAD',
        'headers': {'User-Agent': 'Botocore/1.8.21 Python/3.6.4 Darwin/17.5.0', 'X-Amz-Date': '20180518T025221Z', 'X-Amz-Content-SHA256': 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855', 'Authorization': f'AWS4-HMAC-SHA256 Credential={CREDENTIAL}/20180518/ap-southeast-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=7a7675ef6d70cb647ed59e02d532ffa80d437fb03976d8246ea9ef102d118794', 'Accept-Encoding': 'identity'}
    }
}


class HttpClient(asyncio.streams.FlowControlMixin):
    transport = None

    def __init__(self, *args, **kwargs):
        self.__url = kwargs.pop('url')
        self.__logger = logging.getLogger()
        super().__init__()

    def connection_made(self, transport):
        self.transport = transport

        url_parts = urlparse(self.__url)
        entry = URLS[self.__url]

        body = f'{entry["method"]} {url_parts.path} HTTP/1.1\r\nAccept: */*\r\nHost: {url_parts.hostname}\r\n'
        for name, value in entry['headers'].items():
            body += f'{name}: {value}\r\n'

        body += '\r\n'
        self.transport.write(body.encode('ascii'))
        self.__logger.info(f'data sent: {body}')

    def data_received(self, data):
        self.__logger.info(f'data received: {data}')

        self.transport.close()
        # asyncio.get_event_loop().call_later(1.0, )

    def eof_received(self):
        self.__logger.info('eof_received')

    def connection_lost(self, exc):
        self.__logger.info(f'connection lost: {exc}')
        super().connection_lost(exc)

    @classmethod
    def create_factory(cls, url: str):
        def factory(*args, **kwargs):
            return cls(*args, url=url, **kwargs)

        return factory


async def test_asyncio(ssl_context):
    loop = asyncio.get_event_loop()

    url = 'https://s3.ap-southeast-1.amazonaws.com/archpi.dabase.com/doesnotexist'
    url_parts = urlparse(url)
    port = url_parts.port or (80 if url_parts.scheme == 'http' else 443)
    infos = await loop.getaddrinfo(url_parts.hostname, port, family=socket.AF_INET)
    family, type, proto, canonname, sockaddr = infos[0]
    await loop.create_connection(HttpClient.create_factory(url), sockaddr[0], port, ssl=ssl_context, family=family, proto=proto, flags=socket.AI_NUMERICHOST, server_hostname=url_parts.hostname, local_addr=None)


async def asyncio_test():
    ssl_context = ssl.create_default_context()

    while True:
        await test_asyncio(ssl_context)


await asyncio_test()

----------
components: asyncio
messages: 325811
nosy: asvetlov, thehesiod, yselivanov
priority: normal
severity: normal
status: open
title: asyncio ssl memory leak
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:41:43 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Wed, 19 Sep 2018 22:41:43 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537396903.74.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Gabriel Marko <marko.gabriel.cz at gmail.com>:


----------
nosy:  -suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:42:44 2018
From: report at bugs.python.org (paul j3)
Date: Wed, 19 Sep 2018 22:42:44 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1537396964.17.0.956365154283.issue34744@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

In your example, what is 'flag'?  There's no Action attribute of that name.  There is a 'dest' and a 'option_strings' list.

All the 'help' '%(...)s' does is display one of the Action object attributes, the most common one is 'default'.

Try this:

    a = parser.add_argument(...)
    print(vars(a))

to see all the attributes of such an object.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:43:09 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Wed, 19 Sep 2018 22:43:09 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537396989.85.0.956365154283.issue34660@psf.upfronthosting.co.za>


Change by Gabriel Marko <marko.gabriel.cz at gmail.com>:


----------
nosy:  -suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:44:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 22:44:28 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1537397068.58.0.956365154283.issue34745@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

What is "raw asyncio SSL sockets"? We don't use SSL sockets in asyncio, we use SSL Memory BIO.  Do you think that some SSL context objects aren't being properly released?

BTW, can you see the leak when run under uvloop?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:45:58 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Wed, 19 Sep 2018 22:45:58 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1537397158.24.0.956365154283.issue34605@psf.upfronthosting.co.za>


Change by Gabriel Marko <marko.gabriel.cz at gmail.com>:


----------
nosy:  -suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:48:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 22:48:11 +0000
Subject: [issue34595] PyUnicode_FromFormat(): add %T format for an object type
 name
In-Reply-To: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>
Message-ID: <1537397291.53.0.956365154283.issue34595@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I close this issue until we can agree on an API.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34595>
_______________________________________

From report at bugs.python.org  Wed Sep 19 18:48:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 22:48:53 +0000
Subject: [issue18174] Make regrtest with --huntrleaks check for fd leaks
In-Reply-To: <1370807273.91.0.83033499223.issue18174@psf.upfronthosting.co.za>
Message-ID: <1537397333.75.0.956365154283.issue18174@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I give up on that close. I closed my PR 7827 and PR 7966.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18174>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:05:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:05:10 +0000
Subject: [issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option
In-Reply-To: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>
Message-ID: <1537398310.76.0.956365154283.issue34639@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The discussion moved back to bpo-34589.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Initialize() and Py_Main() should not enable C locale coercion

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34639>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:06:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:06:08 +0000
Subject: [issue34285] regrtest: in case of test failure,
 add "always look on the bright side of life"
In-Reply-To: <1532995063.27.0.56676864532.issue34285@psf.upfronthosting.co.za>
Message-ID: <1537398368.22.0.956365154283.issue34285@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34285>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:06:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:06:44 +0000
Subject: [issue33718] Enhance regrtest: meta-ticket for multiple changes
In-Reply-To: <1527775539.21.0.682650639539.issue33718@psf.upfronthosting.co.za>
Message-ID: <1537398404.73.0.956365154283.issue33718@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33718>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:06:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:06:51 +0000
Subject: [issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes
In-Reply-To: <1527774159.9.0.682650639539.issue33717@psf.upfronthosting.co.za>
Message-ID: <1537398411.86.0.956365154283.issue33717@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33717>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:07:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:07:18 +0000
Subject: [issue32183] Coverity: CID 1423264: Insecure data handling
 (TAINTED_SCALAR)
In-Reply-To: <1512056012.34.0.213398074469.issue32183@psf.upfronthosting.co.za>
Message-ID: <1537398438.86.0.956365154283.issue32183@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32183>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:07:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:07:48 +0000
Subject: [issue32128] test_nntplib: test_article_head_body() fails in SSL mode
In-Reply-To: <1511573022.36.0.213398074469.issue32128@psf.upfronthosting.co.za>
Message-ID: <1537398468.14.0.956365154283.issue32128@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32128>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:09:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:09:12 +0000
Subject: [issue31321] traceback.clear_frames() doesn't clear *all* frames
In-Reply-To: <1504277417.4.0.438645016632.issue31321@psf.upfronthosting.co.za>
Message-ID: <1537398552.72.0.956365154283.issue31321@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31321>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:10:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:10:15 +0000
Subject: [issue30776] regrtest: change -R/--huntrleaks rule to decide if a
 test leaks references
In-Reply-To: <1498513763.26.0.144257056209.issue30776@psf.upfronthosting.co.za>
Message-ID: <1537398615.49.0.956365154283.issue30776@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30776>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:10:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:10:44 +0000
Subject: [issue30318] test_distutils is too verbose on Windows
In-Reply-To: <1494345266.31.0.621231206863.issue30318@psf.upfronthosting.co.za>
Message-ID: <1537398644.51.0.956365154283.issue30318@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30318>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:10:57 2018
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 19 Sep 2018 23:10:57 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1537398657.24.0.956365154283.issue34745@psf.upfronthosting.co.za>


Alexander Mohr <thehesiod at gmail.com> added the comment:

sorry, by "raw" I mean in the context of aiohttp, so just using the normal python ssl context and asyncio sockets.  I don't think it's an object not getting GC'd because I didn't see any increase on object counts, nor leaks per tracemalloc.  I think it's some low-level native memory leaked by openssl.

I've updated the gist w/ uvloop and ran with it and still get a leak, see gist + aiohttp issue for plot

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:11:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:11:03 +0000
Subject: [issue29881] Add a new private API clear private variables,
 which are initialized once, at Python shutdown
In-Reply-To: <1490201009.64.0.544065179107.issue29881@psf.upfronthosting.co.za>
Message-ID: <1537398663.3.0.956365154283.issue29881@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29881>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:11:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:11:23 +0000
Subject: [issue30170] "tests may fail,
 unable to create temporary directory" warning on buildbot: add a
 cleanup step to buildbots
In-Reply-To: <1493212642.62.0.333467089335.issue30170@psf.upfronthosting.co.za>
Message-ID: <1537398683.33.0.956365154283.issue30170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30170>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:11:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:11:41 +0000
Subject: [issue30244] Emit a ResourceWarning in concurrent.futures executor
 destructors
In-Reply-To: <1493795887.73.0.860969778348.issue30244@psf.upfronthosting.co.za>
Message-ID: <1537398701.33.0.956365154283.issue30244@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30244>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:11:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:11:54 +0000
Subject: [issue30227] test_site must not write outside the build directory:
 must not write into $HOME/.local/
In-Reply-To: <1493720121.71.0.343416046113.issue30227@psf.upfronthosting.co.za>
Message-ID: <1537398714.61.0.956365154283.issue30227@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30227>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:12:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:12:18 +0000
Subject: [issue30188] test_nntplib: random EOFError in setUpClass()
In-Reply-To: <1493305628.27.0.924756319794.issue30188@psf.upfronthosting.co.za>
Message-ID: <1537398738.23.0.956365154283.issue30188@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30188>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:12:36 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 19 Sep 2018 23:12:36 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537398756.05.0.956365154283.issue32557@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

(Excuse the GitHub syntax - was about to post it there, but it got long enough to belong here)

Regarding the `_dirnameW` discussion, fixing `_dirname` would be ideal, but that is bloating out your PR quite a bit :)

The "right" function to use there is [PathCchRemoveFileSpec](https://docs.microsoft.com/en-us/windows/desktop/api/pathcch/nf-pathcch-pathcchremovefilespec), which unfortunately does not exist on Windows 7.

The fallback is [PathRemoveFileSpec](https://docs.microsoft.com/en-us/windows/desktop/api/shlwapi/nf-shlwapi-pathremovefilespeca) which only supports up to `MAX_PATH` (but may do something relatively sensible for longer paths, such as trimming out the last directory separator before that limit - I haven't tested it).

Supporting both is tricky - there's a similar example in `PC/getpathp.c` for `PathCchCombineEx` that could be replicated for dirname. But I'd be okay with taking this PR without that fix and filing a new bug for `_dirnameW`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:12:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:12:40 +0000
Subject: [issue29451] Use _PyArg_Parser for _PyArg_ParseStack(): support
 positional only arguments
In-Reply-To: <1486289353.72.0.801621994712.issue29451@psf.upfronthosting.co.za>
Message-ID: <1537398760.3.0.956365154283.issue29451@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29451>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:13:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:13:07 +0000
Subject: [issue26568] Add a new warnings.showwarnmsg() function taking a
 warnings.WarningMessage object
In-Reply-To: <1458052320.63.0.791464551893.issue26568@psf.upfronthosting.co.za>
Message-ID: <1537398787.09.0.956365154283.issue26568@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26568>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:13:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 23:13:32 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1537398812.05.0.956365154283.issue34745@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Would you be able to test uvloop/master branch?  Current uvloop 0.11.x uses pretty much the asyncio implementation; the master branch has a completely rewritten SSL layer.  If the master branch has the leak it might mean that the root cause is indeed in either the ssl module or openssl itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:14:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:14:55 +0000
Subject: [issue21998] asyncio: support fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1537398895.71.0.956365154283.issue21998@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm torn between 2 & 3.  Guido, Victor, Martin, what do you think?

Give up, document that fork() is not supported and close the issue :-) IMHO it's not worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21998>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:15:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:15:10 +0000
Subject: [issue21702] asyncio: remote_addr of create_datagram_endpoint() is
 not documented
In-Reply-To: <1402385733.37.0.0697912425381.issue21702@psf.upfronthosting.co.za>
Message-ID: <1537398910.51.0.956365154283.issue21702@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21702>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:15:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:15:29 +0000
Subject: [issue20414] Python 3.4 has two Overlapped types
In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za>
Message-ID: <1537398929.15.0.956365154283.issue20414@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20414>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:16:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:16:34 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537398994.44.0.956365154283.issue19756@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I didn't see test_nntplib failing recently, so I close the issue as outdated.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:18:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:18:18 +0000
Subject: [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1537399098.9.0.956365154283.issue19431@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

It seems like these functions should be documented, so I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19431>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:18:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:18:29 +0000
Subject: [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1537399109.64.0.956365154283.issue19431@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution: out of date -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19431>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:18:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:18:50 +0000
Subject: [issue18295] Possible integer overflow in PyCode_New()
In-Reply-To: <1372108745.44.0.114375127897.issue18295@psf.upfronthosting.co.za>
Message-ID: <1537399130.55.0.956365154283.issue18295@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18295>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:19:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:19:56 +0000
Subject: [issue28224] Compilation warnings on Windows: export 'PyInit_xx'
 specified multiple times
In-Reply-To: <1474442469.56.0.286518199442.issue28224@psf.upfronthosting.co.za>
Message-ID: <1537399196.52.0.956365154283.issue28224@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28224>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:20:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:20:17 +0000
Subject: [issue29419] Argument Clinic: inline PyArg_UnpackTuple and
 PyArg_ParseStack(AndKeyword)?
In-Reply-To: <1486039849.42.0.101303637281.issue29419@psf.upfronthosting.co.za>
Message-ID: <1537399217.18.0.956365154283.issue29419@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29419>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:21:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:21:23 +0000
Subject: [issue29465] Modify _PyObject_FastCall() to reduce stack consumption
In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za>
Message-ID: <1537399283.24.0.956365154283.issue29465@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I should measure the stack usage to check if it's still worth it.

IMHO we gone far enough in optimizing the stack usage:
https://vstinner.github.io/contrib-cpython-2017q1.html

I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29465>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:22:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:22:38 +0000
Subject: [issue29674] Use GCC __attribute__((alloc_size(x,
 y))) on PyMem_Malloc() functions
In-Reply-To: <1488272050.61.0.409487721584.issue29674@psf.upfronthosting.co.za>
Message-ID: <1537399358.11.0.956365154283.issue29674@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29674>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:22:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:22:57 +0000
Subject: [issue30198] distutils build_ext: don't run newer_group() in parallel
 in multiple threads when using parallel
In-Reply-To: <1493381870.33.0.670258208626.issue30198@psf.upfronthosting.co.za>
Message-ID: <1537399377.36.0.956365154283.issue30198@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30198>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:24:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:24:31 +0000
Subject: [issue33868] test__xxsubinterpreters: test_subinterpreter() fails
 randomly on AMD64 Ubuntu Shared 3.x
In-Reply-To: <1529052832.87.0.947875510639.issue33868@psf.upfronthosting.co.za>
Message-ID: <1537399471.04.0.956365154283.issue33868@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33868>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:25:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:25:25 +0000
Subject: [issue33613] test_multiprocessing_fork:
 test_semaphore_tracker_sigint() fails with -W error
In-Reply-To: <1527069849.43.0.682650639539.issue33613@psf.upfronthosting.co.za>
Message-ID: <1537399525.04.0.956365154283.issue33613@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33613>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:25:30 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 23:25:30 +0000
Subject: [issue21998] asyncio: support fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1537399530.75.0.956365154283.issue21998@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'll revisit this later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21998>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:25:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:25:51 +0000
Subject: [issue33531] test_asyncio: test_subprocess test_stdin_broken_pipe()
 failure on Travis CI
In-Reply-To: <1526452192.92.0.682650639539.issue33531@psf.upfronthosting.co.za>
Message-ID: <1537399551.03.0.956365154283.issue33531@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33531>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:27:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:27:14 +0000
Subject: [issue31687] test_semaphore_tracker() of test_multiprocessing_spawn
 fails randomly (race condition?)
In-Reply-To: <1507109795.91.0.213398074469.issue31687@psf.upfronthosting.co.za>
Message-ID: <1537399634.92.0.956365154283.issue31687@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

bpo-33613 and bpo-34040 have been fixed. I hope that it will be enough.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31687>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:27:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:27:38 +0000
Subject: [issue30816] test_open() of test_eintr timeout after 10 min on
 "x86-64 El Capitan 3.x"
In-Reply-To: <1498832228.54.0.975621351907.issue30816@psf.upfronthosting.co.za>
Message-ID: <1537399658.9.0.956365154283.issue30816@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30816>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:28:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:28:50 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1537399730.74.0.956365154283.issue30317@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Let's close this giant issue since a fix has been merged. Please open a new issue if a similar bug appears.

Thanks Pablo Galindo for the fix ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:29:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:29:22 +0000
Subject: [issue29471] AST: add an attribute to FunctionDef to distinguish
 functions from generators and coroutines
In-Reply-To: <1486458539.58.0.744778606798.issue29471@psf.upfronthosting.co.za>
Message-ID: <1537399762.41.0.956365154283.issue29471@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm not sure we need this feature TBH.

Ok, I close the issue.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29471>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:30:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:30:23 +0000
Subject: [issue29306] Check usage of Py_EnterRecursiveCall() and
 Py_LeaveRecursiveCall() in new FASTCALL functions
In-Reply-To: <1484730285.0.0.960009012423.issue29306@psf.upfronthosting.co.za>
Message-ID: <1537399823.72.0.956365154283.issue29306@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm not sure about touching the stable branches. At least, the issue has been fixed since Python 3.7. I close the issue.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29306>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:31:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:31:14 +0000
Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body()
In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za>
Message-ID: <1537399874.51.0.956365154283.issue19613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I suggest to close the issue since the bug didn't show up recently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19613>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:32:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:32:15 +0000
Subject: [issue23236] asyncio: add timeout to StreamReader read methods
In-Reply-To: <1421196508.1.0.44699876054.issue23236@psf.upfronthosting.co.za>
Message-ID: <1537399935.0.0.956365154283.issue23236@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

This feature request doesn't seem popular and I lost track of it, so I just close the issue. Sorry.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23236>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:51:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:51:05 +0000
Subject: [issue32093] macOS: implement time.thread_time() using thread_info()
In-Reply-To: <1511198453.26.0.213398074469.issue32093@psf.upfronthosting.co.za>
Message-ID: <1537401065.01.0.956365154283.issue32093@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm not sure if it is worthwhile to implement this fairly specialised function for older macOS releases due to the maintenance cost.

Ok. I close the issue.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32093>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:53:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:53:54 +0000
Subject: [issue34131] test_threading: BarrierTests.test_default_timeout()
 failed on AppVeyor
In-Reply-To: <1531780347.81.0.56676864532.issue34131@psf.upfronthosting.co.za>
Message-ID: <1537401234.38.0.956365154283.issue34131@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34131>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:55:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 23:55:16 +0000
Subject: [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537401316.63.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Aaand... it's back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34733>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:55:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:55:24 +0000
Subject: [issue33966]
 test_multiprocessing_spawn.WithProcessesTestPool.test_traceback() leaks 4
 handles on Windows
In-Reply-To: <1530014102.79.0.56676864532.issue33966@psf.upfronthosting.co.za>
Message-ID: <1537401324.89.0.956365154283.issue33966@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I give up on that one :-( It doesn't seem easy to fix this corner case without changing the behaviour.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33966>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:55:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:55:44 +0000
Subject: [issue33920] test_asyncio:
 test_run_coroutine_threadsafe_with_timeout() failed on AMD64 FreeBSD 10.x
 Shared 3.7
In-Reply-To: <1529531278.55.0.56676864532.issue33920@psf.upfronthosting.co.za>
Message-ID: <1537401344.4.0.956365154283.issue33920@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33920>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:56:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:56:01 +0000
Subject: [issue33686] test_concurrent_futures: test_pending_calls_race()
 failed on x86 Windows7 3.6
In-Reply-To: <1527626766.22.0.682650639539.issue33686@psf.upfronthosting.co.za>
Message-ID: <1537401361.84.0.956365154283.issue33686@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33686>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:56:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:56:26 +0000
Subject: [issue33683] asyncio: sendfile tests ignore SO_SNDBUF on Windows
In-Reply-To: <1527602831.07.0.682650639539.issue33683@psf.upfronthosting.co.za>
Message-ID: <1537401386.39.0.956365154283.issue33683@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33683>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:56:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:56:46 +0000
Subject: [issue33680] regrtest: re-run failed tests in a subprocess
In-Reply-To: <1527594063.1.0.682650639539.issue33680@psf.upfronthosting.co.za>
Message-ID: <1537401406.2.0.956365154283.issue33680@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33680>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:57:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:57:08 +0000
Subject: [issue30884] regrtest -jN --timeout=TIMEOUT should kill child process
 running longer than TIMEOUT seconds
In-Reply-To: <1499634680.38.0.350592946082.issue30884@psf.upfronthosting.co.za>
Message-ID: <1537401428.96.0.956365154283.issue30884@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30884>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:57:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:57:36 +0000
Subject: [issue33676] test_multiprocessing_fork: dangling threads warning
In-Reply-To: <1527548628.93.0.682650639539.issue33676@psf.upfronthosting.co.za>
Message-ID: <1537401456.48.0.956365154283.issue33676@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33676>
_______________________________________

From report at bugs.python.org  Wed Sep 19 19:57:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:57:58 +0000
Subject: [issue34150] test_multiprocessing_spawn: Dangling processes leaked on
 AMD64 FreeBSD 10.x Shared 3.x
In-Reply-To: <1531932884.13.0.56676864532.issue34150@psf.upfronthosting.co.za>
Message-ID: <1537401478.03.0.956365154283.issue34150@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34150>
_______________________________________

From report at bugs.python.org  Wed Sep 19 20:51:37 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Thu, 20 Sep 2018 00:51:37 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537404696.99.0.956365154283.issue34660@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@terry.reed:

I politely ask you: Please use my proper first name if you refer to me and please don't call me an extremist (like here https://bugs.python.org/msg325802). Feel free to criticize my opinion but don't put labels on me. We don't know each other. Labeling people (not actions or ideas) is ad hominem argumentation or can be considered to be a personal attack which as far as I understand isn't complaint with CoC either.

And please don't misrepresent what I wrote:

> Marko called our actions 'madness' and here called us 'irresponsible'.   (https://bugs.python.org/issue34694#msg325802)

I called _the behavior_ irresponsible not the people. Even responsible people can sometimes have irresponsible choices or behavior.

> I find this behavior from the Python core developers and representatives simply rresponsible. (https://bugs.python.org/msg325499)

I hope we can end this debate here.

----------
nosy: +suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Wed Sep 19 22:45:19 2018
From: report at bugs.python.org (Keith Dart)
Date: Thu, 20 Sep 2018 02:45:19 +0000
Subject: [issue32810] Expose ags_gen and agt_gen in asynchronous generators
In-Reply-To: <1518205773.11.0.467229070634.issue32810@psf.upfronthosting.co.za>
Message-ID: <1537411519.46.0.956365154283.issue32810@psf.upfronthosting.co.za>


Change by Keith Dart <keith at dartworks.biz>:


----------
nosy: +kdart

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32810>
_______________________________________

From report at bugs.python.org  Wed Sep 19 23:30:46 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Sep 2018 03:30:46 +0000
Subject: [issue34138] imaplib RFC 6855 issue
In-Reply-To: <1531830667.9.0.56676864532.issue34138@psf.upfronthosting.co.za>
Message-ID: <1537414246.13.0.956365154283.issue34138@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8849
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34138>
_______________________________________

From report at bugs.python.org  Wed Sep 19 23:43:57 2018
From: report at bugs.python.org (Gordon Messmer)
Date: Thu, 20 Sep 2018 03:43:57 +0000
Subject: [issue34138] imaplib RFC 6855 issue
In-Reply-To: <1531830667.9.0.56676864532.issue34138@psf.upfronthosting.co.za>
Message-ID: <1537415037.39.0.956365154283.issue34138@psf.upfronthosting.co.za>


Gordon Messmer <gordon.messmer at gmail.com> added the comment:

PR 9436 should resolve the issue.

Since the RFC requires the "UTF8 (" prefix in the "data" and not in the literal, that had to be moved into the _command function.

This change should only affect the append() use, as that is currently the only function that sets self.literal to a value that is not a function.  The authenticate() use is not affected, and no other functions set self.literal.

----------
nosy: +gordonmessmer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34138>
_______________________________________

From report at bugs.python.org  Thu Sep 20 00:53:17 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Sep 2018 04:53:17 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1537419197.27.0.956365154283.issue34722@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Possibly we should just sort the individual marsahalled entries of the frozenset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Thu Sep 20 00:55:09 2018
From: report at bugs.python.org (lanzhiwang)
Date: Thu, 20 Sep 2018 04:55:09 +0000
Subject: [issue34746] Asyncio documentation have a error
Message-ID: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>


New submission from lanzhiwang <hzhilamp at 163.com>:

https://docs.python.org/3.7/library/asyncio-llapi-index.html

loop.stop() Close the event loop.
fix
loop.close() Close the event loop.

----------
components: asyncio
messages: 325838
nosy: asvetlov, docs at python, hzhilamp at 163.com, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio documentation have a error
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34746>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:06:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:06:59 +0000
Subject: [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420019.75.0.956365154283.issue34746@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8851
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34746>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:16:25 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 Sep 2018 05:16:25 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1537420585.08.0.956365154283.issue34686@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

See #34722.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:17:14 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:17:14 +0000
Subject: [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420634.41.0.956365154283.issue34746@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ffef50f1f5907e5f0f175b12088d3e509011f126 by Yury Selivanov in branch 'master':
bpo-34746: Fix stop -> close (GH-9437)
https://github.com/python/cpython/commit/ffef50f1f5907e5f0f175b12088d3e509011f126


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34746>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:17:28 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 05:17:28 +0000
Subject: [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420648.78.0.956365154283.issue34746@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8852

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34746>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:21:12 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 05:21:12 +0000
Subject: [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420872.04.0.956365154283.issue34746@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4fe8dc68577f9e22aaf24db08fb6647277c42d4c by Miss Islington (bot) in branch '3.7':
bpo-34746: Fix stop -> close (GH-9437)
https://github.com/python/cpython/commit/4fe8dc68577f9e22aaf24db08fb6647277c42d4c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34746>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:24:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:24:41 +0000
Subject: [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537421081.74.0.956365154283.issue34746@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks for filing the bug!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34746>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:38:05 2018
From: report at bugs.python.org (Shyam Saladi)
Date: Thu, 20 Sep 2018 05:38:05 +0000
Subject: [issue17560] problem using multiprocessing with really big objects?
In-Reply-To: <1364399521.2.0.696890688109.issue17560@psf.upfronthosting.co.za>
Message-ID: <1537421885.88.0.956365154283.issue17560@psf.upfronthosting.co.za>


Shyam Saladi <smsaladi at gmail.com> added the comment:

I apologize if this isn't the right forum to post this message, but Davin, if you have since put together the guide/blogpost mentioned in your message, would you be able to share a link to the material please?

I am interested in gaining a better understanding of multiprocessing's pluggable pickler and, more generally, dealing with large objects (the comment about this being being an anti-pattern is noted).

Thank you.

----------
nosy: +saladi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17560>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:42:17 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 20 Sep 2018 05:42:17 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537422137.2.0.956365154283.issue34736@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I welcome suggestions for improvement!

We could either find a better error message covering all cases, or emit a more specific message when non-base64 characters have been skipped.

Unfortunately, skipping non-base64 characters is a basic assumption of a2b_base64 which is used under the hood, and it currently provides no indication whether such characters are skipped, and if so how many.  Also, it is common in some contexts to have line breaks in base64-encoded data, which are skipped when decoding.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Thu Sep 20 01:58:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:58:16 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537423096.59.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8853

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 20 02:22:39 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 20 Sep 2018 06:22:39 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537424559.29.0.956365154283.issue34736@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Perhaps something such as "number of base64 data characters cannot be 1 more than a multiple of 4"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Thu Sep 20 03:31:08 2018
From: report at bugs.python.org (jophine antony)
Date: Thu, 20 Sep 2018 07:31:08 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537428668.22.0.956365154283.issue34732@psf.upfronthosting.co.za>


jophine antony <jophinep at gmail.com> added the comment:

I had raised a PR in github when i have created this ticket but forgot to add it here: https://github.com/python/cpython/pull/9413

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Thu Sep 20 03:39:05 2018
From: report at bugs.python.org (Vincent Pelletier)
Date: Thu, 20 Sep 2018 07:39:05 +0000
Subject: [issue34747] SSLSocket.context cannot be changed on non-connected
 sockets
Message-ID: <1537429145.63.0.956365154283.issue34747@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <vincent at nexedi.com>:

>From ssl.py, both on 2.7.15 and 3.6.6:
class SSLSocket(...):
...
    @context.setter
    def context(self, ctx):
        self._context = ctx
        self._sslobj.context = ctx

_sslobj is only set when socket is connected. While this is not a big issue for client sockets as user could just wrap the socket with correct context to begin with, and not a big issue for server sockets for the same reason, it is an issue for listening sockets: they are never connected, by definition, and do not care about _sslobj: upon accept() they only use self._context to wrap created socket.

Suggested fix:
    @context.setter
    def context(self, ctx):
        self._context = ctx
        if self._sslobj:
            self._sslobj.context = ctx
(consistently with how _sslobj is evaluated as a boolean elsewhere in the same class)

Suggested workaround (ex: if this fix is not backported to 2.7):
    try:
        ssl_socket.context = new_context
    except AttributeError:
        pass
as _context is changed first, and it's all that matters.

----------
messages: 325847
nosy: vincent-nexedi
priority: normal
severity: normal
status: open
title: SSLSocket.context cannot be changed on non-connected sockets
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34747>
_______________________________________

From report at bugs.python.org  Thu Sep 20 03:53:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Sep 2018 07:53:43 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537430023.5.0.956365154283.issue34659@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> As for pickling/copying, this task is technically difficult, 
> it but I don't see principal problems. 

I've added the pickle/copy support to the PR.

> is it worth to add it?

Tim was persuasive, so I've agreed to add the feature.  It may be little used but may help once in a while.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Thu Sep 20 05:24:37 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Thu, 20 Sep 2018 09:24:37 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537435477.59.0.956365154283.issue34694@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@Larry and Terry:

I want to stay out of this discussion or participation on Python development for the future as I've expressed it elsewhere (https://bugs.python.org/issue34660#msg325515). However, I want to address the unfair treatment of my person and what I consider to be a violation of CoC in the previous comment (https://bugs.python.org/issue34694#msg325802).

> We have been and will be attacked from extremists on both sides if consider changes on a case-by-case basis, accepting some and rejecting others.
> We have been and will be attacked from extremists on both sides for considering changes on a case-by-case basis, accepting some and rejecting others.

Labeling people as "extremists" without justification is _ad hominem_ and can be considered to be a personal attack. The term "extremism" has strong negative connotations and it's often related to "calling for violent action". The comment doesn't make clear neither 1) who or what group of people is meant to be extremist here nor 2) what was considered to be extremist. 

In general _ad hominem_ arguments and attacking someones reputation are not part of civil and rational argumentation/discourse. As far as I understand this isn't compliant with the Code of Conduct either. 

> Marko called our actions 'madness' and here called us 'irresponsible'.

I find this unfair and a misrepresentation of what I wrote:

> I find this behavior from the Python core developers and representatives simply irresponsible. (https://bugs.python.org/msg325499)

I explicitly referred to _behavior being irresponsible_ not the people. Even responsible people can have sometimes irresponsible decisions or behaviour. I also explained what I'd meant by "madness" (see here: https://bugs.python.org/issue34660#msg325503). And as I've already said elswhere:

> I can completely agree that I shouldn't/mustn't make sarcastic comments. (https://bugs.python.org/issue34660#msg325515)

I also agree with Larry that sarcasm isn't the best strategy :) However, silencing discussions like this "There will be no further discussion about this." (https://bugs.python.org/issue34694#msg325437) isn't a good strategy either. 

I don't want to be involved into further discussion and I politely ask you to not refer to me or labeling me.

Thank you,

Gabriel

----------
nosy: +suic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:04:04 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 20 Sep 2018 10:04:04 +0000
Subject: [issue34125] Profiling depends on whether **kwargs is given
In-Reply-To: <1531761360.51.0.56676864532.issue34125@psf.upfronthosting.co.za>
Message-ID: <1537437844.34.0.956365154283.issue34125@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34125>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:04:36 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 20 Sep 2018 10:04:36 +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: <1537437876.83.0.956365154283.issue25750@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25750>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:27:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 10:27:21 +0000
Subject: [issue34742] Add optional argument for exit status in
 argparse.ArgumentParser.error
In-Reply-To: <1537381633.99.0.956365154283.issue34742@psf.upfronthosting.co.za>
Message-ID: <1537439241.82.0.956365154283.issue34742@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34742>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:33:34 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 10:33:34 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1537439614.69.0.956365154283.issue34542@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 11485102cb7b3c57a1bc6d04c4ff4b1e25c53530 by Miss Islington (bot) (Christian Heimes) in branch '3.6':
[3.6] bpo-34542: Update test certs and keys (GH-8997) (GH-9396)
https://github.com/python/cpython/commit/11485102cb7b3c57a1bc6d04c4ff4b1e25c53530


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:33:57 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 10:33:57 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1537439637.35.0.956365154283.issue34542@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 49d65958e13db03b9a4240d8bdaff1a4be69a1d7 by Miss Islington (bot) (Christian Heimes) in branch '2.7':
[2.7] bpo-34542: Update test certs and keys (GH-8997) (GH-9397)
https://github.com/python/cpython/commit/49d65958e13db03b9a4240d8bdaff1a4be69a1d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:41:04 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 10:41:04 +0000
Subject: [issue34742] Add optional argument for exit status in
 argparse.ArgumentParser.error
In-Reply-To: <1537381633.99.0.956365154283.issue34742@psf.upfronthosting.co.za>
Message-ID: <1537440064.68.0.956365154283.issue34742@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems like a reasonable addition (Customization of writing to sys.stderr too) . It seems to have been inherited from optparse which has pretty much the same code with hardcoded exit code. The solution suggested is to catch SystemExit and provide custom status code or subclass ArgumentParser.

Googling "custom exit code ArgumentParser.error" gave me some discussions : 

* https://stackoverflow.com/questions/5943249/python-argparse-and-controlling-overriding-the-exit-status-code
* https://groups.google.com/forum/#!topic/comp.lang.python/NwsDljv_edk
* PEP discussion on sys.exit and stderr: https://www.python.org/dev/peps/pep-0389/#discussion-sys-stderr-and-sys-exit
* Open issue to customize stderr that might be helpful if someone wants to add a patch for custom exit code : https://bugs.python.org/issue9938

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34742>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:45:14 2018
From: report at bugs.python.org (Jatin Goel)
Date: Thu, 20 Sep 2018 10:45:14 +0000
Subject: [issue34737] Python upgrade with SYSTEM account uninstalls python
In-Reply-To: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>
Message-ID: <1537440314.44.0.956365154283.issue34737@psf.upfronthosting.co.za>


Jatin Goel <jatingoel1037 at gmail.com> added the comment:

Hi Steve,

It's not actually an issue with the Tcl/Tk package.

This is happening for all the packages.

Even with the installAllUsers flag set, the installation for all users fail, and then it tries to do justForMe installation, and that too is failing.

Again elaborating, this issue only comes when trying to upgrade the Python using the SYSTEM account.

No antivirus is running on any of the machines where it failed.

PFA the log file for Python installation.

You can find all the other log files in this GitHub repository: https://github.com/GoelJatin/PythonIssue34737

----------
Added file: https://bugs.python.org/file47816/InstallPython

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34737>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:49:55 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 20 Sep 2018 10:49:55 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537440595.23.0.956365154283.issue34663@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 20 06:52:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 10:52:33 +0000
Subject: [issue34559] multiprocessing AuthenticationError when nesting with
 non-default authkey
In-Reply-To: <1535753812.06.0.56676864532.issue34559@psf.upfronthosting.co.za>
Message-ID: <1537440753.55.0.956365154283.issue34559@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34559>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:10:54 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 11:10:54 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537441854.06.0.956365154283.issue32215@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 8d1e190fc507a9e304f6817e761e9f628a23cbd8 by Berker Peksag in branch 'master':
bpo-32215: Fix performance regression in sqlite3 (GH-8511)
https://github.com/python/cpython/commit/8d1e190fc507a9e304f6817e761e9f628a23cbd8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:11:10 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 11:11:10 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537441870.38.0.956365154283.issue32215@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8856

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:11:17 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 11:11:17 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537441877.54.0.956365154283.issue32215@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8857

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:14:38 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 11:14:38 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
In-Reply-To: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>
Message-ID: <1537442078.54.0.956365154283.issue34743@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset b10a64d117de6121ea3e79c467c4107f8f399f3d by Berker Peksag in branch 'master':
bpo-34743: Fix test_database_source_name under SQLite 3.7.9 (GH-9426)
https://github.com/python/cpython/commit/b10a64d117de6121ea3e79c467c4107f8f399f3d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:14:44 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 11:14:44 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
In-Reply-To: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>
Message-ID: <1537442084.41.0.956365154283.issue34743@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8858

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:25:13 2018
From: report at bugs.python.org (xitop)
Date: Thu, 20 Sep 2018 11:25:13 +0000
Subject: [issue34748] Incorrect HTML link in functools.partial
Message-ID: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>


New submission from xitop <reg.bugs at poti.sk>:

There is a minor issue regarding the page https://docs.python.org/3/library/functools.html

The description of functools.partial starts with text "Return a new partial object" which contains a link. This link does not point to the partial object (#partial-objects anchor) as it should. It points back
to the partial function (#functools.partial anchor) which is not helpful. The partial object docs can be thus easily overseen.

----------
assignee: docs at python
components: Documentation
messages: 325856
nosy: docs at python, xitop
priority: normal
severity: normal
status: open
title: Incorrect HTML link in functools.partial
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34748>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:25:43 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 11:25:43 +0000
Subject: [issue34344] Fix the docstring for
 AbstractEventLoopPolicy.get_event_loop
In-Reply-To: <1533549887.39.0.56676864532.issue34344@psf.upfronthosting.co.za>
Message-ID: <1537442743.94.0.956365154283.issue34344@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34344>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:31:16 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 11:31:16 +0000
Subject: [issue33813] Update overdue 'Deprecated ... removed in 3.x' messages
In-Reply-To: <1528562784.89.0.592728768989.issue33813@psf.upfronthosting.co.za>
Message-ID: <1537443076.31.0.956365154283.issue33813@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33813>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:37:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 11:37:09 +0000
Subject: [issue33545] Docs for uuid don't mention that uuid1 can repeat in
 some circumstances
In-Reply-To: <1526491965.86.0.682650639539.issue33545@psf.upfronthosting.co.za>
Message-ID: <1537443429.84.0.956365154283.issue33545@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33545>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:40:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 11:40:47 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537443647.92.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

======================================================================
ERROR: setUpClass (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_nntplib.py", line 292, in setUpClass
    usenetrc=False)
  File "/home/travis/build/python/cpython/Lib/nntplib.py", line 1043, in __init__
    self.sock = socket.create_connection((host, port), timeout)
  File "/home/travis/build/python/cpython/Lib/socket.py", line 724, in create_connection
    raise err
  File "/home/travis/build/python/cpython/Lib/socket.py", line 713, in create_connection
    sock.connect(sa)
OSError: [Errno 99] Cannot assign requested address

https://travis-ci.org/python/cpython/jobs/430974933

----------
status:  -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:41:13 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 11:41:13 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537443673.03.0.956365154283.issue19756@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
Removed message: https://bugs.python.org/msg325858

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:43:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 11:43:09 +0000
Subject: [issue33813] Update overdue 'Deprecated ... removed in 3.x' messages
In-Reply-To: <1528562784.89.0.592728768989.issue33813@psf.upfronthosting.co.za>
Message-ID: <1537443789.88.0.956365154283.issue33813@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue27032.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33813>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:45:10 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 20 Sep 2018 11:45:10 +0000
Subject: [issue34749] improve performance of binascii.a2b_base64()
Message-ID: <1537443910.98.0.956365154283.issue34749@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

I reworked implementation of binascii.a2b_base64() and there is significant speedup:

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from binascii import b2a_base64, a2b_base64; s = b2a_base64(1000 * b'b')" "a2b_base64(s)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 3.43 us +- 0.01 us
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 1.52 us +- 0.01 us
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 3.43 us +- 0.01 us -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 1.52 us +- 0.01 us: 2.26x faster (-56%)

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from binascii import b2a_base64, a2b_base64; s = b2a_base64(1 * b'b')" "a2b_base64(s)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 76.0 ns +- 0.2 ns
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 69.2 ns +- 0.1 ns
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 76.0 ns +- 0.2 ns -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 69.2 ns +- 0.1 ns: 1.10x faster (-9%)

----------
components: Extension Modules
messages: 325860
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: improve performance of binascii.a2b_base64()
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34749>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:45:58 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 20 Sep 2018 11:45:58 +0000
Subject: [issue34749] improve performance of binascii.a2b_base64()
In-Reply-To: <1537443910.98.0.956365154283.issue34749@psf.upfronthosting.co.za>
Message-ID: <1537443958.73.0.956365154283.issue34749@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +8859
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34749>
_______________________________________

From report at bugs.python.org  Thu Sep 20 07:54:54 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 11:54:54 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537444494.01.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I think it would be nice if tweaked support.transient_internet() to catch EADDRNOTAVAIL. See https://github.com/python/cpython/commit/e4dcbbd7f4ac18d01c0ec85f64ae98b8281ed403#diff-7fa374913c0ecbdc621db8ea79a1212bR78 for another example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:32:35 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Sep 2018 12:32:35 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1537446755.07.0.956365154283.issue34247@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The "ill-defined" in Python 3.6 relates to the fact that we never actually defined or tested which environment variables were read by Py_Main and which ones were read by Py_Initialize, since the majority of our tests only covered Py_Main (by launching a full Python subprocess).

Thus the only way to find out which environment variables fell into which category would be to read the Python 3.6 source code.

That's technically still the case for Python 3.7, but Victor's done some excellent refactoring work so it's much clearer in the code which vars may be updated if Py_Initialize is run a second time.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:37:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 12:37:21 +0000
Subject: [issue33236] MagicMock().__iter__.return_value is different from
 MagicMock().__iter__()
In-Reply-To: <1523015407.46.0.682650639539.issue33236@psf.upfronthosting.co.za>
Message-ID: <1537447041.5.0.956365154283.issue33236@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please link to the relevant documentation that is misleading? As I can see from the source code return value is a Mock object [1] which I believe the docs state as below : 

https://docs.python.org/3/library/unittest.mock.html#calling

> Mock objects are callable. The call will return the value set as the return_value attribute. The default return value is a new Mock object; it is created the first time the return value is accessed (either explicitly or by calling the Mock) - but it is stored and the same one returned each time.

from unittest.mock import MagicMock
x = MagicMock()

print(x.__iter__())
print(x.__iter__.return_value)
print(x.return_value)


?  cpython git:(master) ./python.exe bpo33236.py
<list_iterator object at 0x10d0797f0>
<MagicMock name='mock.__iter__()' id='4513568752'>
<MagicMock name='mock()' id='4513642816'>


[1] : https://github.com/python/cpython/blob/b10a64d117de6121ea3e79c467c4107f8f399f3d/Lib/unittest/mock.py#L463


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33236>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:38:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 12:38:12 +0000
Subject: [issue31628] test_emails failure on FreeBSD
In-Reply-To: <1506669614.14.0.213398074469.issue31628@psf.upfronthosting.co.za>
Message-ID: <1537447092.91.0.956365154283.issue31628@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31628>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:39:23 2018
From: report at bugs.python.org (Antony Lee)
Date: Thu, 20 Sep 2018 12:39:23 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
Message-ID: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

A quick check suggests that enum entries can be programmatically created by assigning to locals() in the Enum body:

   class E(Enum): locals()["a"] = 1
   E.a  # -> <E.a: 'a'>

However, using locals().update(...) doesn't, and silently does the wrong thing:

   class E(Enum): locals().update({"a": "a"})
   E.a  # -> 'a'

(Yes, in this simple case, I could just use the functional API (`E = Enum("E", [("a", "a")])`), but the above is simpler if I also want e.g. to define methods for the Enum.

----------
components: Library (Lib)
messages: 325864
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: locals().update doesn't work in Enum body, even though direct assignment to locals() does
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:39:53 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 12:39:53 +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: <1537447193.63.0.956365154283.issue33110@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33110>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:48:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Sep 2018 12:48:32 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537447712.84.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

https://github.com/python/cpython/pull/9257 should be complete now, although I may have gone overboard on the documentation updates (as it seems to be unclear, at least to Victor, why PYTHONCOERCECLOCALE exists in the first place)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:50:14 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Sep 2018 12:50:14 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537447814.53.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Also, the patch is currently still written on the assumption that it won't be backported to 3.7.1. I haven't checked if it would apply cleanly to 3.7.x, but I suspect not, given the magnitude of the startup changes targeting 3.8.0 since 3.7.0 was released)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Thu Sep 20 08:57:47 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 12:57:47 +0000
Subject: [issue33117] asyncio example uses non-existing/documented method
In-Reply-To: <1521666406.67.0.467229070634.issue33117@psf.upfronthosting.co.za>
Message-ID: <1537448267.21.0.956365154283.issue33117@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think `asyncio.run_coroutine_threadsafe(coro, loop)` returns a concurrent.futures.Future [1] which supports timeout and not asyncio.Future which doesn't support timeout. Please add in if I am missing anything. Since asyncio docs are being rewritten this would be a great time to contribute too if you would like to add more clarification.

Docs at [1] also say the below : 

asyncio.run_coroutine_threadsafe(coro, loop)

    Submit a coroutine to the given event loop. Thread-safe.

    Return a concurrent.futures.Future to wait for the result from another OS thread.


```
# bpo33117.py. This needs to be called from a different thread as docs said but I am using future.result(timeout) just to make sure there is no error with respect to function argument.

import asyncio

loop = asyncio.get_event_loop()
timeout = 4

# Create a coroutine
coro = asyncio.sleep(1, result=3)

# Submit the coroutine to a given loop
future = asyncio.run_coroutine_threadsafe(coro, loop)

# Wait for the result with an optional timeout argument
assert future.result(timeout) == 3
```


?  cpython git:(master) ./python.exe bpo33117.py
Traceback (most recent call last):
  File "../bpo33117.py", line 13, in <module>
    assert future.result(timeout) == 3
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/_base.py", line 438, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

[1] https://docs.python.org/3.8/library/concurrent.futures.html#concurrent.futures.Future



Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33117>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:06:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 13:06:58 +0000
Subject: [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1537448818.34.0.956365154283.issue19431@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I closed the issue because we decided to not document the function, but I'm still interested to mark the API is private. Such change is more sensitive, so I added it my larger "New C API" project which works on finding a way to deprecate functions and provide maybe helpers for backward and forward compatibility:
https://pythoncapi.readthedocs.io/bad_api.html#for-internal-use-only

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19431>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:08:49 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:08:49 +0000
Subject: [issue33085] *** Error in `python': double free or corruption (out):
 0x00007ff5254d50d0 ***
In-Reply-To: <1521183590.06.0.467229070634.issue33085@psf.upfronthosting.co.za>
Message-ID: <1537448929.68.0.956365154283.issue33085@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Can you please add a little more description on reproducing this issue along with OS details ? By "the installation of readline (6.2.4.1) [1]" are you referring to a third party package that you have installed with Python that resulted in a crash in Python interpreter? I tried it with master in a virtual env and cannot reproduce the same. Is this reproducible with latest Python or Python 3.6 version? Also it seems you are installing it as a root user does this happen only for root user or even with a virtualenv?


```
(bpo33085-env) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ pip install readline
[snip]
Installing collected packages: readline
  Running setup.py install for readline ... done
Successfully installed readline-6.2.4.1
(bpo33085-env) karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ python
Python 3.8.0a0 (heads/master:73820a6, Sep 14 2018, 18:33:26)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
```

[1] : https://pypi.org/project/readline/ (moved to https://pypi.org/project/gnureadline/)


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33085>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:14:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:14:13 +0000
Subject: [issue32995] Add a glossary entry for context variables
In-Reply-To: <1520244692.22.0.467229070634.issue32995@psf.upfronthosting.co.za>
Message-ID: <1537449253.33.0.956365154283.issue32995@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32995>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:18:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:18:21 +0000
Subject: [issue32291] Value error for string shared memory in multiprocessing
In-Reply-To: <1513098036.37.0.213398074469.issue32291@psf.upfronthosting.co.za>
Message-ID: <1537449501.69.0.956365154283.issue32291@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32291>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:24:02 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:24:02 +0000
Subject: [issue32019] Interactive shell doesn't work with readline bracketed
 paste
In-Reply-To: <1510614151.97.0.213398074469.issue32019@psf.upfronthosting.co.za>
Message-ID: <1537449842.1.0.956365154283.issue32019@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32019>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:24:43 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:24:43 +0000
Subject: [issue31898] Add a `recommended-packages.txt` file
In-Reply-To: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>
Message-ID: <1537449883.25.0.956365154283.issue31898@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31898>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:27:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:27:19 +0000
Subject: [issue31865] html.unescape does not work as per documentation
In-Reply-To: <1508899606.23.0.213398074469.issue31865@psf.upfronthosting.co.za>
Message-ID: <1537450039.34.0.956365154283.issue31865@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31865>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:27:27 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 20 Sep 2018 13:27:27 +0000
Subject: [issue34751] Hash collisions for tuples
Message-ID: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

It's not hard to come up with a hash collision for tuples:

>>> hash( (1,0,0) )
2528505496374819208
>>> hash( (1,-2,-2) )
2528505496374819208

The underlying reason is that the hashing code mixes ^ and *. This can create collisions because, for odd x, we have x ^ (-2) == -x and this minus operation commutes with multiplication.

This can be fixed by replacing ^ with +. On top of that, the hashing code for tuples looks needlessly complicated. A simple Bernstein hash suffices.

----------
messages: 325870
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Hash collisions for tuples

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:34:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 13:34:41 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537450481.89.0.956365154283.issue34663@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Thanks for chiming in Florian, and thanks Pablo for your detailed investigation. :)

I concur, very interesting talk ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:38:22 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Sep 2018 13:38:22 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1537450702.31.0.956365154283.issue34690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

python-dev thread with more discussion of the patch: https://mail.python.org/pipermail/python-dev/2018-September/155188.html

Note that my comment above was based on a misunderstanding of what the patch does - the module level code still gets executed at import time, what's able to be avoided is the unmarshalling costs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:38:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 13:38:23 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537450703.66.0.956365154283.issue19756@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I think it would be nice if tweaked support.transient_internet() to catch EADDRNOTAVAIL.

Sure, that sounds like a reasonable change? Do you want to work on a PR? If not, maybe we should open a new issue, since this issue is tidly linked to test_nntplib, whereas modifying support.transient_internet() is a more generic change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:42:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 13:42:19 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1537450939.58.0.956365154283.issue34247@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> The "ill-defined" in Python 3.6 relates to the fact that we never actually defined or tested which environment variables were read by Py_Main and which ones were read by Py_Initialize, since the majority of our tests only covered Py_Main (by launching a full Python subprocess).
>
> Thus the only way to find out which environment variables fell into which category would be to read the Python 3.6 source code.

Oh ok, I see. Thanks for the explanation.

> That's technically still the case for Python 3.7, but Victor's done some excellent refactoring work so it's much clearer in the code which vars may be updated if Py_Initialize is run a second time.

Well, for me the most important part is not the code, but tests. test_embed currently tests the following environment variables:

static void test_init_env_putenvs(void)
{
    putenv("PYTHONHASHSEED=42");
    putenv("PYTHONMALLOC=malloc_debug");
    putenv("PYTHONTRACEMALLOC=2");
    putenv("PYTHONPROFILEIMPORTTIME=1");
    putenv("PYTHONMALLOCSTATS=1");
    putenv("PYTHONUTF8=1");
    putenv("PYTHONVERBOSE=1");
    putenv("PYTHONINSPECT=1");
    putenv("PYTHONOPTIMIZE=2");
    putenv("PYTHONDONTWRITEBYTECODE=1");
    putenv("PYTHONUNBUFFERED=1");
    putenv("PYTHONNOUSERSITE=1");
    putenv("PYTHONFAULTHANDLER=1");
    putenv("PYTHONDEVMODE=1");
    /* FIXME: test PYTHONWARNINGS */
    /* FIXME: test PYTHONEXECUTABLE */
    /* FIXME: test PYTHONHOME */
    /* FIXME: test PYTHONDEBUG */
    /* FIXME: test PYTHONDUMPREFS */
    /* FIXME: test PYTHONCOERCECLOCALE */
    /* FIXME: test PYTHONPATH */
}

As you can see, the test suite is not complete yet. But since the tests are there, it shouldn't be hard to extend the test suite.

test_embed has InitConfigTests in 3.7 and master branches. I'm not interested to backport these tests to 3.6. I modified Python initialization deeply in 3.7, and the status of the code in 3.6 is "undefined". I don't think that it's worth it to backport these tests to 2.7 or 3.6. I success to focus on the master branch where we want to finish the implementation of the PEP 432 which should provide a better *public* API for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:44:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 13:44:06 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537451046.06.0.956365154283.issue19756@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Sure, that sounds like a reasonable change? 

Oh, typo: you should read "Sure, that sounds like a reasonable change." :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:48:36 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Sep 2018 13:48:36 +0000
Subject: [issue30140] Binary arithmetic does not always call subclasses first
In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za>
Message-ID: <1537451316.91.0.956365154283.issue30140@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that we've left a similar operand precedence handling issue languishing for a long time over compatibility concerns: https://bugs.python.org/issue11477

In that case, NumPy is actually benefiting from the discrepancy with the documentation though, as the lower-than-expected precedence of sq_concat and sq_repeat is what allows NumPy arrays to always take precedence over builtin container types, even when the array is the right hand operand.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30140>
_______________________________________

From report at bugs.python.org  Thu Sep 20 09:50:47 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Sep 2018 13:50:47 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1537451447.19.0.956365154283.issue34247@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, exactly - things are much improved already, thanks primarily to your work, and it seems likely they'll be even further improved by the time 3.8.0 comes around :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:10:06 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 14:10:06 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537452606.27.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Yeah, I will submit a pull request today. The reason I reopened this issue is that I didn't want to file another issue for a similar problem and wanted to use this as a meta issue for issues with test_nntplib. Also, I'd like to play Martin's patches a bit and see if they still needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:14:34 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 20 Sep 2018 14:14:34 +0000
Subject: [issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn
In-Reply-To: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>
Message-ID: <1537452874.4.0.956365154283.issue34663@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Same here, even if I learned more about the implementation of posix_spawn than I should have to know ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34663>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:15:37 2018
From: report at bugs.python.org (Nicholas Parslow)
Date: Thu, 20 Sep 2018 14:15:37 +0000
Subject: [issue34752] warnings.warn fails silently with unicode input
Message-ID: <1537452937.66.0.956365154283.issue34752@psf.upfronthosting.co.za>


New submission from Nicholas Parslow <nick.parslow at soapboxlabs.com>:

example:

Python 2.7.14 |Anaconda, Inc.| (default, Dec  7 2017, 17:05:42) 
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn(u'bl?')
>>> warnings.warn('blah')
__main__:1: UserWarning: blah

the warnings.warn_explicit function seems to be the part that is failing. On a machine which doesn't use anaconda it fails in an identical manner.

if you do:
>>> with warnings.catch_warnings(record=True) as w:
...   warnings.warn(u'bl?')
... 
>>> w
[<warnings.WarningMessage object at 0x7ffadb35b190>]
>>> w[0].message
UserWarning(u'bl\xe9',)


I can get that it fails with unicode (though it's annoying) but the silent fail is really bad imo.

----------
components: Extension Modules
messages: 325880
nosy: nparslow
priority: normal
severity: normal
status: open
title: warnings.warn fails silently with unicode input
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34752>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:28:05 2018
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 20 Sep 2018 14:28:05 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1537453685.01.0.956365154283.issue34750@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

`locals()` returns the dictionary being used (an _EnumDict) and direct assignment uses the `__setitem__` method, which has been overridden -- and it is the only one; so `update()`, etc., still have normal dict meanings and not Enum ones.

Next step:  compile list of all methods that _EnumDict should override.

Or just say it's not supported.

Antony, can you give a more detailed use-case?  Meaning an actual example, please.

----------
assignee:  -> ethan.furman
nosy: +ethan.furman
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:43:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 14:43:58 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537454638.13.0.956365154283.issue32892@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8860
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:53:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 14:53:16 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537455195.99.0.956365154283.issue32892@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 9445 is an implementation of this idea. For simplicity and for reducing affect on tests no deprecation warning is raised, and there is no validation of the type of argument for old classes. Num('123') will just return Constant('123') without errors and warnings. isinstance(Constant('123'), Num) will return False, and isinstance(Constant('123'), Str) will return True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 20 10:53:18 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 14:53:18 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537455198.44.0.956365154283.issue19756@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8861
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:06:50 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Sep 2018 15:06:50 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537456010.22.0.956365154283.issue34751@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> It's not hard to come up with a hash collision for tuples:

Nor is it hard to come up with collisions for most simple hash functions.  For typical use cases of tuples, what we have works out fine (it just combined the effects of the underlying hashes).

> The underlying reason is that the hashing code mixes ^ and *. 

Addition also has a relationship to multiplication.   I think the XOR is fine.

> A simple Bernstein hash suffices.

That is more suited to character data and small hash ranges (as opposed to 64-bit).  

>  On top of that, the hashing code for tuples looks 
> needlessly complicated.

The important thing is that it has passed our testing (see the comment above) and that it compiles nicely (see the tight disassembly below).


----------------------

L82:
    xorq    %r14, %rax
    imulq   %rbp, %rax
    leaq    82518(%rbp,%r12,2), %rbp
    movq    %r13, %r12
    movq    %rax, %r14
    leaq    -1(%r13), %rax
    cmpq    $-1, %rax
    je  L81
    movq    %rax, %r13
L73:
    addq    $8, %rbx
    movq    -8(%rbx), %rdi
    call    _PyObject_Hash
    cmpq    $-1, %rax
    jne L82

----------
components: +Interpreter Core
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> performance
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:08:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 15:08:30 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537456110.54.0.956365154283.issue32892@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

+1. I wanted to propose this change while I was working on FAT Python, but I waited until I "completed" this project. Sadly, I abandonned the FAT Python. And I wasn't brave enough to propose to break the AST.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:09:05 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 15:09:05 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537456145.14.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 8213eaddf3ce8e87564d2949454903a1484748b5 by Berker Peksag in branch 'master':
bpo-19756: Prevent test failures due to EADDRNOTAVAIL (GH-9446)
https://github.com/python/cpython/commit/8213eaddf3ce8e87564d2949454903a1484748b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:09:21 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:09:21 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537456161.25.0.956365154283.issue19756@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8862

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:09:32 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:09:32 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537456172.56.0.956365154283.issue19756@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8863

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:22:05 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 15:22:05 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537456925.08.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy:  -steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:22:10 2018
From: report at bugs.python.org (Windson Yang)
Date: Thu, 20 Sep 2018 15:22:10 +0000
Subject: [issue34753] Use coroutine object or coroutine function instead of
 coroutine
Message-ID: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>


New submission from Windson Yang <wiwindson at gmail.com>:

A PR https://github.com/python/cpython/pull/9408 solved an ambiguous problem about coroutine. Which led me to https://docs.python.org/3/library/asyncio-task.html#awaitables

> Note that in this documentation the term ?coroutine? can be used for two closely related concepts:

> a coroutine function: an async def function;
> a coroutine object: object returned by calling a coroutine function.

This will let people confused. IMO we should use `coroutine object` or `coroutine function` instead of coroutine when it means an object. For instance, L22 in https://github.com/python/cpython/blob/471503954a91d86cf04228c38134108c67a263b0/Doc/library/asyncio-api-index.rst

> Create event loop, run a coroutine, close the loop.
should be
> Create event loop, run a coroutine object, close the loop.

----------
assignee: docs at python
components: Documentation
messages: 325886
nosy: Windson Yang, docs at python
priority: normal
severity: normal
status: open
title: Use coroutine object or coroutine function instead of coroutine
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34753>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:23:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 15:23:52 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537457032.33.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 476177005e8c8d4ece3070c8c378f8b8c068e76f by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-19756: Prevent test failures due to EADDRNOTAVAIL (GH-9446)
https://github.com/python/cpython/commit/476177005e8c8d4ece3070c8c378f8b8c068e76f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:25:53 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:25:53 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537457153.51.0.956365154283.issue32215@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8864

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:26:29 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:26:29 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537457189.83.0.956365154283.issue19756@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8865

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:32:06 2018
From: report at bugs.python.org (Jose Angel Acosta)
Date: Thu, 20 Sep 2018 15:32:06 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537457526.52.0.956365154283.issue34694@psf.upfronthosting.co.za>


Jose Angel Acosta <acostaja at gmail.com> added the comment:

I'm so sorry to see my proposal just derived in personal attacks.
The problem here is the core who  "owns" python, admited a change to the Language documentation on whats should be considered a political or cultural bias w/o considering the broad community OPINION, I wont name it irresponsible but fairly disconnected with the purpose of OpenSource: freedom as on free speech, which is something being censored by latest core's commit on suggestion based on political or cultural bias, not code usability.
In other instances or communities it should have been enough to ask for the resignation of those that allowed this distortion introduced into the project -owned by the community, not the core approving commits-.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:36:26 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:36:26 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537457786.9.0.956365154283.issue19756@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1eabe19c57938dd70b66b97239be337294e15cba by Miss Islington (bot) in branch '3.6':
bpo-19756: Prevent test failures due to EADDRNOTAVAIL (GH-9446)
https://github.com/python/cpython/commit/1eabe19c57938dd70b66b97239be337294e15cba


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:43:30 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 15:43:30 +0000
Subject: [issue34754] test_flush_return_value fails on FreeBSD
Message-ID: <1537458210.16.0.956365154283.issue34754@psf.upfronthosting.co.za>


New submission from Berker Peksag <berker.peksag at gmail.com>:

======================================================================
FAIL: test_flush_return_value (test.test_mmap.MmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_mmap.py", line 754, in test_flush_return_value
    self.assertRaises(OSError, mm.flush, 1, len(b'python'))
AssertionError: OSError not raised by flush

I think I was relying on the behavior of Linux in that assert, it might be better to run that assert only under Linux.

----------
assignee: berker.peksag
components: Tests
messages: 325890
nosy: berker.peksag, koobs
priority: normal
severity: normal
stage: needs patch
status: open
title: test_flush_return_value fails on FreeBSD
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34754>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:45:11 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 20 Sep 2018 15:45:11 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537458311.74.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Nor is it hard to come up with collisions for most simple hash functions.

The Bernstein hash algorithm is a simple algorithm for which it can be proven mathematically that collisions cannot be generated if the multiplier is unknown. That is an objective improvement over the current tuple hash. Of course, in practice the multiplier is not secret, but it suffices that it is random enough.

> Addition also has a relationship to multiplication.

Of course, but not in a way that can be used to generate hash collisions. In fact, the simple relation between addition and multiplication makes this an actual provable mathematical statement.

> That is more suited to character data and small hash ranges (as opposed to 64-bit).

Maybe you are thinking of the multiplier 33 which is classically used for character data? If you replace the multiplier 33 by a larger number like _PyHASH_MULTIPLIER == 1000003 (ideally it would be a truly random number), it works fine for arbitrary sequences and arbitrary bit lengths.

> The important thing is that it has passed our testing

That's a silly argument. If it passed testing, it is only because the testing is insufficient.

But really: what I am proposing is a better hash without obvious collisions which won't be slower than the existing hash. Why would you be against that? Why should we "roll our own" hash instead of using a known good algorithm?

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:56:34 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 15:56:34 +0000
Subject: [issue34754] test_flush_return_value fails on FreeBSD
In-Reply-To: <1537458210.16.0.956365154283.issue34754@psf.upfronthosting.co.za>
Message-ID: <1537458994.07.0.956365154283.issue34754@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8866
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34754>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:57:01 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 15:57:01 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537459021.69.0.956365154283.issue32215@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 015cd0f5cb17b1b208a92e549cd665dc38f2f699 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-32215: Fix performance regression in sqlite3 (GH-8511)
https://github.com/python/cpython/commit/015cd0f5cb17b1b208a92e549cd665dc38f2f699


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:57:46 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:57:46 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537459066.53.0.956365154283.issue32215@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8867

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 11:58:34 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 15:58:34 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
In-Reply-To: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>
Message-ID: <1537459114.02.0.956365154283.issue34743@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8868

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:06:08 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 16:06:08 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537459568.53.0.956365154283.issue19756@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 170ea8ccd4235d28538ab713041502d07ad1cacd by Miss Islington (bot) in branch '2.7':
bpo-19756: Prevent test failures due to EADDRNOTAVAIL (GH-9446)
https://github.com/python/cpython/commit/170ea8ccd4235d28538ab713041502d07ad1cacd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:07:17 2018
From: report at bugs.python.org (Antony Lee)
Date: Thu, 20 Sep 2018 16:07:17 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1537459637.17.0.956365154283.issue34750@psf.upfronthosting.co.za>


Antony Lee <anntzer.lee at gmail.com> added the comment:

I have a personal helper function for writing (Qt) GUIs that generates ComboBoxes from Enums; essentially something like

    class Choices(Enum):
        choice1 = "text for choice 1"
        choice2 = "text for choice 2"

    def callback(choice: Choices):
        # do stuff based on choice
        pass

    create_combobox(Choices, callback=callback)

I'm not including the actual code for create_combobox because it's not particularly relevant here.

So far, if I wanted to add methods to the Choice enum (e.g. for simplifying the code in `callback`), I could do it directly; if I wanted to dynamically generate the list of choices, I could also do it (by using the functional API).  But to do both, it would have been nice to use the locals().update approach in the bug report above.  Instead, I need to do something like

    class MethodsMixin(Enum):
        def method(self): ...

    ChoicesWithMethods = MethodsMixin("ChoicesWithMethods", [<the choices>])

(As a side note, I originally thought I could do the inheritance in the opposite direction

    Choices = Enum("Choices", [...])

    class ChoicesWithMethods(Choices):
        def method(self): ...

but that fails because Choices is a final class.  It would be nice if it was still possible to inherit from Choices *as long as only methods are added, rather than new members* (I understand why adding new members is problematic).  But this is really a side point.)

Making _EnumDict actually support update() and every other relevant method is actually not particularly difficult: I think you just need to make it inherit from (collections.abc.MutableMapping, dict) (in that order); this is exactly the approach used (since a while ago) by matplotlib's RcParams class (https://github.com/matplotlib/matplotlib/blob/v3.0.0/lib/matplotlib/__init__.py#L783).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:09:59 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Thu, 20 Sep 2018 16:09:59 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537459799.72.0.956365154283.issue34648@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

> In 3.4, format_list() was documented to accept return values of extract_tb() > and extract_stack() functions and they both were returned lists:
> 
>     def extract_tb(tb, limit=None):
>         return list(_extract_tb_iter(tb, limit=limit))
> 
>     def extract_stack(f=None, limit=None):
>         stack = list(_extract_stack_iter(_get_stack(f), limit=limit))
>         stack.reverse()
>         return stack

I think that?s an unnecessarily and extraordinarily narrow reading - you could use the same reading to make a judgement of ?format_list may only be passed values returned by extract_tb and extract_stack rather than other values of the same type?, and that would be absurd.

I don?t think it?s a wise choice to say ?because the motivation for offering the format_list function was to work with values returned by extract_tb and extract_stack, the allowed inputs to format_list should be restricted to just those types?.

Why not support Iterable[FrameSummary]? A choice to support Iterable[FrameSummary] *is also a choice to support List[FrameSummary]*. It's just a "wider" choice; it?s not a breaking choice to drop support for List[FrameSummary].

> I don't think we support the "pass manually created iterables" case here.

What?s a ?manually created iterable?? What kinds of iterables aren?t ?manually created iterables?? Can their differences be captured in the type system?

> Yes, the old API is still supported for backwards compatibility reasons.

This is a very flat statement that invites questions by what it doesn?t say and by the way it describes something that is true today without saying for how long into the future that thing will remain true. For how long will the old API be supported for backwards compatibility reasons? Is new code encouraged to use the new API? If the new API is better, shouldn?t new code use it? If the new API isn?t better, why was it introduced?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:11:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 16:11:56 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537459916.12.0.956365154283.issue19756@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Berker! Do you want to do something with Martin's patches? If not, can you please close the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:15:08 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Sep 2018 16:15:08 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537460108.7.0.956365154283.issue34320@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, the PEP 520 example isn't exactly right.  PEP 520 is about the class definition namespace, not the namespace object passed to type().  That always does the right thing, since the default class definition namespace is dict (which happens to be ordered in 3.6+).

That said, a test that explicitly calls type() with an OrderedDict, as you have shown, is still a good idea since type() always changes the namespace to a dict.

Perhaps another good test of the same thing would be with a metaclass that returns an OrderedDict from __prepare__():

  class Meta(type):
      @classmethod
      def __prepare__(meta, name, bases, **kwargs):
          return OrderedDict()

  class Spam(metaclass=Meta):
      a = 1
      b = 2

  Spam.__dict__

Just keep in mind that neither of those is specific to PEP 520.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:16:49 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Sep 2018 16:16:49 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537460209.07.0.956365154283.issue34320@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
Removed message: https://bugs.python.org/msg325897

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:17:17 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 20 Sep 2018 16:17:17 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537460237.94.0.956365154283.issue34320@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, the PEP 520 example isn't exactly right.  PEP 520 is about the class definition namespace, not the namespace object passed to type().  That always does the right thing, since the default class definition namespace is dict (which happens to be ordered in 3.6+).

That said, a test that explicitly calls type() with an OrderedDict, as you have shown, is still a good idea since type() always changes the namespace to a dict.

Perhaps another good test of the same thing would be with a metaclass that returns an OrderedDict from __prepare__():

  class Meta(type):
      @classmethod
      def __prepare__(meta, name, bases, **kwargs):
          return OrderedDict()

  class Spam(metaclass=Meta):
      a = 1
      b = 2
      locals().move_to_end('a')

  Spam.__dict__

Just keep in mind that neither of those is specific to PEP 520.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:39:51 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 16:39:51 +0000
Subject: [issue34011] Default preference not given to venv DLL's
In-Reply-To: <1530353263.14.0.56676864532.issue34011@psf.upfronthosting.co.za>
Message-ID: <1537461591.15.0.956365154283.issue34011@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

This change breaks a number of tests when run on a proper installation, since we still need to copy pythonXY.dll or else python.exe refuses to start.

Since I'm fixing these tests today, I'll also fix this issue.

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34011>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:40:44 2018
From: report at bugs.python.org (Elliot Edmunds)
Date: Thu, 20 Sep 2018 16:40:44 +0000
Subject: [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1537461644.03.0.956365154283.issue16438@psf.upfronthosting.co.za>


Elliot Edmunds <edmundselliot at gmail.com> added the comment:

I agree that linking to the precedence table is probably the best solution.

A different option would be to add an extra column listing the "priority" and rank the priorities of the different operations.

----------
nosy: +Elliot Edmunds

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16438>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:44:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 16:44:10 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537461850.95.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset e247b46cba4f4d32ea96a15dbc36d73265171106 by Yury Selivanov in branch 'master':
bpo-33649: More improvements (GH-9439)
https://github.com/python/cpython/commit/e247b46cba4f4d32ea96a15dbc36d73265171106


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:44:16 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 16:44:16 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537461856.95.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8869

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:50:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 16:50:56 +0000
Subject: [issue34755] Few minor optimizations in _asynciomodule.c
Message-ID: <1537462256.95.0.956365154283.issue34755@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

* Perform cheap comparison with None before expensive checks in task_step_impl().
* Use more efficient private API for getting and setting an optional attribute.
* Use PyGen_Check() instead of inspect.isgenerator().
* Use faster and more idiomatic way of getting the name of the type.

----------
messages: 325902
nosy: asvetlov, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Few minor optimizations in _asynciomodule.c
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34755>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:52:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 16:52:33 +0000
Subject: [issue34755] Few minor optimizations in _asynciomodule.c
In-Reply-To: <1537462256.95.0.956365154283.issue34755@psf.upfronthosting.co.za>
Message-ID: <1537462353.17.0.956365154283.issue34755@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8870
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34755>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:53:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 16:53:11 +0000
Subject: [issue34754] test_flush_return_value fails on FreeBSD
In-Reply-To: <1537458210.16.0.956365154283.issue34754@psf.upfronthosting.co.za>
Message-ID: <1537462391.08.0.956365154283.issue34754@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset bc854750589d4de0fd55693963964e0558b5c8ac by Berker Peksag in branch 'master':
bpo-34754: Fix test_flush_return_value on FreeBSD (GH-9451)
https://github.com/python/cpython/commit/bc854750589d4de0fd55693963964e0558b5c8ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34754>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:53:21 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 20 Sep 2018 16:53:21 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537462401.89.0.956365154283.issue32892@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't feel confident reviewing the code, but I'm okay with the change. Can you describe what usages of the old API will continue to work, and what part will break? (It would seem that code that creates a tree using e.g. Num(42) will still work, but code inspecting a tree won't see any Num instances, only Constant instances.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:57:23 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 16:57:23 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537462643.66.0.956365154283.issue33649@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8e5ef58c10a1154f824d5875c2d89794a800eadc by Miss Islington (bot) in branch '3.7':
bpo-33649: More improvements (GH-9439)
https://github.com/python/cpython/commit/8e5ef58c10a1154f824d5875c2d89794a800eadc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:57:55 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 16:57:55 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1537462675.1.0.956365154283.issue26119@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26119>
_______________________________________

From report at bugs.python.org  Thu Sep 20 12:58:28 2018
From: report at bugs.python.org (Joe Pamer)
Date: Thu, 20 Sep 2018 16:58:28 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537462708.05.0.956365154283.issue32557@psf.upfronthosting.co.za>


Joe Pamer <joe at noteven.org> added the comment:

Awesome - thanks, Steve - this is all super helpful! If you're cool with it I'd like to stick to using _dirnameW for now, and then follow up with another set of PRs for the fixes you've recommended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:10:45 2018
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 20 Sep 2018 17:10:45 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537463445.77.0.956365154283.issue34732@psf.upfronthosting.co.za>


Richard Neumann <mail at richard-neumann.de> added the comment:

I updated my pull request.
Since "_windll_getnode()" is only returning a (random?) node for a UUID, I circumevented the value checking by introducing a new keyword-only argument "strict" defaulting to "True", there being set to "False".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:11:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 17:11:02 +0000
Subject: [issue34753] Use coroutine object or coroutine function instead of
 coroutine
In-Reply-To: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>
Message-ID: <1537463462.84.0.956365154283.issue34753@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> This will let people confused. IMO we should use `coroutine object` or `coroutine function` instead of coroutine when it means an object.

I'm not sure that it's a good idea to apply this change everywhere, but I think in general this is a good idea.  Do you want to submit a PR?

----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34753>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:13:27 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 20 Sep 2018 17:13:27 +0000
Subject: [issue34742] Add optional argument for exit status in
 argparse.ArgumentParser.error
In-Reply-To: <1537381633.99.0.956365154283.issue34742@psf.upfronthosting.co.za>
Message-ID: <1537463607.5.0.956365154283.issue34742@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

While I don't think this change will cause any backward compatibility issues, I wonder whether it does much good.

https://docs.python.org/3/library/argparse.html#exiting-methods

already documents the option of customizing `parser.exit` and `parser.error`

parser.exit has the optional status argument (default 0).

I don't see how an error method with optional status can be used without some sort of subclassing.  At least not for standard argparse errors.  It would only help for custom error calls. 

    parser.error('my own error message', status=0)

The usual errors are issued with a

    self.error(message)

call.

Unittest, 'test_argparse.py' has a ErrorRaisingArgumentParser class that customizes both error() and exit().  But its error catching code is a bit complicated.

Another SO reference on argparse unittesting:

https://stackoverflow.com/questions/39028204/using-unittest-to-test-argparse-exit-errors

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34742>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:16:37 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Sep 2018 17:16:37 +0000
Subject: [issue30947] Update embeded copy of libexpat from 2.2.1 to 2.2.3
In-Reply-To: <1500301095.91.0.571865583049.issue30947@psf.upfronthosting.co.za>
Message-ID: <1537463797.43.0.956365154283.issue30947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Victor, the PR for this BPO has introduced XML_POOR_ENTROPY. Neither the commit message nor the issue explains why. Which platform failed to compile without XML_POOR_ENTROPY?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30947>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:16:37 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:16:37 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537463797.8.0.956365154283.issue34648@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> Why not support Iterable[FrameSummary]?

The question that needs to be answered here is "why we should support Iterable[FrameSummary]?" and you're one the one who needs to answer it instead of saying our design decisions were "absurd" and "not wise", without giving any concrete use cases for your "wider" design choice.

Initial docstring for format_list() were added in 2000: https://github.com/python/cpython/commit/e7b146fb3bdca62a0d5ecc06dbf3348e5a4fe757#diff-e57ff53a569d0ebbe201ad0c102ee27e

    Given a list of tuples as returned by extract_tb() or
    extract_stack(), return a list of strings ready for printing.

There are no tests for iterables other than list at https://github.com/python/cpython/blob/master/Lib/test/test_traceback.py 

So we won't change documentation and docstrings, add more tests without seeing concrete use cases.

> What?s a ?manually created iterable??

I meant an iterable that is extracted from a traceback object manually without using extract_tb() or extract_stack() functions (by using a custom function, an external dependency, or HTTP API) How people can get Iterable[FrameSummary] as an input and pass it to format_list()?

> For how long will the old API be supported for backwards
> compatibility reasons?

I don't remember any plans to remove the support for the old API. And I'm pretty sure we won't do anything until 2.7 is out of maintenance.

> Is new code encouraged to use the new API? If the new API is better,
> shouldn?t new code use it? If the new API isn?t better, why was it
> introduced?

Are you serious? No, we've introduced the new API and spent weeks designing it just to play with people. They should stick with the old one for no reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:19:53 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:19:53 +0000
Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an
 UPDATE statement in a string
In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za>
Message-ID: <1537463993.98.0.956365154283.issue32215@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 4fb672ff96ecbb87aaf2ecc4f04aed76aafe63b1 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-32215: Fix performance regression in sqlite3 (GH-8511)
https://github.com/python/cpython/commit/4fb672ff96ecbb87aaf2ecc4f04aed76aafe63b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32215>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:20:35 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:20:35 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
In-Reply-To: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>
Message-ID: <1537464035.78.0.956365154283.issue34743@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c56bbae5e92828a4c93be3b0e7a5072a31fdc587 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-34743: Fix test_database_source_name under SQLite 3.7.9 (GH-9426)
https://github.com/python/cpython/commit/c56bbae5e92828a4c93be3b0e7a5072a31fdc587


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:21:08 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:21:08 +0000
Subject: [issue34743] test_database_source_name fails with SQLite 3.7.9
In-Reply-To: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>
Message-ID: <1537464068.07.0.956365154283.issue34743@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34743>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:33:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 17:33:39 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
Message-ID: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR makes the following changes in sys.breakpointhook():

* Use _PyObject_GetBuiltin() for getting a builtin. This simplifies the code.

* The only effect of using the "from" list is when the imported name is a submodule. But it should be a callable. Callable module is very rare bird, I don't think we need to support such weird case. Removing the "from" list simplifies the code.

* Only ImportError and AttributeError raised from import are ignored. Other errors are exposed to the user as is. This is most likely a KeyboardInterrupt or MemoryError. They shouldn't be silenced.

sys.breakpointhook() was added in issue31353.

----------
components: Interpreter Core
messages: 325914
nosy: barry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Few changes in sys.breakpointhook()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:33:39 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:33:39 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1537464819.54.0.956365154283.issue34732@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> I had raised a PR in github when i have created this ticket but forgot
> to add it here: https://github.com/python/cpython/pull/9413

Thanks for the PR, Jophine :) I saw your PR yesterday, but I thought fixing this in __init__ would be a better solution. I may be wrong, though, so let's see what other core devs think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:35:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 17:35:24 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1537464924.29.0.956365154283.issue34756@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8871
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:44:58 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:44:58 +0000
Subject: [issue34754] test_flush_return_value fails on FreeBSD
In-Reply-To: <1537458210.16.0.956365154283.issue34754@psf.upfronthosting.co.za>
Message-ID: <1537465498.96.0.956365154283.issue34754@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

>From AMD64 FreeBSD 10.x Shared 3.x:

> 0:18:38 load avg: 5.04 [390/419/1] test_mmap passed

https://buildbot.python.org/all/#/builders/87/builds/1465/steps/4/logs/stdio

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34754>
_______________________________________

From report at bugs.python.org  Thu Sep 20 13:56:03 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:56:03 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537466163.94.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the reviews, Victor. I'm planning to work on them tonight. I will close this issue and open a new one if I decide to do further work on them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 14:00:30 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 18:00:30 +0000
Subject: [issue34011] Default preference not given to venv DLL's
In-Reply-To: <1530353263.14.0.56676864532.issue34011@psf.upfronthosting.co.za>
Message-ID: <1537466430.24.0.956365154283.issue34011@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8872

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34011>
_______________________________________

From report at bugs.python.org  Thu Sep 20 14:11:35 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 20 Sep 2018 18:11:35 +0000
Subject: [issue34757] Placeholder for discussion on Combined patches for AIX -
 to resolve failig tests
Message-ID: <1537467095.33.0.956365154283.issue34757@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

One PR to Rule them all :p

----------
components: Tests
messages: 325918
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Placeholder for discussion on Combined patches for AIX - to resolve failig tests
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34757>
_______________________________________

From report at bugs.python.org  Thu Sep 20 14:12:13 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 20 Sep 2018 18:12:13 +0000
Subject: [issue34757] Placeholder for discussion on Combined patches for AIX -
 to resolve failig tests
In-Reply-To: <1537467095.33.0.956365154283.issue34757@psf.upfronthosting.co.za>
Message-ID: <1537467133.15.0.956365154283.issue34757@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8873
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34757>
_______________________________________

From report at bugs.python.org  Thu Sep 20 14:21:08 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 18:21:08 +0000
Subject: [issue34737] Python upgrade with SYSTEM account uninstalls python
In-Reply-To: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>
Message-ID: <1537467668.11.0.956365154283.issue34737@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Looking closer at the logs, it's the usual problem of not being able to upgrade a per-user install into an all-users install.

If you look at the logs closely, it's *uninstalling* the Just for Me install, not installing it.

The best option in this case is to detect the per-user install (should always be HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{0e7285f4-8cd4-4f97-83ab-1c6946551e2c} for 64-bit) and uninstall it first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34737>
_______________________________________

From report at bugs.python.org  Thu Sep 20 14:45:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 18:45:35 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
In-Reply-To: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>
Message-ID: <1537469135.29.0.956365154283.issue34730@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Interesting.

Nathaniel, do you have this problem in Trio (aclose() not cancelling an anext()) or cancel scopes solve this problem somehow?

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:05:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 19:05:11 +0000
Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body()
In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za>
Message-ID: <1537470311.39.0.956365154283.issue19613@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The test_article_head_body test is now skipped unconditionally:

    @unittest.skipIf(True, "FIXME: see bpo-32128")

I don't think we should close this issue without re-enabling that test.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19613>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:16:04 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 20 Sep 2018 19:16:04 +0000
Subject: [issue34458] No way to alternate options
In-Reply-To: <1534896831.7.0.56676864532.issue34458@psf.upfronthosting.co.za>
Message-ID: <1537470964.91.0.956365154283.issue34458@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34458>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:16:57 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 20 Sep 2018 19:16:57 +0000
Subject: [issue34479] ArgumentParser subparser error display at the wrong level
In-Reply-To: <1535038332.48.0.56676864532.issue34479@psf.upfronthosting.co.za>
Message-ID: <1537471017.93.0.956365154283.issue34479@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34479>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:17:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 19:17:13 +0000
Subject: [issue30947] Update embeded copy of libexpat from 2.2.1 to 2.2.3
In-Reply-To: <1500301095.91.0.571865583049.issue30947@psf.upfronthosting.co.za>
Message-ID: <1537471033.47.0.956365154283.issue30947@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Christian Heimes <lists at cheimes.de> added the comment:
> Victor, the PR for this BPO has introduced XML_POOR_ENTROPY. Neither the commit message nor the issue explains why. Which platform failed to compile without XML_POOR_ENTROPY?

And, maybe:

"Oh, compilation fails on Travis CI at:"
https://github.com/python/cpython/pull/3106#issuecomment-323118722

And my rationale is (extract of setup.py):


                # bpo-30947: Python uses best available entropy sources to
                # call XML_SetHashSalt(), expat entropy sources are not needed
                ('XML_POOR_ENTROPY', '1'),

But I'm wrong if I understood what you told me last week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30947>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:21:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 19:21:53 +0000
Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body()
In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za>
Message-ID: <1537471313.36.0.956365154283.issue19613@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

>  I don't think we should close this issue without re-enabling that test.

The fact is that nobody cares of test_nntplib: this issue is open for 5 years. I don't see how leaving the issue open which helps. It's fine to skip a test if nobody is available to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19613>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:26:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 19:26:33 +0000
Subject: [issue34752] warnings.warn fails silently with unicode input
In-Reply-To: <1537452937.66.0.956365154283.issue34752@psf.upfronthosting.co.za>
Message-ID: <1537471593.43.0.956365154283.issue34752@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34752>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:32:19 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Sep 2018 19:32:19 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537471939.19.0.956365154283.issue34670@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +8874
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:36:41 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 19:36:41 +0000
Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body()
In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za>
Message-ID: <1537472201.5.0.956365154283.issue19613@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Well, no one is going to notice it if we close this issue. I don't see why the age of the issue matters here. We close issues when we fix them. It may take 20 minutes, 5 years or a decade.

I understand closing an issue as "out of date" when we couldn't find the root of the problem, but in this case the problem is obvious and there is already a patch that tries to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19613>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:39:14 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Sep 2018 19:39:14 +0000
Subject: [issue30947] Update embeded copy of libexpat from 2.2.1 to 2.2.3
In-Reply-To: <1500301095.91.0.571865583049.issue30947@psf.upfronthosting.co.za>
Message-ID: <1537472354.11.0.956365154283.issue30947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Do you remember which platform failed? It doesn't say on the GH PR either.

See #34623 for security bug. We only set good salt for pyexpat based parsers (sax, dom, pure Python etree), but not for the C-accelerated ElementTree implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30947>
_______________________________________

From report at bugs.python.org  Thu Sep 20 15:46:32 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 20 Sep 2018 19:46:32 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1537472792.12.0.956365154283.issue32947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Kurt, see #34670 for PHA for server and client side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Thu Sep 20 16:31:02 2018
From: report at bugs.python.org (Robert)
Date: Thu, 20 Sep 2018 20:31:02 +0000
Subject: [issue33236] MagicMock().__iter__.return_value is different from
 MagicMock().__iter__()
In-Reply-To: <1523015407.46.0.682650639539.issue33236@psf.upfronthosting.co.za>
Message-ID: <1537475462.45.0.956365154283.issue33236@psf.upfronthosting.co.za>


Robert <lma at posteo.de> added the comment:

According to this chapter ( https://docs.python.org/3/library/unittest.mock.html#unittest.mock.MagicMock ) the specialmethods in MagicMock are different:

.return_value is preinitialized with defaultvalues, which depends on the operator. In the case of .__iter__ this is "iter([])".
This is the case when running __iter__(), but not when running __iter__.result_value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33236>
_______________________________________

From report at bugs.python.org  Thu Sep 20 16:34:17 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 20 Sep 2018 20:34:17 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
In-Reply-To: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>
Message-ID: <1537475657.78.0.956365154283.issue34730@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Part of the issue here is the one discussed in bpo-30773 / bpo-32526: async generators allow themselves to be re-entered while another asend/athrow/aclose call is in progress, and it causes weird and confusing results. So at a minimum, trying to call aclose while another task is calling asend should make aclose raise an error saying that the generator is already busy.

Of course the OP wants to go further and have aclose actually trigger a cancellation of any outstanding asend/athrow. I see the intuition here, but unfortunately I don't think this can work. Doing a cancellation requires some intimate knowledge of the coroutine runner. You can't just throw in an exception; you also have to unwind the task state. (Eg in the example with 'event.wait', you need to somehow tell the event object that this task is no longer waiting for it, so it shouldn't be notified when the event occurrs.)

So I think we just need to fix ag_running and then recommend people find other ways to interrupt running async generators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Thu Sep 20 16:36:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 20:36:06 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
In-Reply-To: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>
Message-ID: <1537475766.51.0.956365154283.issue34730@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> So I think we just need to fix ag_running and then recommend people find other ways to interrupt running async generators.

Agree. Speaking of fixing ag_running, could you please review my PR: https://github.com/python/cpython/pull/7468 I can then commit it and maybe get this fixed in 3.7.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Thu Sep 20 16:38:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 20:38:42 +0000
Subject: [issue34011] Default preference not given to venv DLL's
In-Reply-To: <1530353263.14.0.56676864532.issue34011@psf.upfronthosting.co.za>
Message-ID: <1537475922.96.0.956365154283.issue34011@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset f14c28f39766855420dd58d209da4ad847f3030e by Steve Dower in branch 'master':
bpo-34011: Fixes missing venv files and other tests (GH-9458)
https://github.com/python/cpython/commit/f14c28f39766855420dd58d209da4ad847f3030e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34011>
_______________________________________

From report at bugs.python.org  Thu Sep 20 16:44:54 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 20:44:54 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537476294.43.0.956365154283.issue19756@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8875

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 16:52:48 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 20:52:48 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1537476768.02.0.956365154283.issue19756@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

PR 9461 converts Martin's nntp-server.patch. I've made some tweaks and fixed a "threading._dangling was modified by test_nntplib" warning. I will try to convert multi-connect.patch later.

I will attribute Martin as the patch author before merging the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 17:03:51 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 20 Sep 2018 21:03:51 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1537477431.04.0.956365154283.issue34756@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Serhiy.  I'm curious whether this is a pure clean up or if there are actual problems you're trying to fix.

* I'm okay with using _PyObject_GetBuiltin() but it does bother me in general to use too many non-public (and thus undocumented) APIs.  It makes understanding what's going on more difficult.  This is a general gripe of mine with Python's C API.

* Given that removing support for callable modules is technically a backward incompatible change, is it worth it?  If we had done it before 3.7 was released, it would have been fine, but now we can't guarantee it won't break someone's code.  I agree it's unlikely, but it is possible.

* Perhaps we should explicitly pass through KeyboardInterrupt and MemoryError rather than just ignoring ImportError and AttributeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Thu Sep 20 17:31:41 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Sep 2018 21:31:41 +0000
Subject: [issue34011] Default preference not given to venv DLL's
In-Reply-To: <1530353263.14.0.56676864532.issue34011@psf.upfronthosting.co.za>
Message-ID: <1537479101.51.0.956365154283.issue34011@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I agree with this only applying to 3.8 - removing the copied files on earlier versions seems like an unnecessary risk to compatibility.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34011>
_______________________________________

From report at bugs.python.org  Thu Sep 20 17:58:50 2018
From: report at bugs.python.org (Christoph Zwerschke)
Date: Thu, 20 Sep 2018 21:58:50 +0000
Subject: [issue34730] aclose() doesn't stop raise StopAsyncIteration /
 GeneratorExit to __anext__()
In-Reply-To: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>
Message-ID: <1537480730.79.0.956365154283.issue34730@psf.upfronthosting.co.za>


Change by Christoph Zwerschke <cito at online.de>:


----------
nosy: +cito

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34730>
_______________________________________

From report at bugs.python.org  Thu Sep 20 19:29:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 23:29:10 +0000
Subject: [issue30947] Update embeded copy of libexpat from 2.2.1 to 2.2.3
In-Reply-To: <1500301095.91.0.571865583049.issue30947@psf.upfronthosting.co.za>
Message-ID: <1537486150.81.0.956365154283.issue30947@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Do you remember which platform failed? It doesn't say on the GH PR either.

It was the Linux job of Travis CI, something like an old Ubuntu LTS version.

Since Travis CI prevented me to merge anything and Python already has access to a safe PRNG, I didn't worry about that issue. The disabled code shouldn't be needed on Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30947>
_______________________________________

From report at bugs.python.org  Thu Sep 20 20:09:24 2018
From: report at bugs.python.org (Travis O'Neill)
Date: Fri, 21 Sep 2018 00:09:24 +0000
Subject: [issue34758] http.server module sets incorrect mimetype for
 WebAssembly files
Message-ID: <1537488564.12.0.956365154283.issue34758@psf.upfronthosting.co.za>


New submission from Travis O'Neill <travis.h.oneill at gmail.com>:

Mimetype is set to application/octet-stream for .wasm files instead of the correct application/wasm.  This causes streaming compile feature to fail (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiateStreaming).

----------
components: Library (Lib)
messages: 325935
nosy: Travis O'Neill
priority: normal
severity: normal
status: open
title: http.server module sets incorrect mimetype for WebAssembly files
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34758>
_______________________________________

From report at bugs.python.org  Thu Sep 20 20:16:49 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Sep 2018 00:16:49 +0000
Subject: [issue34758] http.server module sets incorrect mimetype for
 WebAssembly files
In-Reply-To: <1537488564.12.0.956365154283.issue34758@psf.upfronthosting.co.za>
Message-ID: <1537489009.43.0.956365154283.issue34758@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8876
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34758>
_______________________________________

From report at bugs.python.org  Thu Sep 20 21:21:22 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Sep 2018 01:21:22 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537492882.45.0.956365154283.issue34751@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

ISTM, you're being somewhat aggressive and condescending.  I'll hand you off to Tim who is far better at wrestling over the details :-)

>From my point of view, you've made a bold and unsubstantiated claim that Python's existing tuple hash has collision issues with real code.  Only a contrived and trivial integer example was shown.

On my end, I made an honest effort to evaluate the suggestion.  I read your post, 
looked up Bernstein hash, revisited the existing C code and found that everything it is doing makes sense to me.  There was a comment indicating that empirical tests were run to get the best possible constants.  Also, I disassembled the code to verify that it is somewhat efficiently compiled.

Your responded that I'm being "silly" and then you reversed my decision to close the issue (because there is no evidence that the hash is broken).  Accordingly, I'm going to hand it over to Tim who I'm sure will know the history of the existing code, can compare and contrast the various options, evaluate them in the context of typical Python use cases, and assess whether some change is warranted.

----------
assignee:  -> tim.peters
nosy: +tim.peters
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Thu Sep 20 21:36:50 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Sep 2018 01:36:50 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1537493810.16.0.956365154283.issue34656@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a4ae828ee416a66d8c7bf5ee71d653c2cc6a26dd by Benjamin Peterson in branch 'master':
closes bpo-34656: Avoid relying on signed overflow in _pickle memos. (GH-9261)
https://github.com/python/cpython/commit/a4ae828ee416a66d8c7bf5ee71d653c2cc6a26dd


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 20 21:36:57 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 01:36:57 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1537493817.46.0.956365154283.issue34656@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8878

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 20 21:37:06 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 01:37:06 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1537493826.92.0.956365154283.issue34656@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8879

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 20 21:52:40 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 01:52:40 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1537494760.59.0.956365154283.issue34656@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ef4306b24c9034d6b37bb034e2ebe82e745d4b77 by Miss Islington (bot) in branch '3.7':
closes bpo-34656: Avoid relying on signed overflow in _pickle memos. (GH-9261)
https://github.com/python/cpython/commit/ef4306b24c9034d6b37bb034e2ebe82e745d4b77


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:00:41 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 02:00:41 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1537495241.82.0.956365154283.issue34656@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 71a9c65e74a70b6ed39adc4ba81d311ac1aa2acc by Miss Islington (bot) in branch '3.6':
closes bpo-34656: Avoid relying on signed overflow in _pickle memos. (GH-9261)
https://github.com/python/cpython/commit/71a9c65e74a70b6ed39adc4ba81d311ac1aa2acc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:05:23 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 02:05:23 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
Message-ID: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

Hey Ned, we just noticed that since a few days ago the trio testsuite is failing on 3.7-dev (but not 3.7.0), in a test checking an obscure feature in the ssl module: https://travis-ci.org/python-trio/trio/builds/431291929

And I just reproduced the issue locally with a build of the 3.7 branch HEAD, so somehow whatever is happening is definitely new in 3.7.1.

It could just be a bug in the test or something, I don't know because I haven't debugged it yet (I'll do that now). But with 3.7.1rc1 imminent I figured you'd rather know earlier rather than later.

----------
assignee: christian.heimes
components: SSL
keywords: 3.7regression
messages: 325940
nosy: christian.heimes, ned.deily, njs
priority: normal
severity: normal
status: open
title: Possible regression in ssl module in 3.7.1 and master
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:06:06 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 02:06:06 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537495566.52.0.956365154283.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

(And Christian, if you know of any risky-sounding recent changes in SSLObject.unwrap, lmk :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:18:33 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Sep 2018 02:18:33 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537496313.95.0.956365154283.issue34715@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8880

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:23:25 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 02:23:25 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537496605.04.0.956365154283.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Git bisect says:


1229664f30dd5fd4da32174a19258f8312464d45 is the first bad commit
commit 1229664f30dd5fd4da32174a19258f8312464d45
Author: Miss Islington (bot) <31488909+miss-islington at users.noreply.github.com>
Date:   Mon Sep 17 12:12:13 2018 -0700

    bpo-32533: Fixed thread-safety of error handling in _ssl. (GH-7158)
    
    (cherry picked from commit c6fd1c1c3a65217958b68df3a4991e4f306e9b7d)
    
    Co-authored-by: Steve Dower <steve.dower at microsoft.com>


Now let's see if I can narrow down exactly what the behavioral change is, besides "this random test started failing"...

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:35:24 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 02:35:24 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537497324.94.0.956365154283.issue34759@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

It should just be gathering SSL error codes before acquiring the GIL, which could switch thread and then get the wrong code.

Of course, it's possible it is in the backport. How easily can you test against master? (I'm AFK, so can't easily do anything right now.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:37:29 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Sep 2018 02:37:29 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537497449.65.0.956365154283.issue34715@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:39:51 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 02:39:51 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537497591.35.0.956365154283.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

The test doesn't involve any threads, so it does seem strange that this PR changed its behavior.

I haven't checked against master carefully, but the original observation was that our Travis "3.7-dev" and "3.8-dev" tests started failing in the same way sometime in the last week-ish, so my tentative guess is that it it's the same for both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:48:44 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 02:48:44 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537498124.3.0.956365154283.issue34759@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for the heads-up!  If you become convinced it's a post-3.7.0 regression that would affect 3.7.1, please change the priority to "release blocker".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Thu Sep 20 22:52:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Sep 2018 02:52:22 +0000
Subject: [issue34715] timemodule.c fails to compile on BSD
In-Reply-To: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>
Message-ID: <1537498342.92.0.956365154283.issue34715@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset c510c6b8b60f211793e0b84c317ea6974e8a6153 by Benjamin Peterson in branch 'master':
Simplify PyInit_timezone. (GH-9467)
https://github.com/python/cpython/commit/c510c6b8b60f211793e0b84c317ea6974e8a6153


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34715>
_______________________________________

From report at bugs.python.org  Thu Sep 20 23:22:22 2018
From: report at bugs.python.org (Windson Yang)
Date: Fri, 21 Sep 2018 03:22:22 +0000
Subject: [issue34753] Use coroutine object or coroutine function instead of
 coroutine
In-Reply-To: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>
Message-ID: <1537500142.28.0.956365154283.issue34753@psf.upfronthosting.co.za>


Windson Yang <wiwindson at gmail.com> added the comment:

Sure, I found around 7 places may need to change, I can fix some of them right, and I will put the rest links which I'm not sure in the PR comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34753>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:29:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 04:29:38 +0000
Subject: [issue34748] Incorrect HTML link in functools.partial
In-Reply-To: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>
Message-ID: <1537504178.69.0.956365154283.issue34748@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34748>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:37:22 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 04:37:22 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537504642.62.0.956365154283.issue34589@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks, Victor and Nick, for the work.  With the revert merged (GH-9430), this issue is no longer a release blocker for 3.7.1, correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:46:25 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 04:46:25 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537505185.25.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

@jdemeyer, please define exactly what you mean by "Bernstein hash".  Bernstein has authored many hashes, and none on his current hash page could possibly be called "simple":

    https://cr.yp.to/hash.html

If you're talking about the teensy 

    hash = hash * 33 + c;

thing from now-ancient C folklore, Bernstein is claimed to have replaced addition with xor in that later:

    http://www.cse.yorku.ca/~oz/hash.html

In any case, Python _used_ to do plain

    x = (1000003 * x) ^ y;
    
but changed to the heart of the current scheme 14 years ago to address Source Forge bug #942952:
    https://github.com/python/cpython/commit/41bd02256f5a2348d2de3d6e5fdfcaeb2fcaaebc#diff-cde4fb3109c243b2c2badb10eeab7fcd

The Source Forge bug reports no longer appear to exist.  If you care enough, dig through the messages with subject:

    [ python-Bugs-942952 ] Weakness in tuple hash

here:

    https://mail.python.org/pipermail/python-bugs-list/2004-May/subject.html

The thrust was that the simpler approach caused, in real life, hashes of nested tuples of the form

    (X, (X, Y))

to return hash(Y) - the hash(X) parts across calls magically xor'ed out.

It was also systematically the case that

   (X, (Y, Z))

and

   (Y, (X, Z))

hashed to the same thing.

So the complications were added for a reason, to address the showed-up-in-real-life pathological cases discussed in the bug report already linked to.  Since I don't believe we've had other reports of real-life pathologies since, nobody is going to change this again without truly compelling reasons.  Which I haven't seen here, so I'm closing this report again.

BTW, as also explained in that report, the goal of Python's hash functions is to minimize collisions in dicts in real life.  We generally couldn't care less whether they "act random", or are hard to out-guess.  For example,

     assert all(hash(i) == i for i in range(1000000))

has always succeeded.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:51:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 04:51:40 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537505500.66.0.956365154283.issue34751@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

(FWIW, I believe the Source Forge bug reports were forwarded ported to bugs.python.org.  This looks like the issue in question: https://bugs.python.org/issue942952 )

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:51:55 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 04:51:55 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537505515.57.0.956365154283.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

The ssl module's unwrap() method is intended to do a clean shutdown of TLS encryption on a socket (or memory BIO or whatever). The idea is that it sends a "close notify" frame (i.e., tells the peer that we're shutting down), and then it waits for the peer to send a "close notify" back, and then the TLS layer is cleanly shut down.

If you have a non-blocking socket or memory BIO, of course, it can't actually wait for the peer to send the "close notify" back. So in this case its semantics are: the first time you call it, it sends a "close notify", and then if it hasn't seen a "close notify", it raises SSLWantReadError to tell you that, and that you need to keep calling it.

In the current 3.7 branch, however, it never raises SSLWantReadError, so there's no way for calling code to figure out whether the other side has sent a "close notify". So in the current 3.7 branch, it's impossible to do a clean shutdown of the TLS layer on a non-blocking socket or memory BIO, and this is a regression from 3.7.0.

The attached script demonstrates this -- on 3.7.0 it completes successfully, but on the 3.7 branch it fails.

Impact: This is maybe not as bad as it sounds, because 'unwrap' is *very* rarely used? (Lots of protocols have STARTTLS, but not many have STOPTLS!) But I'm still going to mark it as a release blocker for now because:

- it is a genuine regression, that makes a rare-but-intentional-and-documented feature unusable

- while I haven't fully understood why the thread-safety patch causes this problem, the changes that patch makes to 'unwrap' are very similar to the changes it makes to much more important functions like 'do_handshake' and 'send' and 'recv', so I'm nervous that the underlying issue might affect those as well.

- I figure if Ned doesn't think it's a release blocker, he can always remove the tag :-)

----------
priority: normal -> release blocker
Added file: https://bugs.python.org/file47817/ssl-unwrap-regression-example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:54:02 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 04:54:02 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537505642.71.0.956365154283.issue34759@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Steve?  Christian?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Fri Sep 21 00:55:05 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 04:55:05 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537505705.47.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Ah!  I see that the original SourceForge bug report got duplicated on this tracker, as PR #942952.  So clicking on that is a lot easier than digging thru the mail archive.

One message there noted that replacing xor with addition made collision statistics much worse for the cases at issue.

----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 01:09:04 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 05:09:04 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537506544.92.0.956365154283.issue34751@psf.upfronthosting.co.za>


Change by Tim Peters <tim at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 01:36:30 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 05:36:30 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537508190.29.0.956365154283.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Oh, here it is:

https://github.com/python/cpython/commit/1229664f30dd5fd4da32174a19258f8312464d45#diff-e1cc5bf74055e388cda128367a814c8fR2587


-    if (err < 0) {
+    if (err.ssl < 0) {

Before in this function, 'err' was the return code from SSL_shutdown, which is -1 if an error occurred (and you're supposed to look at the SSL error code) or 0/1 on success. Now 'err.ssl' is the actual SSL error code, which as it turns out is never negative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Fri Sep 21 01:41:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 05:41:07 +0000
Subject: [issue31146] Docs: On non-public translations,
 language picker fallback to "English"
In-Reply-To: <1502206180.29.0.859774070814.issue31146@psf.upfronthosting.co.za>
Message-ID: <1537508467.76.0.956365154283.issue31146@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31146>
_______________________________________

From report at bugs.python.org  Fri Sep 21 01:54:47 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 05:54:47 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537509287.91.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> ISTM, you're being somewhat aggressive and condescending. 

Interestingly, I felt the same with your reply, which explains my rapid reversion of your closing of the ticket. The way I see it: I pointed out a bug in tuple hashing and you just closed that, basically claiming that it's not a bug.

I still don't understand why you are closing this so quickly. To put it differently: if I can improve the hash function, removing that obvious collision, extending the tests to catch this case, while not making it slower, why shouldn't this be done?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 01:55:03 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 05:55:03 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537509303.82.0.956365154283.issue34759@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
keywords: +patch
pull_requests: +8881
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Fri Sep 21 01:57:20 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 05:57:20 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537509440.06.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Since I don't believe we've had other reports of real-life pathologies since

You just did in this bug report. Why doesn't that count?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:06:40 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 06:06:40 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537510000.78.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

@jdemeyer, you didn't submit a patch, or give any hint that you _might_.  It _looked_ like you wanted other people to do all the work, based on a contrived example and a vague suggestion.

And we already knew from history that "a simple Bernstein hash suffices" is false for tuple hashing (for one possible meaning of "a simple Bernstein hash" - we had one of those 14 years ago).

Neither Raymond nor I want to spend time on this ourselves, so in the absence of somebody else volunteering to do the work, there's no reason to keep the report open uselessly.

If you're volunteering to do the work ... then do the work ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:09:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 06:09:52 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537510192.05.0.956365154283.issue34735@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 91e6c8717b7dcbcc46b189509de5f2d335819f37 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-34735: Fix a memory leak in Modules/timemodule.c (GH-9418)
https://github.com/python/cpython/commit/91e6c8717b7dcbcc46b189509de5f2d335819f37


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:10:02 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 06:10:02 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537510202.31.0.956365154283.issue34735@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8882

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:10:12 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 06:10:12 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537510212.3.0.956365154283.issue34735@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8883

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:10:27 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 06:10:27 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537510227.26.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

To come back to the topic of hashing, with "Bernstein hash" for tuples I did indeed mean the simple (in Python pseudocode):

# t is a tuple
h = INITIAL_VALUE
for x in t:
    z = hash(x)
    h = (h * MULTIPLIER) + z
return h

I actually started working on the code and there is indeed an issue with the hashes of (X, (Y, Z)) and (Y, (X, Z)) being equal that way. But that can be solved by replacing "hash(x)" in the loop by something slightly more complicated. After thinking about it, I decided to go for shifting higher to lower bits, so replacing z by z^(z >> 32) or something like that.

This also has the benefit of mixing the high-order bits into the low-order bits, which is an additional improvement over the current code.

Since I already wrote the code anyway, I'll create a PR for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:10:38 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 06:10:38 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537510238.78.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

You said it yourself:  "It's not hard to come up with ...".  That's not what "real life" means.  Here:

>>> len(set(hash(1 << i) for i in range(100_000)))
61

Wow!  Only 61 hash codes across 100 thousand distinct integers?!

Yup - and I don't care.  I contrived the case, just like you apparently contrived yours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:11:35 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 06:11:35 +0000
Subject: [issue34755] Few minor optimizations in _asynciomodule.c
In-Reply-To: <1537462256.95.0.956365154283.issue34755@psf.upfronthosting.co.za>
Message-ID: <1537510295.34.0.956365154283.issue34755@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fb3e9c00ed79f4d880ab9a67aab861eb3660ec75 by Serhiy Storchaka in branch 'master':
bpo-34755: Add few minor optimizations in _asynciomodule.c. (GH-9455)
https://github.com/python/cpython/commit/fb3e9c00ed79f4d880ab9a67aab861eb3660ec75


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34755>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:11:40 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 06:11:40 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537510300.7.0.956365154283.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

PR posted. Also seems to affect 3.6, so adding that to the tags.

----------
keywords: +3.6regression
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:12:18 2018
From: report at bugs.python.org (Monte Davidoff)
Date: Fri, 21 Sep 2018 06:12:18 +0000
Subject: [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537510338.24.0.956365154283.issue29013@psf.upfronthosting.co.za>


Monte Davidoff <md14-python at alluvialsw.com> added the comment:

Serhiy, merely reverting the change would not fix the originally reported problem in the documentation. Based on your additional information, and to prevent the need to describe the ZIP64 extensions in more than one place, I suggest two changes:

(1) Change the second paragraph in the zipfile module documentation from:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that are more than 4 GiB in size)."

to:

"It can handle ZIP files that use the ZIP64 extensions."

(2) In the description of the zipfile.ZipFile class, change:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 4 GiB."

to:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GiB or contains more than 65535 files."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29013>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:18:11 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 06:18:11 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537510691.37.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

For the record: my collision is not contrived. It came up in actual code where I was hashing some custom class using tuples and found an unexpected high number of collisions, which I eventually traced back to the collision I reported here.

By the way, I think the worst real-life hash collision is

>>> hash(-1) == hash(-2)
True

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:23:33 2018
From: report at bugs.python.org (Jatin Goel)
Date: Fri, 21 Sep 2018 06:23:33 +0000
Subject: [issue34737] Python upgrade with SYSTEM account uninstalls python
In-Reply-To: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>
Message-ID: <1537511013.46.0.956365154283.issue34737@psf.upfronthosting.co.za>


Jatin Goel <jatingoel1037 at gmail.com> added the comment:

Thanks for the info Steve.

Yeah I noticed it earlier, but couldn't make sense why it would try  per-user uninstall at all. (Thought some upgrade issue, and it was a rollback action)

Though we've been doing the installation for all users from the beginning with our script from SYSTEM account.

This is the first time we tried upgrade.

I'll check and verify on the machines if someone modified it, i.e., uninstalled python and then re-installed with Just for Me option selected.

Will let you know how it goes.

Thanks Again!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34737>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:38:05 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Sep 2018 06:38:05 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537511885.41.0.956365154283.issue34623@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The bug affects multiple platforms. libexpat's expat.h uses slightly different autoconf macro names than pyconfig.h. Therefore only platforms that have either HAVE_GETRANDOM or _WIN32 defined, use a proper CSPRNG to seed the hash salt.

Since HAVE_SYSCALL_GETRANDOM, HAVE_ARC4RANDOM_BUF, HAVE_ARC4RANDOM, or XML_DEV_URANDOM are never defined by Python's pyconfig.h, older Linux platforms, any BSD, and any other Unix platform with /dev/urandom fall back to a weak Mersenne Twister-like RNG with gettimeofday().tv_usec and getpid() as seed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:47:30 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Sep 2018 06:47:30 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537512450.26.0.956365154283.issue34623@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I have contected Red Hat product security to request a CVE for the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:49:59 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Sep 2018 06:49:59 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537512599.58.0.956365154283.issue34759@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Good catch, Nathaniel.

I was about to ask for a reproducer test, but then I saw that you have added one already. Fantastic!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:58:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 06:58:52 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1537513132.21.0.956365154283.issue34756@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a pure clean up except the last item which fixes a minor problem. I had wrote this patch a while ago (perhaps before 3.7.0 was released), and now revive my old patches.

I think that the general rule is that exceptions shouldn't be ignored blindly, except in case when we have no choice (like in destructors). ImportError and AttributeError are expected exceptions raised in PyImport_ImportModuleLevelObject and PyObject_GetAttrString when PYTHONBREAKPOINT points to non-existing name, all other exceptions mean exceptional situation or programming error. Note that exceptions raised when call the hook are not ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Fri Sep 21 02:59:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 06:59:54 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1537513194.52.0.956365154283.issue34756@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I will drop cleanup changes if they don't look good to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Fri Sep 21 03:41:49 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 07:41:49 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537515709.33.0.956365154283.issue34735@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f37496e893d743dbd01c802c8e8cdc16498a1604 by Miss Islington (bot) in branch '3.6':
bpo-34735: Fix a memory leak in Modules/timemodule.c (GH-9418)
https://github.com/python/cpython/commit/f37496e893d743dbd01c802c8e8cdc16498a1604


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Fri Sep 21 03:41:53 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 07:41:53 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537515713.44.0.956365154283.issue34735@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 975f3cb1f25406a9be019906227d53b23852f415 by Miss Islington (bot) in branch '3.7':
bpo-34735: Fix a memory leak in Modules/timemodule.c (GH-9418)
https://github.com/python/cpython/commit/975f3cb1f25406a9be019906227d53b23852f415


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34735>
_______________________________________

From report at bugs.python.org  Fri Sep 21 04:00:36 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Sep 2018 08:00:36 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537516836.06.0.956365154283.issue34670@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Please note that SSL_verify_client_post_handshake() doesn't perform any IO by itself.

A typical scenario for HTTP looks like this (actual flow may vary):

* client
  * send ``HTTP GET /path``
* server
  * recv
  * verify_client_post_handshake
  * send HTTP Connection Upgrade (emits CertRequest message)
* client
  * recv
  * send upgrade confirmation (emits Certificate, CertificateVerify, Finish message)
* server
  * recv
  * verify certificate
  * send payload or error (may emit TLS alert for unknown, invalid, or missing cert)
* client
  * recv (receive TLS alert or server response)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Fri Sep 21 04:09:02 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 Sep 2018 08:09:02 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537517342.06.0.956365154283.issue34751@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/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 04:23:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 08:23:32 +0000
Subject: [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537518212.16.0.956365154283.issue29013@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This would look good too.

To be accurate, zipfile will create ZIP files that use the ZIP64 extensions when:

* It contains more than 65535 files.

* It is larger than 2 GiB. More accurate, when either the offset or the size of the central directory is larger than 2 GiB, so in theory it is possible to exceed the total size of 2 GiB without using ZIP64.

* The original size of any file is larger than 2 GiB.

I'm not sure we should describe the behavior in all details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29013>
_______________________________________

From report at bugs.python.org  Fri Sep 21 04:28:36 2018
From: report at bugs.python.org (Christoph Glaubitz)
Date: Fri, 21 Sep 2018 08:28:36 +0000
Subject: [issue34760] Regression in abc in combination with issubclass
Message-ID: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>


New submission from Christoph Glaubitz <chris+lp at chrigl.de>:

I'm not sure if this is a bug, or a known breaking change. I didn't find anything related in the changelog, except for a rewrite of abc. But hovever, I want this to be documented.

In 3.7.0:

import abc
def f():
    pass

class A(metaclass=abc.ABCMeta):
    pass

issubclass(f, A)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
TypeError: issubclass() arg 1 must be a class


python up to 3.6 (including 2.7) happily return false.

Found real world usage in osc-lib
* https://github.com/openstack/osc-lib/blob/46e2fb0a58fc06cfce1bb535f432405767d6b78b/osc_lib/utils/__init__.py#L495
* https://storyboard.openstack.org/#!/story/2003322

----------
messages: 325975
nosy: glaubich
priority: normal
severity: normal
status: open
title: Regression in abc in combination with issubclass
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 04:37:47 2018
From: report at bugs.python.org (Guillaume Dominici)
Date: Fri, 21 Sep 2018 08:37:47 +0000
Subject: [issue34761] str(super()) != super().__str__()
Message-ID: <1537519067.65.0.956365154283.issue34761@psf.upfronthosting.co.za>


New submission from Guillaume Dominici <guillaumedominici at gmail.com>:

The super proxy does not seem to forward call to .__str__() when the call occurs via str() function.
It may be an expected behavior, but it looks unexpected to me.

Minimal reproduction (tested on Python 3.6, but I believe may newer versions have similar behavior):

class Parent():
  def __str__(self):
    return "Parent"

class Child(Parent):
  def foo(self):
    s = super(Child, self)
    print(s.__str__())
    print(str(s))


c = Child()
c.foo()

# Output :
### Parent
### <super: <class 'Child'>, <Child object>>

----------
messages: 325976
nosy: Guillaume Dominici
priority: normal
severity: normal
status: open
title: str(super()) != super().__str__()
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34761>
_______________________________________

From report at bugs.python.org  Fri Sep 21 04:44:27 2018
From: report at bugs.python.org (Christoph Glaubitz)
Date: Fri, 21 Sep 2018 08:44:27 +0000
Subject: [issue34760] Regression in abc in combination with passing a function
 to issubclass
In-Reply-To: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>
Message-ID: <1537519467.4.0.956365154283.issue34760@psf.upfronthosting.co.za>


Christoph Glaubitz <chris+lp at chrigl.de> added the comment:

Maybe this is just how it should have been working the entire time, and osc is just holding it wrong.

Since:

class B:
    pass

issubclass(f, B)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class

... but:

issubclass(B, A)
False

----------
title: Regression in abc in combination with issubclass -> Regression in abc in combination with passing a function to issubclass

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:06:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 09:06:06 +0000
Subject: [issue34760] Regression in abc in combination with passing a function
 to issubclass
In-Reply-To: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>
Message-ID: <1537520766.97.0.956365154283.issue34760@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:14:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 09:14:09 +0000
Subject: [issue34761] str(super()) != super().__str__()
In-Reply-To: <1537519067.65.0.956365154283.issue34761@psf.upfronthosting.co.za>
Message-ID: <1537521249.11.0.956365154283.issue34761@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is an expected behavior.

>From https://docs.python.org/3/library/functions.html#super:

    Return a proxy object that delegates method calls to a parent or sibling class of type.

super() delegates explicit method calls. You shouldn't expect that it will delegate special methods called indirectly. For example, super() + 2 doesn't call super().__add__(2), and float(super()) doesn't call super().__float__().

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34761>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:15:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 09:15:07 +0000
Subject: [issue34755] Few minor optimizations in _asynciomodule.c
In-Reply-To: <1537462256.95.0.956365154283.issue34755@psf.upfronthosting.co.za>
Message-ID: <1537521307.0.0.956365154283.issue34755@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/issue34755>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:15:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 09:15:28 +0000
Subject: [issue34735] Modules/timemodule.c: Memory leak in time_strftime()
In-Reply-To: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>
Message-ID: <1537521328.99.0.956365154283.issue34735@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/issue34735>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:19:11 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 21 Sep 2018 09:19:11 +0000
Subject: [issue34760] Regression in abc in combination with passing a function
 to issubclass
In-Reply-To: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>
Message-ID: <1537521551.49.0.956365154283.issue34760@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This was a conscious decision (i.e we decided that the old inconsistency is a bug). See https://bugs.python.org/issue33018 for previous discussion. What is your use case? If it is critical, we can reconsider this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:22:26 2018
From: report at bugs.python.org (Monte Davidoff)
Date: Fri, 21 Sep 2018 09:22:26 +0000
Subject: [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537521746.66.0.956365154283.issue29013@psf.upfronthosting.co.za>


Monte Davidoff <md14-python at alluvialsw.com> added the comment:

I agree it may be better if we don't describe all the details of ZIP64. How about this rewording for the second change, so we don't have to give all the details?

(2) In the description of the zipfile.ZipFile class, change:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 4 GiB."

to:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when necessary, for example, when the zipfile is larger than 2 GiB."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29013>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:45:09 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 21 Sep 2018 09:45:09 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537523109.81.0.956365154283.issue34751@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/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 05:58:34 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 21 Sep 2018 09:58:34 +0000
Subject: [issue34760] Regression in abc in combination with passing a function
 to issubclass
In-Reply-To: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>
Message-ID: <1537523914.02.0.956365154283.issue34760@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/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 06:17:25 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 21 Sep 2018 10:17:25 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537525045.11.0.956365154283.issue34751@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with Raymond and Tim here: while it's inevitably true that there are many possible hash collisions, we'd need to see where the current algorithm caused real problems in real code. Pointing out a few examples where there was a collision isn't very helpful.

So, jdemeyer, if it's possible to show (or describe) to us an example of a problem you had, such that we could repeat it, that would be helpful (and necessary) to evaluate any proposed changes.  What were the inputs to hash() that caused a problem, and how did that problem manifest itself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 06:34:24 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 10:34:24 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537526064.48.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> So, jdemeyer, if it's possible to show (or describe) to us an example of a problem you had, such that we could repeat it, that would be helpful (and necessary) to evaluate any proposed changes.  What were the inputs to hash() that caused a problem, and how did that problem manifest itself?

In all honesty, I don't remember. This was a while ago and at that time I didn't care enough to put up a CPython bug report. Still, this is a collision for tuples of short length (3) containing small integers (0 and -2). Why do you find that contrived?

What prompted me to report this bug now anyway is that I discovered bad hashing practices for other classes too. For example, meth_hash in Objects/methodobject.c simply XORs two hashes and XOR tends to suffer from catastrophic cancellation. So I was hoping to fix tuple hashing as an example for other hash functions to follow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 06:47:25 2018
From: report at bugs.python.org (Christoph Glaubitz)
Date: Fri, 21 Sep 2018 10:47:25 +0000
Subject: [issue34760] Regression in abc in combination with passing a function
 to issubclass
In-Reply-To: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>
Message-ID: <1537526845.37.0.956365154283.issue34760@psf.upfronthosting.co.za>


Christoph Glaubitz <chris+lp at chrigl.de> added the comment:

I just realized this while trying to use the openstack command line tools on python3.7. After reading issue33018 and the fact that even in python2

class B:
    pass

def f():
    pass

issubclass(f, B)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class

... I am sure, the new behavior is the correct one. I would be totally fine with closing this issue, and hoping not too many code depend on the strange old behavior :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 06:52:49 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Sep 2018 10:52:49 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537527169.49.0.956365154283.issue34589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Correct - it won't change anything from 3.7.0, and even the original discrepancies relative to PEP 538 only affect applications that:

1. Are embedding a CPython runtime
2. *Aren't* already ensuring that they're running in a locale other than the C locale
3. Aren't able to set PYTHONCOERCECLOCALE=0 or LC_ALL=C in the environment prior to calling Py_Initialize() or Py_Main() in order to disable the locale coercion

(Because of the high quality of Victor's work on the UTF-8 mode implementation, it's practically impossible to externally distinguish between the behaviour of late coercion and the intended early coercion in the CPython CLI itself)

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Fri Sep 21 07:46:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 11:46:12 +0000
Subject: [issue27903] Avoid ResourceWarnings from platform._dist_try_harder
In-Reply-To: <1472591978.31.0.987771003839.issue27903@psf.upfronthosting.co.za>
Message-ID: <1537530372.24.0.956365154283.issue27903@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27903>
_______________________________________

From report at bugs.python.org  Fri Sep 21 07:53:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 11:53:34 +0000
Subject: [issue27121] imghdr does not support jpg files with Lavc bytes
In-Reply-To: <1464170447.09.0.218380322577.issue27121@psf.upfronthosting.co.za>
Message-ID: <1537530814.76.0.956365154283.issue27121@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27121>
_______________________________________

From report at bugs.python.org  Fri Sep 21 07:58:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 11:58:15 +0000
Subject: [issue26767] Inconsistant error messages for failed attribute
 modification
In-Reply-To: <1460715032.51.0.36886496046.issue26767@psf.upfronthosting.co.za>
Message-ID: <1537531095.91.0.956365154283.issue26767@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26767>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:16:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:16:19 +0000
Subject: [issue26452] Wrong line number attributed to comprehension expressions
In-Reply-To: <1456640149.75.0.85936592027.issue26452@psf.upfronthosting.co.za>
Message-ID: <1537532179.11.0.956365154283.issue26452@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think there have been some improvements merged with https://bugs.python.org/issue12458 . I am not sure if the patch covers more cases. I ran the tests attached in the patch and some of them cause RuntimeError in master.

# bpo26452.py

def f():
    return [j
            for i in range(3)
            if i]

f()

# Master 

./python.exe
Python 3.8.0a0 (heads/master:c510c6b8b6, Sep 21 2018, 11:10:24)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

./python.exe ../backups/bpo26452.py
Traceback (most recent call last):
  File "../backups/bpo26452.py", line 6, in <module>
    f()
  File "../backups/bpo26452.py", line 2, in f
    return [j
  File "../backups/bpo26452.py", line 2, in <listcomp>
    return [j
NameError: name 'j' is not defined


# Python 3.7

python3.7 ../backups/bpo26452.py
Traceback (most recent call last):
  File "../backups/bpo26452.py", line 6, in <module>
    f()
  File "../backups/bpo26452.py", line 3, in f
    for i in range(3)
  File "../backups/bpo26452.py", line 4, in <listcomp>
    if i]
NameError: name 'j' is not defined

# Tests

./python.exe ../backups/test26452.py
..F
======================================================================
FAIL: test_operators (__main__.TestPEP380Operation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/test26452.py", line 21, in expect_line
    f()
  File "../backups/test26452.py", line 98, in f
    -
RuntimeError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "../backups/test26452.py", line 100, in test_operators
    self.expect_line(f, 3) # want 2
  File "../backups/test26452.py", line 26, in expect_line
    self.assertEqual(relative_line, expected_relative_line)
AssertionError: 2 != 3

----------------------------------------------------------------------
Ran 3 tests in 0.001s

FAILED (failures=1)


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26452>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:19:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:19:17 +0000
Subject: [issue26495] super() does not work in nested functions, genexps,
 listcomps, and gives misleading exceptions
In-Reply-To: <1457290649.73.0.734693015263.issue26495@psf.upfronthosting.co.za>
Message-ID: <1537532357.8.0.956365154283.issue26495@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26495>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:23:36 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:23:36 +0000
Subject: [issue26214] textwrap should minimize number of breaks in extra long
 words
In-Reply-To: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>
Message-ID: <1537532616.75.0.956365154283.issue26214@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26214>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:36:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:36:58 +0000
Subject: [issue24997] mock.call_args compares as equal and not equal
In-Reply-To: <1441343319.6.0.391788581363.issue24997@psf.upfronthosting.co.za>
Message-ID: <1537533418.89.0.956365154283.issue24997@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems this is not reproducible at least on Python 3.6.4 and Master branch.

# bpo24997.py

from unittest.mock import *

m = Mock()
m(1,2)
m.call_args
print("1 ", m.call_args == call(1,2))
print("2 ", m.call_args != call(1,2))


# Master

./python.exe
Python 3.8.0a0 (heads/master:c510c6b8b6, Sep 21 2018, 11:10:24)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
./python.exe ../backups/bpo24997.py
1  True
2  False

# Python 3.6.4

python3.6 ../backups/bpo24997.py
1  True
2  False


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24997>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:37:44 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:37:44 +0000
Subject: [issue25240] Stack overflow in reprlib causes a core dump
In-Reply-To: <1443286078.54.0.18490843262.issue25240@psf.upfronthosting.co.za>
Message-ID: <1537533464.36.0.956365154283.issue25240@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25240>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:46:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:46:09 +0000
Subject: [issue24828] Segfault when using store-context AST node in a load
 context
In-Reply-To: <1439042614.34.0.045626812152.issue24828@psf.upfronthosting.co.za>
Message-ID: <1537533969.64.0.956365154283.issue24828@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the script. The crash is still reproducible as of now with at least python 2.7.14 . I need to check on the latest 2.7 branch yet.

On python 3 it produces an error as below : 

Traceback (most recent call last):
  File "../backups/bpo24828.py", line 6, in <module>
    code = compile(m, '', mode='exec')
ValueError: expression must have Load context but has Store instead

Crash report on Mac OS

MacOS/Python
Identifier:            Python
Version:               2.7.14 (2.7.14)
Code Type:             X86-64 (Native)
Parent Process:        zsh [13087]
Responsible:           iTerm2 [230]
User ID:               501

Date/Time:             2018-09-21 18:13:27.072 +0530
OS Version:            Mac OS X 10.10.4 (14E46)
Report Version:        11
Anonymous UUID:        BCB9DD4C-B310-CA87-7308-42F6715FDA83

Sleep/Wake UUID:       FA788657-D625-40D6-8701-16E042836F5F

Time Awake Since Boot: 24000 seconds
Time Since Wake:       14000 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 00000001075be000-00000001075c0000 [    8K] r-x/rwx SM=COW  /usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.python.python             	0x00000001075fc8bb dict_set_item_by_hash_or_entry + 14
1   org.python.python             	0x000000010764fa63 PyEval_EvalFrameEx + 14664
2   org.python.python             	0x000000010764bf29 PyEval_EvalCodeEx + 1583
3   org.python.python             	0x000000010764b8f4 PyEval_EvalCode + 54
4   org.python.python             	0x0000000107647fdc builtin_eval + 570
5   org.python.python             	0x00000001076527c8 PyEval_EvalFrameEx + 26285
6   org.python.python             	0x000000010764bf29 PyEval_EvalCodeEx + 1583
7   org.python.python             	0x000000010764b8f4 PyEval_EvalCode + 54
8   org.python.python             	0x000000010766f05d run_mod + 53
9   org.python.python             	0x000000010766f100 PyRun_FileExFlags + 133
10  org.python.python             	0x000000010766ec4f PyRun_SimpleFileExFlags + 698
11  org.python.python             	0x00000001076805f9 Py_Main + 3137
12  libdyld.dylib                 	0x00007fff9354a5c9 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0xc6079cb3d3de86bb  rbx: 0x00000001077d3168  rcx: 0x0000000000000000  rdx: 0xc6079cb3d3de86bb
  rdi: 0x00000001077d3168  rsi: 0x00000001078f4a08  rbp: 0x00007fff586410d0  rsp: 0x00007fff586410c0
   r8: 0x0000000000000000   r9: 0x0000000000000000  r10: 0x0000000000000001  r11: 0x000000000024e797
  r12: 0x0000000107871a00  r13: 0x0000000107871b70  r14: 0x0000000000000008  r15: 0x00000001078f4a08
  rip: 0x00000001075fc8bb  rfl: 0x0000000000010206  cr2: 0x0000000000000000


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24828>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:47:23 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 12:47:23 +0000
Subject: [issue25312] Cryptic error message if incorrect spec is set on a
 callable mock
In-Reply-To: <1443982028.68.0.922333733292.issue25312@psf.upfronthosting.co.za>
Message-ID: <1537534043.19.0.956365154283.issue25312@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25312>
_______________________________________

From report at bugs.python.org  Fri Sep 21 08:50:57 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 12:50:57 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537534257.58.0.956365154283.issue34751@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
keywords: +patch
pull_requests: +8884
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 09:18:29 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 13:18:29 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537535909.74.0.956365154283.issue34751@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/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 09:26:57 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Fri, 21 Sep 2018 13:26:57 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537536417.27.0.956365154283.issue34751@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
nosy: +sir-sigurd

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 10:22:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 14:22:05 +0000
Subject: [issue34589] Py_Initialize() and Py_Main() should not enable C locale
 coercion
In-Reply-To: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>
Message-ID: <1537539725.95.0.956365154283.issue34589@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34589>
_______________________________________

From report at bugs.python.org  Fri Sep 21 10:35:48 2018
From: report at bugs.python.org (Peter Ebden)
Date: Fri, 21 Sep 2018 14:35:48 +0000
Subject: [issue34722] Non-deterministic bytecode generation
In-Reply-To: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>
Message-ID: <1537540548.5.0.956365154283.issue34722@psf.upfronthosting.co.za>


Change by Peter Ebden <peter.ebden at gmail.com>:


----------
keywords: +patch
pull_requests: +8885
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34722>
_______________________________________

From report at bugs.python.org  Fri Sep 21 10:44:08 2018
From: report at bugs.python.org (=?utf-8?q?Vincent_Jug=C3=A9?=)
Date: Fri, 21 Sep 2018 14:44:08 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1537541048.22.0.956365154283.issue34561@psf.upfronthosting.co.za>


Vincent Jug? <vincent.juge at u-pem.fr> added the comment:

Dear all,

After me and my colleagues worked on the first paper you mention, I recently created another merge-based sorting algorithm, which I called "Adaptive Shivers Sort". This is a close variant of the Augmented Shivers Sort presented by Buss & Knop in their article
https://arxiv.org/abs/1801.04641

Like Munro & Wild's Powersort and Peeksort, this algorithm has an optimal worst-case running time (up to a linear additive constant) when measured with the merge cost model that is used in all the articles you cite in this discussion. It also maintains a stack of size log_2(n).
I could not prove such an optimality result for Buss & Knop Augmented Shivers Sort.

Custom tests that I had performed suggest that this algorithm is, in practice, as efficient as Munro & Wild's algorithms, and also does not suffer from critically bad cases.

Moreover, like Buss & Knop's 2-merge, and unlike Munro & Wild's Powersort and Peeksort, this algorithm has the advantage of having a structure that is very similar to that of Timsort, which may be an advantage in your situation.

That is why, upon reading your discussion, I refurbished my notes about Adaptive Shivers Sort, which you may find here:
http://igm.univ-mlv.fr/~juge/papers/shivers_arxiv.pdf

These notes include a description of the algorithm and a worst-time complexity analysis. If extending my analysis of this algorithm or investigating tuning details were of interest for you, I would be happy to help.

Best regards,

Vincent Jug?

----------
nosy: +vincent.juge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34561>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:06:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 15:06:32 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
Message-ID: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Unfortunately, the current C API for PEP 567 has a flaw: it uses non-PyObject pointers.  

This causes problems with integrating with tools like Cython, where PyObject is special and a lot of machinery recognizes it and manages refcounts correctly.

It also goes against the recent push to improve C API; one of the things we want to fix is to eliminate non-PyObject pointer types from public APIs entirely.

Because this C API is new (landed in 3.7.0) I think it might make sense to change it in 3.7.1.  I *think* this is a relatively safe (albeit annoying) change:

1. I don't expect that a lot of people use this new C API.  I googled recently if anyone uses contextvars at all, and found that some people are using the Python API.  The only user of C API that I'm aware of is uvloop, which I'll be happy to fix.

2. My current understanding is that this change won't break existing extensions compiled against Python 3.7.0, as it's just a change in pointers' types.

3. For example, clang spits out the following *warning* if it sees mismatched pointer types (and still compiles the extension):

   warning: incompatible pointer types passing 'PyContextVar *' (aka
      'struct _pycontextvarobject *') to parameter of type 'PyObject *' (aka 'struct _object *')
      [-Wincompatible-pointer-types]

4. This would make it slightly harder to create extension that supports both 3.7.0 and 3.7.1 and compiles without warnings.  (It's possible to avoid warnings by adding some #ifdefs macro).

If we don't change this API now, we'll likely have to either live with it, or face a very slow deprecation period.

----------
components: Interpreter Core
messages: 325989
nosy: ned.deily, yselivanov
priority: normal
severity: normal
status: open
title: Change contextvars C API to use PyObject
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:08:15 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 15:08:15 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537542495.96.0.956365154283.issue34762@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8886
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:13:45 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 15:13:45 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537542825.95.0.956365154283.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Just to add to this issue: I originally realized that something is wrong with the design when we had a super hard to track memory leak in uvloop, caused by Cython being unable to automatically manage increfs/decrefs for PyContext* pointers.  So I do believe this is a serious pitfall.

Adding Guido to the nosy list as he accepted the PEP and IMO still has a say in this.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:28:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 15:28:42 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537543722.87.0.956365154283.issue34762@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

IMHO it's not too late to change the public C API in Python 3.7.1, since it's a very new API, I don't expect many users, and I only expect compiler warnings nor hard error if existing code pass PyContextVar* instead of PyObject*.

I agree that it's way better to use PyObject* rather than specific PyContextVar*. The C API should not leak implementation details ;-)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:30:20 2018
From: report at bugs.python.org (=?utf-8?b?6I2J5pyo5bu6?=)
Date: Fri, 21 Sep 2018 15:30:20 +0000
Subject: [issue34763] Python lacks 0x4E17
Message-ID: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>


New submission from ??? <naruawaryousuke at gmail.com>:

This is very easy issue.

? meanning is 30.(? is 0x4E17)
"?".isnumeric() must returns true.
but "?".isnumeric()  returns  False.

----------
components: Unicode
messages: 325992
nosy: ezio.melotti, vstinner, ???
priority: normal
severity: normal
status: open
title: Python lacks 0x4E17
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:32:12 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Sep 2018 15:32:12 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537543722.87.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLig4ejH577f3V+kqjrqWBxHu3w__h2vmUFz-i-hVe5=A@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Let?s change it ASAP. It?s still up to Ned whether to hold up 3.7.1, if he
won?t it should go into 3.7.2.

On Fri, Sep 21, 2018 at 8:28 AM STINNER Victor <report at bugs.python.org>
wrote:

>
> STINNER Victor <vstinner at redhat.com> added the comment:
>
> IMHO it's not too late to change the public C API in Python 3.7.1, since
> it's a very new API, I don't expect many users, and I only expect compiler
> warnings nor hard error if existing code pass PyContextVar* instead of
> PyObject*.
>
> I agree that it's way better to use PyObject* rather than specific
> PyContextVar*. The C API should not leak implementation details ;-)
>
> ----------
> nosy: +vstinner
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34762>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:40:56 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 21 Sep 2018 15:40:56 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1537544456.38.0.956365154283.issue34750@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

The documentation for locals ( https://docs.python.org/3/library/functions.html#locals ) specifically states:

Note: The contents of this dictionary should not be modified; changes may not affect the values of local and free variables used by the interpreter. 

The docstring for locals is similar, making it clear that any correlation between the returned dict and the state of locals if *either* is subsequently modified is implementation dependent, subject to change without back-compat concerns; even if we made this change, we've given ourselves the freedom to undo it at any time, which makes it useless to anyone who might try to rely on it.

The fact that even locals()["a"] = 1 happens to work is an implementation detail AFAICT; normally, locals() is and should remain read-only (or at least, modifications don't actually affect the local scope aside from the dict returned by locals()).

I'm worried that making _EnumDict inherit from collections.abc.MutableMapping in general would slow down Enums (at the very least creation, I'm not clear on whether _EnumDict remains, hidden behind the mappingproxy, for future lookups on the class), since MutableMapping would introduce a Python layer of overhead to most calls.

I'm also just not inclined to encourage the common assumption that locals() returns a dict where mutating it actually works, since it usually doesn't.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:41:31 2018
From: report at bugs.python.org (ChrisRands)
Date: Fri, 21 Sep 2018 15:41:31 +0000
Subject: [issue34764] Improve documentation example for using iter() with
 sentinel value
Message-ID: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>


New submission from ChrisRands <chrisrands0 at gmail.com>:

This arose from this SO question: https://stackoverflow.com/questions/52446415/line-in-iterfp-readline-rather-than-line-in-fp 

The example given in the docs:

with open('mydata.txt') as fp:
    for line in iter(fp.readline, ''):
        process_line(line)

Is exactly equivalent to the following because an empty string is only returned by readline at the EOF:

with open('mydata.txt') as fp:
    for line in fp:
        process_line(line)

The empty string '' sentinel value could be changed to another value to provide a possibly more meaningful example where the 2nd code snippet would not always produce the same result?

----------
assignee: docs at python
components: Documentation
messages: 325995
nosy: ChrisRands, docs at python
priority: normal
severity: normal
status: open
title: Improve documentation example for using iter() with sentinel value

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34764>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:47:07 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Fri, 21 Sep 2018 15:47:07 +0000
Subject: [issue34765] Update install-sh
Message-ID: <1537544827.56.0.956365154283.issue34765@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

The install-sh file that python uses for autotools is horribly outdated. Last update was 16 years ago and it's being copied from automake's source code.

Updating it to modern standards could potentially fix issues for systems that use autotools, but it has the downside of having some backwards incompatible changes e.g. [0][1] (or you can search at their NEWS file [2]) which could break some previous applied workarounds.

As things stand, there is no bug at the moment and autotools just work so would a PR for updating install-sh to a newer version be considered? 

[0] http://git.savannah.gnu.org/cgit/automake.git/commit/lib/install-sh?id=84a98180dd37a32891800fb9aafdf685bab74252
[1] http://git.savannah.gnu.org/cgit/automake.git/commit/lib/install-sh?id=bd44db1abdeea3643ba0387de24af7539da644e4
[2] http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS

----------
components: Build
messages: 325996
nosy: cstratak
priority: normal
severity: normal
status: open
title: Update install-sh
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34765>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:48:45 2018
From: report at bugs.python.org (Yongnan Wu)
Date: Fri, 21 Sep 2018 15:48:45 +0000
Subject: [issue34766] BaseProxy cache should be cleaned when Manager client is
 reconnected
Message-ID: <1537544925.1.0.956365154283.issue34766@psf.upfronthosting.co.za>


Change by Yongnan Wu <wynfred at yeah.net>:


----------
components: Library (Lib)
nosy: wynfred
priority: normal
severity: normal
status: open
title: BaseProxy cache should be cleaned when Manager client is reconnected
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34766>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:54:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 15:54:44 +0000
Subject: [issue34767] Optimize asyncio.Lock
Message-ID: <1537545284.93.0.956365154283.issue34767@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

There's no point in always creating a deque() for waiters in Lock.__init__.  Not all locks end up using waiters.

----------
components: asyncio
messages: 325997
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Optimize asyncio.Lock
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34767>
_______________________________________

From report at bugs.python.org  Fri Sep 21 11:59:53 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Sep 2018 15:59:53 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537545593.14.0.956365154283.issue34763@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8887
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:06:25 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 21 Sep 2018 16:06:25 +0000
Subject: [issue34765] Update install-sh
In-Reply-To: <1537544827.56.0.956365154283.issue34765@psf.upfronthosting.co.za>
Message-ID: <1537545985.24.0.956365154283.issue34765@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

If there's no actual bug, it certainly does not need to be done on maintenance branches.

----------
nosy: +zach.ware
versions:  -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34765>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:21:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Sep 2018 16:21:43 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537546903.13.0.956365154283.issue34762@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur that the sooner the change is applied, the better it will be for everyone.  We'll need to make a prominent notice in the release notes though.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:23:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 16:23:08 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537546988.07.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8888

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:24:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 16:24:56 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537547096.73.0.956365154283.issue34762@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> We'll need to make a prominent notice in the release notes though.

Something can be added at:
https://docs.python.org/dev/whatsnew/3.7.html#notable-changes-in-python-3-7-1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:27:15 2018
From: report at bugs.python.org (Antony Lee)
Date: Fri, 21 Sep 2018 16:27:15 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1537547235.92.0.956365154283.issue34750@psf.upfronthosting.co.za>


Antony Lee <anntzer.lee at gmail.com> added the comment:

> encourage the common assumption that locals() returns a dict where mutating it actually works, since it usually doesn't.

It does at global and class scope, not at function scope.

FWIW, PEP558 (admittedly not accepted yet) proposes to modify the documentation for the semantics of locals() at class-scope to match the actual behavior (https://www.python.org/dev/peps/pep-0558/#class-scope):

    At class scope [...] changes to the returned mapping must change the values bound to local variable names in the execution environment.

> I'm worried that making _EnumDict inherit from collections.abc.MutableMapping in general would slow down Enums (at the very least creation, I'm not clear on whether _EnumDict remains, hidden behind the mappingproxy, for future lookups on the class), since MutableMapping would introduce a Python layer of overhead to most calls.

"Normal" calls won't: __setitem__ / __getitem__ stays what they are, they were implemented in Python and stay implemented in Python.  Whoever calls update() will go through an extra Python layer, but there's not much you can do about that.

Alternatively, if you *really* don't want to support the MutableMapping API, at least it should be disabled (e.g. by adding stub implementations of update(), etc. that throw NotImplementedError).  Again performance-wise this would only affect those who try to call these methods.

As a side note, I would be curious to see any realistic code where the performance of enum creation turns out to be critical.  I don't think(?) the _EnumDict stays afterwards, at least PEP558 (which supposedly corresponds to the actual current behavior) also states "The mapping returned by locals() will not be used as the actual class namespace underlying the defined class (the class creation process will copy the contents to a fresh dictionary that is only accessible by going through the class machinery)."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:28:07 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 16:28:07 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537547287.1.0.956365154283.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

>> We'll need to make a prominent notice in the release notes though.

> Something can be added at:
https://docs.python.org/dev/whatsnew/3.7.html#notable-changes-in-python-3-7-1

Yeah, thank you for suggestion, I'll do that.  I'll also update the PEP, docs in other places, and try to spread the word.

Now I'm just waiting for Ned to confirm if this goes into 3.7.1 or 3.7.2.  It's his say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:32:24 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 21 Sep 2018 16:32:24 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537547544.45.0.956365154283.issue34762@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> one of the things we want to fix is to eliminate non-PyObject
> pointer types from public APIs entirely.

A notable exception is Py_buffer. [1]  As well, cross-interpreter data must not be PyObject, though that isn't much of an issue (yet). :)  At some point it may make sense to make _PyCrossInterpreterData [2] part of the public C-API.  However, we can cross *that* bridge later. :)

Using PyObject for contextvars makes sense (for the reasons you described) as long as they won't be shared between interpreters.  I'm not super familiar with the contextvars C-API, but it looks like cross-interpreter issues are *not* a factor.  If that's the case then there's nothing further to discuss. :)

[1] https://docs.python.org/3/c-api/buffer.html#buffer-structure
[2] https://github.com/python/cpython/blob/master/Include/internal/pystate.h#L137

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:37:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 16:37:21 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537547841.3.0.956365154283.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> > one of the things we want to fix is to eliminate non-PyObject
> pointer types from public APIs entirely.

> A notable exception is Py_buffer. [1]

Right, because Py_buffer isn't a PyObject at all :)

> Using PyObject for contextvars makes sense (for the reasons you described) as long as they won't be shared between interpreters.

Yeah, PyContext, PyContextVar, and PyContextToken aren't supposed to be shared between sub-interpreters directly.  Context is essentially a mapping of Context Variables to arbitrary Python Objects, so sharing it transparently isn't possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:38:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 16:38:05 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537547885.43.0.956365154283.issue34763@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:39:54 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 21 Sep 2018 16:39:54 +0000
Subject: [issue34760] Regression in abc in combination with passing a function
 to issubclass
In-Reply-To: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>
Message-ID: <1537547994.96.0.956365154283.issue34760@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

OK, lets close this for now. We will see if there are any other situations.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34760>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:40:09 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 21 Sep 2018 16:40:09 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537548009.53.0.956365154283.issue32892@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

As someone who does AST manipulation (Quixote PTL template support), I'm interested in this patch. I think what is proposed sounds like a good change.  I.e. having the extra node types is not useful and makes the compiler harder to understand.  Providing subclasses for backwards compatibility would be nice.  I will test my Quixote package with Serhiy's patch.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:41:56 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 21 Sep 2018 16:41:56 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537548116.75.0.956365154283.issue34762@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> because Py_buffer isn't a PyObject at all :)

It owns a PyObject reference to the buffer owner, though.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 12:55:17 2018
From: report at bugs.python.org (Yongnan Wu)
Date: Fri, 21 Sep 2018 16:55:17 +0000
Subject: [issue34766] BaseProxy cache should be cleaned when Manager client is
 reconnected
Message-ID: <1537548917.32.0.956365154283.issue34766@psf.upfronthosting.co.za>


Change by Yongnan Wu <wynfred at yeah.net>:


----------
keywords: +patch
pull_requests: +8889
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34766>
_______________________________________

From report at bugs.python.org  Fri Sep 21 13:08:57 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 21 Sep 2018 17:08:57 +0000
Subject: [issue34761] str(super()) != super().__str__()
In-Reply-To: <1537519067.65.0.956365154283.issue34761@psf.upfronthosting.co.za>
Message-ID: <1537549737.42.0.956365154283.issue34761@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

As Serhiy said, this is the correct behavior.  Nearly all builtin operations are made using the appropriate "dunder" method from the object's type (not looked up on the object itself).  So the following (based on your example) are equivalent:

  s = super(Child, self)
  print(type(s).__str__(s))
  print(str(s))

In contrast, explicitly calling __str__() on the instance involves lookup there, so the following are equivalent:

  s = super(Child, self)
  print(s.__str__())
  print(type(s).__getattribute__(s, '__str__')())

You can read more about "dunder" (AKA "special") methods and how they are looked up in the docs. [1][2][3]

I'm going to close this issue, but if you think there's anything further we can do in the documentation to avoid confusion then please let us know.


[1] https://docs.python.org/3/reference/datamodel.html#special-lookup
[2] https://docs.python.org/3/reference/datamodel.html#special-method-names
[3] https://docs.python.org/3/library/inspect.html#fetching-attributes-statically

----------
nosy: +eric.snow
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34761>
_______________________________________

From report at bugs.python.org  Fri Sep 21 13:32:27 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 17:32:27 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537551147.96.0.956365154283.issue34762@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Since we've already delayed 3.7.1rc cutoff for a few days, let's get it into 3.7.1 if you have the time, Yury.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 13:42:35 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 21 Sep 2018 17:42:35 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537547885.45.0.249678724859.issue34763@psf.upfronthosting.co.za>
Message-ID: <CC643227-DF72-47F2-8C62-B89960A57157@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

We use the Unicode database for these methods. Could you please check whether the database marks the character as numeric ?

If yes, we may need to check the database generation.

Otherwise, there isn't much we can do, since we use the Unicode database as reference.

Thanks
-- 
Marc-Andre Lemburg

Sent from my phone. 
See http://www.egenix.com/company/ for contact information
and impressum.

On 21 September 2018 18:38:05 GMT+02:00, Serhiy Storchaka <report at bugs.python.org> wrote:
> 
> Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:
> 
> 
> ----------
> nosy: +lemburg
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34763>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:00:48 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 21 Sep 2018 18:00:48 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537552848.58.0.956365154283.issue34763@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Unicode 11.0.0 has ? (U+5345) as being numeric and having the value 30.

What's the difference between that and U+4E17?

I notice that they look at lot alike. Are they different variants, perhaps traditional vs simplified?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:07:11 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 21 Sep 2018 18:07:11 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537553231.96.0.956365154283.issue34763@psf.upfronthosting.co.za>


Change by Matthew Barnett <python at mrabarnett.plus.com>:


----------
Removed message: https://bugs.python.org/msg326015

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:07:30 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 21 Sep 2018 18:07:30 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537553250.0.0.956365154283.issue34763@psf.upfronthosting.co.za>


Change by Matthew Barnett <python at mrabarnett.plus.com>:


----------
Removed message: https://bugs.python.org/msg326014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:07:39 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 21 Sep 2018 18:07:39 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537553259.28.0.956365154283.issue34763@psf.upfronthosting.co.za>


Change by Matthew Barnett <python at mrabarnett.plus.com>:


----------
Removed message: https://bugs.python.org/msg326013

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:07:47 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 21 Sep 2018 18:07:47 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537553267.88.0.956365154283.issue34763@psf.upfronthosting.co.za>


Change by Matthew Barnett <python at mrabarnett.plus.com>:


----------
Removed message: https://bugs.python.org/msg326012

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:46:14 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 18:46:14 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537555574.71.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I should also make it clear that the collision hash((1,0,0)) == hash((1,-2,-2)) that I reported is due to the algorithm, it's not due to some bad luck that 2 numbers happen to be the same. There are also many more similar hash collisions for tuples (all involving negative numbers) due to the same underlying mathematical reason.

I still don't understand why you don't consider it a problem. It may be a tiny problem, not really affecting the correct functioning of CPython. But, if we can fix this tiny problem, why shouldn't we?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 14:56:18 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Sep 2018 18:56:18 +0000
Subject: [issue34764] Improve documentation example for using iter() with
 sentinel value
In-Reply-To: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>
Message-ID: <1537556178.97.0.956365154283.issue34764@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur that the readline() example is problematic.  While it succeeds in showing how iter() works, the example itself is not the best way to solve that particular problem.

Here are two possible substitute examples.

1) Simple example that focuses primarily on the behavior of iter() and required little extra knowledge:


    >>> from random import randint
    >>> def roll_dice():
            return randint(1, 6) + randint(1, 6)

    >>> # roll until a seven is seen
    >>> list(iter(roll_dice, 7))
    >>> list(iter(roll_dice, 7))
    [10, 6, 5, 6, 8]

2) Practical application reading binary files in fixed-width blocks for processing with the structure module.  This also teaches how to partial() to produce an arity-zero callable suitable for use with iter().

    >>> Read fixed-width blocks from a database binary file
    >>> from functools import partial
    >>> with open('mydata.db', 'rb') as f:
    	    for block in iter(partial(f.read, 64)):
		print(parse_struct(block))

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34764>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:01:35 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 21 Sep 2018 19:01:35 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537556495.03.0.956365154283.issue34751@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not one to judge the effectiveness of a new hash algorithm. But my personal concern here is making something else worse: an unintended consequence. IMO the bar for changing this would be very high, and at the least it would need to be addressing a known, not theoretical, problem.

That said, I'll let the experts debate your proposed change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:16:50 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Sep 2018 19:16:50 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537557410.04.0.956365154283.issue34623@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

CVE-2018-14647 was assigned to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:26:19 2018
From: report at bugs.python.org (Benito Kestelman)
Date: Fri, 21 Sep 2018 19:26:19 +0000
Subject: [issue34768] Add documentation for the purpose of __init__.py in
 packages
Message-ID: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>


New submission from Benito Kestelman <beni.kestel001 at gmail.com>:

I just learned how to make my own package in python and upload it to pypi. I mainly used the documentation here: https://packaging.python.org/tutorials/packaging-projects/

Other than the toy example, there is no explanation of __init__.py, its purpose, or what I should put in it to get my code to work. 

It took me a lot of time and guessing to figure it out, and I had to look at several projects on Github to see how others did it. I found a couple that looked correct because they were concise, but others looked horrendous - one was several thousand lines long. 

A clear explanation of how to use __init__.py when making a package would be extremely helpful.

----------
assignee: docs at python
components: Documentation
messages: 326020
nosy: bkestelman, docs at python
priority: normal
severity: normal
status: open
title: Add documentation for the purpose of __init__.py in packages

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34768>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:26:57 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Sep 2018 19:26:57 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537558017.64.0.956365154283.issue34751@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

ISTM the collision of "hash((1,0,0)) == hash((1,-2,-2))" also stems from integers hashing to themselves and that twos-complement arithmetic relation, -x == ~x+1.  Further, that example specifically exploits that "hash(-1) == hash(-2)" due to how error codes.  In a way, tuple hashing is incidental.

Occasional collisions aren't really a big deal -- it is normal for dicts to have some collisions and to resolve them.  I would be more concerned is non-contrived datasets had many elements that gave exactly the same hash value resulting in a pile-up in one place.

FWIW, the current algorithm also has some advantages that we don't want to lose. In particular, the combination of the int hash and tuple hash are good at producing distinct values for non-negative numbers:

    >>> from itertools import product
    >>> len(set(map(hash, product(range(100), repeat=4))))
    100000000

The current hash is in the pretty-darned-good category and so we should be disinclined to change battle-tested code that is known to work well across a broad range of use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:34:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 19:34:02 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537558442.23.0.956365154283.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 2ec872b31e25cee1f983fe07991fb53f3fd1cbac by Yury Selivanov in branch 'master':
bpo-34762: Fix contextvars C API to use PyObject* pointer types. (GH-9473)
https://github.com/python/cpython/commit/2ec872b31e25cee1f983fe07991fb53f3fd1cbac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:34:26 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 19:34:26 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537558466.43.0.956365154283.issue34762@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8890

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:38:50 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 19:38:50 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537558730.33.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Further, that example specifically exploits that "hash(-1) == hash(-2)"

No, it does not. There is no hashing of -1 involved in the example hash((1,0,0)) == hash((1,-2,-2)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:44:24 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 19:44:24 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537559064.0.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

For me, it's largely because you make raw assertions with extreme confidence that the first thing you think of off the top of your head can't possibly make anything else worse.  When it turns out it does make some things worse, you're equally confident that the second thing you think of is (also) perfect.

So far we don't even have a real-world test case, let alone a coherent characterization of "the problem":

"""
all involving negative numbers) due to the same underlying mathematical reason.
"""

is a raw assertion, not a characterization.  The only "mathematical reason" you gave before is that "j odd implies j^(-2) == -j, so that m*(j^(-2)) == -m".  Which is true, and a good observation, but doesn't generalize as-is beyond -2.

Stuff like this from the PR doesn't inspire confidence either:

"""
MULTIPLIER = (1000003)**3 + 2 = 1000009000027000029: the multiplier should be big enough and the original 20-bit number is too small for a 64-bit hash. So I took the third power. Unfortunately, this caused a sporadic failure of the testsuite on 32-bit systems. So I added 2 which solved that problem.
"""

Why do you claim the original was "too small"?  Too small for what purpose?  As before, we don't care whether Python hashes "act random".  Why, when raising it to the third power apparently didn't work, did you pull "2" out of a hat?  What was _the cause_ of the "sporadic failure" (whatever that means), and why did adding 2 fix it?  Why isn't there a single word in _the code_ about where the mystery numbers came from?:

You're creating at least as many mysteries as you're claiming to solve.

We're not going to change such heavily used code on a whim.

That said, you could have easily enough _demonstrated_ that there's potentially a real problem with a mix of small integers of both signs:

>>> from itertools import product
>>> cands = list(range(-10, -1)) + list(range(9))
>>> len(cands)
18
>>> _ ** 4
104976
>>> len(set(hash(t) for t in product(cands, repeat=4)))
35380

And that this isn't limited to -2 being in the mix (and noting that -1 wasn't in the mix to begin with):

>>> cands.remove(-2)
>>> len(cands) ** 4
83521
>>> len(set(hash(t) for t in product(cands, repeat=4)))
33323

If that's "the problem", then - sure - it _may_ be worth addressing.  Which we would normally do by looking for a minimal change to code that's been working well for over a decade, not by replacing the whole thing "just because".

BTW, continuing the last example:

>>> c1 = Counter(hash(t) for t in product(cands, repeat=4))
>>> Counter(c1.values())
Counter({1: 11539, 2: 10964, 4: 5332, 3: 2370, 8: 1576, 6: 1298, 5: 244})

So despite that there were many collisions, the max number of times any single hash code appeared was 8.  That's unfortunate, but not catastrophic.

Still, if a small change could repair that, fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:48:15 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 19:48:15 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537559295.64.0.956365154283.issue34762@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 187f2dd256a917c20bf55954d019fd35fb46ab08 by Miss Islington (bot) in branch '3.7':
bpo-34762: Fix contextvars C API to use PyObject* pointer types. (GH-9473)
https://github.com/python/cpython/commit/187f2dd256a917c20bf55954d019fd35fb46ab08


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:48:57 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 19:48:57 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537559337.51.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Oops!

"""
"j odd implies j^(-2) == -j, so that m*(j^(-2)) == -m"
"""

The tail end should say "m*(j^(-2)) == -m*j" instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:49:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 19:49:37 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537559377.4.0.956365154283.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

PEP update: https://github.com/python/peps/commit/977a94d1a79b71336568119eb689b277d2ffec80

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 15:50:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 19:50:34 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1537559434.47.0.956365154283.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Fixed in master and 3.7.  Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:07:12 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 20:07:12 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537560432.86.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> FWIW, the current algorithm also has some advantages that we don't want to lose. In particular, the combination of the int hash and tuple hash are good at producing distinct values for non-negative numbers:

    >>> from itertools import product
    >>> len(set(map(hash, product(range(100), repeat=4))))
    100000000

FWIW: the same is true for my new hash function

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:16:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 20:16:53 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537561013.66.0.956365154283.issue32892@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum, I'm not sure that I understood correctly: does "isinstance(node, ast.Num)" still work with the patch? If yes, I see no reason to not merge the change ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:23:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 20:23:19 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537561399.63.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset db1a80e97aa7217c561fb3627f70be1882de9534 by Yury Selivanov in branch 'master':
bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475)
https://github.com/python/cpython/commit/db1a80e97aa7217c561fb3627f70be1882de9534


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:23:26 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 20:23:26 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537561406.07.0.956365154283.issue33649@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8891

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:25:11 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:25:11 +0000
Subject: [issue34267] find_python.bat doesn't find installed Python 3.7
In-Reply-To: <1532820797.37.0.56676864532.issue34267@psf.upfronthosting.co.za>
Message-ID: <1537561511.26.0.956365154283.issue34267@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34267>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:27:56 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 20:27:56 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537561676.26.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Concerning the MULTIPLIER:

> Why do you claim the original was "too small"?  Too small for what purpose?

If the multiplier is too small, then the resulting hash values are small too. This causes collisions to appear for smaller numbers:

BEFORE:
>>> L = [(a,b) for a in range(2) for b in range(2**21)]
>>> len(L), len(set(hash(x) for x in L))
(4194304, 2097152)

AFTER:
>>> L = [(a,b) for a in range(2) for b in range(2**21)]
>>> len(L), len(set(hash(x) for x in L))
(4194304, 4194304)

Again, not a huge problem, but at least there is room for improvement.

> Why, when raising it to the third power apparently didn't work, did you pull "2" out of a hat?  What was _the cause_ of the "sporadic failure" (whatever that means)

With "sporadic failure", I mean a hash collision not due to the algorithm but due to two numbers which happen to be the same. This might not even affect actual usage, but it did cause the testsuite to fail on 32 bit machines (48 collisions if I recall correctly while only 20 are allowed).

> and why did adding 2 fix it?

Because it's really just random chance. Some constants just happen to produce more collisions on the specific testsuite input. It should also be said that, due to the structure of that input, collisions are not independent. For example, if hash((a,b,c)) == hash((d,e,f)), then also hash((a,b,c,x)) == hash((d,e,f,x)) for example.

> Why isn't there a single word in _the code_ about where the mystery numbers came from?

Ideally, it should be just a random number. I can fix that by using a "Nothing up my sleeve number".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:33:31 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:33:31 +0000
Subject: [issue33782] VSTS Windows-PR: internal error
In-Reply-To: <1528283564.84.0.592728768989.issue33782@psf.upfronthosting.co.za>
Message-ID: <1537562011.5.0.956365154283.issue33782@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33782>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:35:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 20:35:37 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537562137.48.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset e45662c28bfc84aa3674463a2995e45da4d63793 by Yury Selivanov (Miss Islington (bot)) in branch '3.7':
bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475) (GH-9481)
https://github.com/python/cpython/commit/e45662c28bfc84aa3674463a2995e45da4d63793


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:37:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 20:37:04 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537562224.15.0.956365154283.issue34763@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

$ ./python
Python 3.8.0a0 (heads/master-dirty:06e7608207, Sep 20 2018, 01:52:01) 
>>> import unicodedata
>>> unicodedata.unidata_version
'11.0.0'
>>> unicodedata.numeric('\u5345')
30.0
>>> unicodedata.numeric('\u4E17')
ValueError: not a numeric character

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:44:31 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:44:31 +0000
Subject: [issue34725] Py_GetProgramFullPath() odd behaviour in Windows
In-Reply-To: <1537291607.58.0.956365154283.issue34725@psf.upfronthosting.co.za>
Message-ID: <1537562671.38.0.956365154283.issue34725@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I meant returning the full name of the process is intentional. But you're right that overriding it should actually override it.

I found the prior bug at issue33180, but I'm closing it in favour of this one. I don't have fully fleshed out semantics in my mind for all the cases to handle here, but I hope that we soon reach a point of drastically simplifying getpath and can align the platforms better at that point.

Meanwhile I'll leave this open in case anyone wants to work on a targeted fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34725>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:44:42 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:44:42 +0000
Subject: [issue33180] Flag for unusable sys.executable
In-Reply-To: <1522335211.5.0.467229070634.issue33180@psf.upfronthosting.co.za>
Message-ID: <1537562682.32.0.956365154283.issue33180@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Closing in favour of issue34725

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33180>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:46:11 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:46:11 +0000
Subject: [issue32282] When using a Windows XP compatible toolset,
 `socketmodule.c` fails to build
In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za>
Message-ID: <1537562771.44.0.956365154283.issue32282@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I'm going to just close this without fixing 3.5. If there's demand, we can consider it, but at this stage it's so easy for people to migrate to 3.6 or later that I'm sure that's already been done.

----------
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32282>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:46:32 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:46:32 +0000
Subject: [issue32556] support bytes paths in nt _getdiskusage,
 _getvolumepathname, and _getfinalpathname
In-Reply-To: <1516029730.24.0.467229070634.issue32556@psf.upfronthosting.co.za>
Message-ID: <1537562792.13.0.956365154283.issue32556@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32556>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:47:00 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:47:00 +0000
Subject: [issue33016] nt._getfinalpathname may use uninitialized memory
In-Reply-To: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
Message-ID: <1537562820.15.0.956365154283.issue33016@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33016>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:47:55 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:47:55 +0000
Subject: [issue32533] SSLSocket read/write thread-unsafety
In-Reply-To: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>
Message-ID: <1537562875.68.0.956365154283.issue32533@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Fixed, with a fix for the regression coming in issue34759

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:48:13 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:48:13 +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: <1537562893.24.0.956365154283.issue33091@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> SSLSocket read/write thread-unsafety

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33091>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:48:47 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Sep 2018 20:48:47 +0000
Subject: [issue21983] segfault in ctypes.cast
In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>
Message-ID: <1537562927.9.0.956365154283.issue21983@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Still needs a backport to 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21983>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:51:15 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 21 Sep 2018 20:51:15 +0000
Subject: [issue34700] typing.get_type_hints doesn't know about typeshed
In-Reply-To: <1537042200.54.0.956365154283.issue34700@psf.upfronthosting.co.za>
Message-ID: <1537563075.53.0.956365154283.issue34700@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I think there is also a fourth option: add a flag to `get_type_hints()` that will guard evaluation of forward references, as proposed in https://github.com/python/typing/issues/508. If the evaluation of a "forward reference" raises an error, then we keep it unevaluated (i.e. a string).

----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34700>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:51:57 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Sep 2018 20:51:57 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537563117.95.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8892

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Fri Sep 21 16:59:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 20:59:34 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537563574.27.0.956365154283.issue32892@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Can you describe what usages of the old API will continue to work, and what part will break?

Very good question!

What will continue to work:

* Instantiating. Both `Num(42)` and `Num(n=42)` will continue to work, but they will return an instance of Constant: Constant(value=42).

* Attribute access. Constant will get attributes "n" and "s" as aliases to the attribute "value". So Num(42).n will continue to return 42. 

* isinstance() check. Although `isinstance(Num(42), Num)` will continue to return True, and `isinstance(Str('42'), Num)` will continue to return False. Also `isinstance(Constant(42), Num)` will return True and `isinstance(Constant('42'), Num)` will return False.

* Subclassing. Subclasses of these classes will continue to behave as normal classes. Instantiating them will return instances of that classes, not Constant, and the isinstance() check will not have any magic.

What will no longer work:

* issubclass() check and exact type check. `issubclass(type(node), Num)` and `type(node) is Num` will return False for node = Num(42). But seems isinstance() is a more common way of checking the type of a node.

* If the user of NodeVisitor implemented visit_Num(), but not implemented visit_Constant(), his handler will not be triggered. This can be easily fixed by implementing visit_Constant(). Constant was introduced in 3.6.

* isinstance() check for underinitialized node. `isinstance(Num(), Num)` will return False.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:02:13 2018
From: report at bugs.python.org (Mario)
Date: Fri, 21 Sep 2018 21:02:13 +0000
Subject: [issue34725] Py_GetProgramFullPath() odd behaviour in Windows
In-Reply-To: <1537562671.38.0.956365154283.issue34725@psf.upfronthosting.co.za>
Message-ID: <10d64414-7ad0-b4dc-f5b1-d290e0494dd6@gmail.com>


Mario <mariofutire at gmail.com> added the comment:

On 21/09/2018 21:44, Steve Dower wrote:
> 
> Steve Dower <steve.dower at python.org> added the comment:
> 
> I meant returning the full name of the process is intentional. But you're right that overriding it should actually override it.
> 
> I found the prior bug at issue33180, but I'm closing it in favour of this one. I don't have fully fleshed out semantics in my mind for all the cases to handle here, but I hope that we soon reach a point of drastically simplifying getpath and can align the platforms better at that point.
> 
> Meanwhile I'll leave this open in case anyone wants to work on a targeted fix.
> 

So you are saying that the Windows behaviour (+ ability to overwrite) is intentional.
This looks to me in contrast to what the doc says under 
https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath.

Moreover I am not sure what Py_SetProgramName() is meant to do then.

The problem in my opinion is that we are trying to fit 2 things in the same field: the real 
executable name and the root of the python installation (which could be a virtual environment as well).
In python.exe the 2 are the same (or linked), but for embedded applications they are not.

Remember that site.py uses the sys.executable as "root of the python installation" to derive the 
path and handle virtual environments.

I think that if these 2 concepts were separated, it would be much easier to explain the desired 
behaviour and find a valid implementation in Window and Linux.

Let's say sys.executable is the full name of the process and sys.python_root is the folder from 
which to derive all the paths.

It is probably too big of a change, but it might be useful to write down the ideal behaviour before 
thinking of a pragmatic solution.

Andrea

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34725>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:15:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 21:15:17 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537564517.27.0.956365154283.issue32892@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> * If the user of NodeVisitor implemented visit_Num(), but not implemented visit_Constant(), his handler will not be triggered. This can be easily fixed by implementing visit_Constant(). Constant was introduced in 3.6.

IHMO that's an acceptable tradeoff. We should just make sure that it's properly documented in the Porting section of What's New in Python 3.8.

> * issubclass() check and exact type check. `issubclass(type(node), Num)` and `type(node) is Num` will return False for node = Num(42). But seems isinstance() is a more common way of checking the type of a node.

In the AST code that I read, isinstance() was the most popular way to check the type of a node. I don't recall any AST code using issubclass.

> isinstance() check for underinitialized node. `isinstance(Num(), Num)` will return False.

I don't think that it's an issue. 

--

In term of optimization, I'm curious, do you know if your PR optimize more cases than previously? Or do you expect futher optimizations later thanks to this change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:26:46 2018
From: report at bugs.python.org (Dan Snider)
Date: Fri, 21 Sep 2018 21:26:46 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1537565206.14.0.956365154283.issue34750@psf.upfronthosting.co.za>


Dan Snider <mr.assume.away at gmail.com> added the comment:

It's working as intended. locals() and vars() simply returns the current frame's f_locals. In functions, modifying this usually accomplishes nothing useful because the code object has OPTIMIZED and NEWLOCALS flags set, meaning local variables are looked up or set via the LOAD_FAST and STORE_FAST opcodes (respectively) which doesn't even look in the f_locals mapping. In this case, vars() and locals() will build a new dict[*] and fill it with the frame's fastlocals and unpack any closure cells into it.

The code object used for class bodies however is special and actually *does* use the mapping in f_locals, which for for classes ultimately built by builtins.__build_class__ (aka classes built with a `class` statement) will be whatever the metaclass's __prepare__ returns, which in the case of enums is an enum._EnumDict instance. 

So that's why metaclasses are so powerful. You don't even need to use a dictionary subclass as the class namespace, since the STORE_NAME opcode will use PyObject_SetItem; however type.__new__ will make you cast it to a dict, and even the dict that is wrapped by a MappingProxy after the class has been created will be a copy anyway. 

So anyway, there's nothing actually wrong with the current behavior. dict.update never calls `self.__getitem__`, and since `_EnumDict.__setitem__` is where all of the magic happens regular dict.update won't trigger it. I agree though that adding an update method would be nice though and can be done in just a few lines of code.

    import enum
    import sys

    def local_update(it=(), **kws):
        self = sys._getframe(1).f_locals
        d = dict(it, **kws)
        for k, v in d.items():
            self[k] = v
            
    class MyEnum(enum.Enum):
        local_update(a=1, b=2)
        
    assert MyEnum.a.value == 1

[*] it doesn't actually build a new one every time but the only practical purpose with the NEWLOCALS code.co_code flag set is for introspection with vars(), locals(), and sys._getframe

----------
nosy: +bup

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:30:40 2018
From: report at bugs.python.org (ChrisRands)
Date: Fri, 21 Sep 2018 21:30:40 +0000
Subject: [issue34764] Improve documentation example for using iter() with
 sentinel value
In-Reply-To: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>
Message-ID: <1537565440.85.0.956365154283.issue34764@psf.upfronthosting.co.za>


ChrisRands <chrisrands0 at gmail.com> added the comment:

Thank you Raymond, I like both your examples, although I think I prefer 1) for the simplicity

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34764>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:34:26 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 21 Sep 2018 21:34:26 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537565666.09.0.956365154283.issue34537@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
keywords: +patch
pull_requests: +8893
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:41:29 2018
From: report at bugs.python.org (paul j3)
Date: Fri, 21 Sep 2018 21:41:29 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1537566089.73.0.956365154283.issue34744@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

In your proposed change:

        params = dict(vars(action), prog=self._prog)
      +  if action.option_strings:
      +      params['flag'] = action.option_strings[0]

'params', as I noted earlier already includes the 'dest' and 'option_strings' list.  

'option_strings' is already being used in '_format_action_invocation()'.  So I don't see why this flag needs to appear again in the help line.  Though the user can certainly hard code it into the line when defining the 'add_argument'

e.g.

    cmdline.add_argument('--complex-argument', help='format --complex-argument key1=value1,key2=value2')

What's special about the comma-separated key/value input?

A patch/pull-request needs needs documentation, and unittest.  It appears to be innocuous from a testing stand point, but good documentation could be problem - it could easily end up being confusing without adding much value. 

I propose closing this because I don't think it is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:50:02 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 21 Sep 2018 21:50:02 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537566602.25.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I pushed a minor update to the PR, changing the MULTIPLIER and explaining the chosen constants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 17:55:02 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Sep 2018 21:55:02 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1537566902.5.0.956365154283.issue34561@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Thank you, Vincent!  I very much enjoyed - and appreciated - your paper I referenced at the start.  Way back when, I thought I had a proof of O(N log N), but never wrote it up because some details weren't convincing - even to me ;-) .  Then I had to move on to other things, and never got back to it.  I was probably mistaken.  So it was delightful to see your elegant proof of that, and even more.

I'm attaching a new runstack.py that includes code modeling your new adaptive Shivers strategy.  Like all these approximations, it has its own "bad cases" on smallish inputs.  Based on the specific cases this code runs, powersort remains in a category of its own, with timsort, twomerge, and shivers roughly tied on _average_ merge cost.

Part of the reason, I suspect:  powersort is the only strategy here that's always optimal for 3-run cases.  Which it buys at the cost of never merging the run just discovered (unless it's the last run in the array).  For example, in

    31, 16, 1

twomerge and shivers merge 31 and 16 first, before seeing 1, which is "far from" optimal.  timsort and powersort merge 16 and 1 first, although that's by design in powersort and by luck in timsort.  In

    16, 31, 1
    
only powersort does the best thing (note: runstack.py doesn't model peeksort; I'm sure it would merge 31 and 1 first on that too).

I care about small-number-of-runs because real-life Python lists aren't asymptotic in nature ;-)  People deliberately construct lists with a small number of runs now before sorting, because they know Python's sort can exploit that.  For many other cases, all runs are artificially forced to length `minrun`, and then any scheme at all that approximates balanced merging is about as good as any other.

What I can't know before we time things is whether order-of-merging makes a measurable difference in real life, and whether powersort's possible delay in merging the most recent run has bad cache effects that overwhelm its smaller "merge cost".

In any case, I'm keen to replace timsort's merge-order strategy with _something_ that's much easier to analyze.  The makes your Shivers variant and powersort the only two real contenders now.  It seems quite remarkable that the Shivers variant has such good asymptotics!  It's certainly the easiest to modify Python's C code to implement (straightforward edits in a single function).

----------
Added file: https://bugs.python.org/file47818/runstack.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34561>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:13:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 22:13:34 +0000
Subject: [issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was
 created with an older compiler
In-Reply-To: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>
Message-ID: <1537568014.05.0.956365154283.issue34575@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

It seems like the bug has been fixed. Thanks Zachary Ware for the fix, and thanks everybody for helping to fix this cache issue ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34575>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:17:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 22:17:58 +0000
Subject: [issue34576] [EASY doc] http.server,
 SimpleHTTPServer: warn users on security
In-Reply-To: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>
Message-ID: <1537568278.75.0.956365154283.issue34576@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +easy
title: SimpleHTTPServer: warn users on security -> [EASY doc] http.server, SimpleHTTPServer: warn users on security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34576>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:19:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 22:19:51 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1537568391.53.0.956365154283.issue34037@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Yury, Andrew: Do you know if the executor doesn't wait on purpose? Would it be possible to change that in Python 3.8?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:27:31 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 22:27:31 +0000
Subject: [issue32718] Install PowerShell activation scripts for venv for all
 platforms
In-Reply-To: <1517273696.22.0.467229070634.issue32718@psf.upfronthosting.co.za>
Message-ID: <1537568851.58.0.956365154283.issue32718@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d64ee1a5ba2007ae5fe085dd3495013d940a51bb by Miss Islington (bot) (Brett Cannon) in branch 'master':
bpo-32718: Make Activate.ps1 for venv cross-platform and available on all platforms (GH-9321)
https://github.com/python/cpython/commit/d64ee1a5ba2007ae5fe085dd3495013d940a51bb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32718>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:29:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 22:29:20 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1537568960.9.0.956365154283.issue34037@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Yury, Andrew: Do you know if the executor doesn't wait on purpose? Would it be possible to change that in Python 3.8?

Maybe.  At least we need to add a "timeout" argument to asyncio.run() to let it wait for executor jobs.

I'm also thinking about making OS threads cancellable/interruptable in Python 3.8 (if they run pure Python code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:37:30 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 21 Sep 2018 22:37:30 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1537569450.8.0.956365154283.issue34022@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
keywords: +patch
pull_requests: +8894
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:37:49 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Sep 2018 22:37:49 +0000
Subject: [issue32718] Install PowerShell activation scripts for venv for all
 platforms
In-Reply-To: <1517273696.22.0.467229070634.issue32718@psf.upfronthosting.co.za>
Message-ID: <1537569469.96.0.956365154283.issue32718@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/issue32718>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:49:10 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 21 Sep 2018 22:49:10 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1537570150.28.0.956365154283.issue34022@psf.upfronthosting.co.za>


Elvis Pranskevichus <elvis at magic.io> added the comment:

> In particular, if a build system sets SOURCE_DATE_EPOCH without
specifying a pyc format for py_compile or compileall, Python 3.7 will
give you checked hashes by default

Actually, py_compile will _force_ the CHECKED_HASH mode if SOURCE_DATE_EPOCH is set, regardless of what you specified for py_compile or compileall.  I'm not sure if that's actually intended or a bug.

The fix for the tests is to actually be aware of py_compile behavior and control for SOURCE_DATE_EPOCH.  I submitted a PR with a fix.

----------
nosy: +Elvis.Pranskevichus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:51:20 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Sep 2018 22:51:20 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1537570280.31.0.956365154283.issue34022@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I dislike that having SOURCE_DATE_EPOCH set magically changes command line tools behavior. In my view, this problem should be fixed by reverting ccbe5818af2.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Fri Sep 21 18:57:09 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Sep 2018 22:57:09 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537570629.62.0.956365154283.issue34763@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As I said on the PR, this is because Unicode gives U+4E17 (and other CJK ideographs) a numeric value only in the UniHan database not the normal UCD. makeunicodedata.py only looks at UCD for numeric values.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Fri Sep 21 19:02:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 23:02:26 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
In-Reply-To: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>
Message-ID: <1537570946.32.0.956365154283.issue32706@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Christian: It seems like the test now pass on my Fedora 27. Is it time to enable the test again?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Fri Sep 21 19:02:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 23:02:41 +0000
Subject: [issue31986] [2.7] test_urllib2net.test_sites_no_connection_close()
 randomly fails on Python 2.7
In-Reply-To: <1510179643.18.0.213398074469.issue31986@psf.upfronthosting.co.za>
Message-ID: <1537570961.23.0.956365154283.issue31986@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31986>
_______________________________________

From report at bugs.python.org  Fri Sep 21 19:04:46 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Fri, 21 Sep 2018 23:04:46 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1537571086.91.0.956365154283.issue34022@psf.upfronthosting.co.za>


Elvis Pranskevichus <elvis at magic.io> added the comment:

Perhaps SOURCE_DATE_EPOCH should only be consulted to determine the default behavior if invalidation_mode was not passed explicitly to py_compile.compile().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Fri Sep 21 19:06:11 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 23:06:11 +0000
Subject: [issue31511] test_normalization: test.support.open_urlresource()
 doesn't handle urllib.error.URLError timeout
In-Reply-To: <1505752156.04.0.237744283589.issue31511@psf.upfronthosting.co.za>
Message-ID: <1537571171.26.0.956365154283.issue31511@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31511>
_______________________________________

From report at bugs.python.org  Fri Sep 21 19:06:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 23:06:35 +0000
Subject: [issue31007] ERROR: test_pipe_handle
 (test.test_asyncio.test_windows_utils.PipeTests) expected
 ERROR_INVALID_HANDLE on x86 Windows7 3.x
In-Reply-To: <1500887344.87.0.0437843877994.issue31007@psf.upfronthosting.co.za>
Message-ID: <1537571195.29.0.956365154283.issue31007@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31007>
_______________________________________

From report at bugs.python.org  Fri Sep 21 19:07:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 23:07:27 +0000
Subject: [issue30350] devguide suggests to use VS 2008 to build Python 2.7,
 but VS 2008 is no more supported?
In-Reply-To: <1494581567.83.0.310363881682.issue30350@psf.upfronthosting.co.za>
Message-ID: <1537571247.51.0.956365154283.issue30350@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30350>
_______________________________________

From report at bugs.python.org  Fri Sep 21 20:10:44 2018
From: report at bugs.python.org (Benito Kestelman)
Date: Sat, 22 Sep 2018 00:10:44 +0000
Subject: [issue34768] Add documentation explaining __init__.py in packages
In-Reply-To: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>
Message-ID: <1537575044.75.0.956365154283.issue34768@psf.upfronthosting.co.za>


Change by Benito Kestelman <beni.kestel001 at gmail.com>:


----------
title: Add documentation for the purpose of __init__.py in packages -> Add documentation explaining __init__.py in packages

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34768>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:08:17 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 22 Sep 2018 01:08:17 +0000
Subject: [issue34576] [EASY doc] http.server,
 SimpleHTTPServer: warn users on security
In-Reply-To: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>
Message-ID: <1537578497.67.0.956365154283.issue34576@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

There was some disagreement later on the list about adding this warning. We will fix security issues in SimpleHTTPServer.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34576>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:13:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Sep 2018 01:13:24 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537578804.52.0.956365154283.issue34537@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7279b5125e7c5d84a473d250b27d353cb7f6628e by Victor Stinner (Elvis Pranskevichus) in branch 'master':
bpo-34537: Fix test_gdb:test_strings with LC_ALL=C (GH-9483)
https://github.com/python/cpython/commit/7279b5125e7c5d84a473d250b27d353cb7f6628e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:13:30 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 01:13:30 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537578810.27.0.956365154283.issue34537@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8895

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:15:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Sep 2018 01:15:00 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537578900.19.0.956365154283.issue34537@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't think that it's worth it to backport the change to Python 3.6 and older, since "LC_ALL=C ./python -m test test_gdb" already pass on 2.7 and 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:20:27 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 22 Sep 2018 01:20:27 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537579227.37.0.956365154283.issue22490@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I was pointed here after we found some erroneous behavior.

We have a script run by the system python that invokes a specific venv's python3 with a -m flag requesting a module that is installed (only) in that venv. A user complained that this failed, with the venv's python3 claiming the module was not installed (but it was, as proved by manually running it with the same -m flag).

Eventually someone realized that this was because the system python was a python3 installed by homebrew -- somehow this caused the system python (being python3) set __PYVENV_LAUNCHER__, and that made the venv's python3 ignore the venv's site-packages and instead look in the system python's site-packages.

This feels very wrong.

Maybe this is just a clearer description of https://bugs.python.org/issue31363? But that gained no traction while here there is at least some discussion.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:29:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 01:29:40 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537579780.77.0.956365154283.issue34537@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e5fde1f992e94f166415ab96d874ed1d2e0c8004 by Miss Islington (bot) in branch '3.7':
bpo-34537: Fix test_gdb:test_strings with LC_ALL=C (GH-9483)
https://github.com/python/cpython/commit/e5fde1f992e94f166415ab96d874ed1d2e0c8004


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:31:20 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 22 Sep 2018 01:31:20 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537579880.41.0.956365154283.issue32117@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:


New changeset fd97d1f1af910a6222ea12aec42c456b64f9aee4 by Guido van Rossum (David Cuthbert) in branch 'master':
bpo-32117: Allow tuple unpacking in return and yield statements (gh-4509)
https://github.com/python/cpython/commit/fd97d1f1af910a6222ea12aec42c456b64f9aee4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Fri Sep 21 21:34:30 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 22 Sep 2018 01:34:30 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537580070.22.0.956365154283.issue32117@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Fixed by https://github.com/python/cpython/pull/4509.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Fri Sep 21 22:03:13 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Sep 2018 02:03:13 +0000
Subject: [issue29577] Enum: mixin classes don't mix well with already mixed
 Enums
In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za>
Message-ID: <1537581793.96.0.956365154283.issue29577@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 5bdab641da0afd8aa581dfbde4f82d88d337c4b5 by Ethan Furman in branch 'master':
bpo-29577: Enum: mixin classes don't mix well with already mixed Enums (GH-9328)
https://github.com/python/cpython/commit/5bdab641da0afd8aa581dfbde4f82d88d337c4b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29577>
_______________________________________

From report at bugs.python.org  Fri Sep 21 22:12:04 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Sep 2018 02:12:04 +0000
Subject: [issue29577] Enum: mixin classes don't mix well with already mixed
 Enums
In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za>
Message-ID: <1537582324.36.0.956365154283.issue29577@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +8896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29577>
_______________________________________

From report at bugs.python.org  Fri Sep 21 22:58:00 2018
From: report at bugs.python.org (Windson Yang)
Date: Sat, 22 Sep 2018 02:58:00 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1537585080.18.0.956365154283.issue34397@psf.upfronthosting.co.za>


Windson Yang <wiwindson at gmail.com> added the comment:

Hello, Tim Peters. I wonder why we need to add size_t here:

    assert((size_t)Py_SIZE(a) + (size_t)Py_SIZE(b) <= (size_t)PY_SSIZE_T_MAX);

AFAIK, PY_SSIZE_T_MAX = ((Py_ssize_t)(((size_t)-1)>>1)) which is signed, either Py_SIZE(a) or Py_SIZE(b) is a positive number. Why we need to concast them to size_t, Thank you?

----------
nosy: +Windson Yang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Fri Sep 21 23:47:32 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 22 Sep 2018 03:47:32 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537588052.88.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

>> Why do you claim the original was "too small"?  Too small for
>> what purpose?

> If the multiplier is too small, then the resulting hash values are
> small too. This causes collisions to appear for smaller numbers:

All right!  An actual reason ;-)  So there are two things so far I clearly agree with, but they're independent of "the problem" this report was opened about:

1. On a 64-bit box life would be better if we picked a bigger multiplier.  This should be done via preprocessor #if selection, though, not via the inscrutable rules C uses to cut back an integer literal out of range for the type of the variable it's assigned to.

2. A raw integer hash of -1 should be changed to something other than -2.  It was always a Poor Idea to pick an integer of small magnitude for the substitute.  Some newer types didn't repeat this mistake.  For example, frozensets replace a raw hash of -1 with 
590923713.  Alas, this is hard to change now, because hashable objects of any type that compare equal to -1 also need to return the same substitute value (e.g., hash(-1.0) == hash(decimal.Decimal("-100e-2")) == hash(-1+0j) == -2).  So I'm afraid it's been hard-coded into user-defined numeric classes too :-(  There would be no obvious problem in changing the _tuple_ hash to use a different substitute value, although it's not clear that would buy anything either.  hash(-1) == -2 was the original sin.


[about multipliers]
> Because it's really just random chance.
> ...
> Ideally, it should be just a random number.

How do you know this?  I'm not aware of any research papers about picking multipliers in this context, but would love to see one.

I am aware of much research about multipliers in the somewhat related contexts of linear congruential pseudo-random number generators, and of "multiplicative hashing", and "any random multiplier is fine" couldn't be further from the truth _in_ those contexts.

Guido picked a prime to begin with (actually, at first it was 3(!)), and comments in the current code sure say that whoever added this part was keen on primes too:

"""
/* The addend 82520, was selected from the range(0, 1000000) for
   generating the greatest number of prime multipliers for tuples
   up to length eight:
"""

I don't know that primes are important here, but neither do I know that they're _not_ important here.  Widely used production code isn't the place to conduct experiments, so the status quo is favored in the absence of truly compelling reasons.  Just repeating the raw assertion "random is fine" isn't compelling.  If it were true, we could, e.g., multiply by a large power of 2 via shifting instead, and save a few cycles.

For my best guess at what "the problem" here actually is, in the

>>> cands = list(range(-10, -1)) + list(range(9))
>>> len(set(hash(t) for t in product(cands, repeat=4)))

example, which currently (on my 64-bit box) generates 35,380 distinct hash codes from the 104,976 inputs, ALL the collisions go away merely by changing the character "^" to "+" in the current code.

Which was your original suggestion.  Which you appear to be opposed to now?  I'm unclear about why, if so.

That's a change I could probably live with, although I have no strong reason to believe it couldn't cause problems for applications that currently work fine.  I don't have more time to think about that now, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 21 23:48:49 2018
From: report at bugs.python.org (Jordan Chapman)
Date: Sat, 22 Sep 2018 03:48:49 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537588129.74.0.956365154283.issue32117@psf.upfronthosting.co.za>


Change by Jordan Chapman <jchapman134569 at gmail.com>:


----------
pull_requests: +8897

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Fri Sep 21 23:57:36 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 22 Sep 2018 03:57:36 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1537588656.09.0.956365154283.issue34397@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Because the behavior of signed integer overflow isn't defined in C.  Picture a 3-bit integer type, where the maximum value of the signed integer type is 3.  3+3 has no defined result.  Cast them to the unsigned flavor of the integer type, though, and the result is defined to be 6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:11:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Sep 2018 04:11:47 +0000
Subject: [issue34686] Add `-r`, as opposed to `-R` to Python core interpreter
In-Reply-To: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>
Message-ID: <1537589507.99.0.956365154283.issue34686@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34686>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:42:34 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:42:34 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537591353.99.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 026337a7101369297c8083047d2f3c6fc9dd1e2b by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482)
https://github.com/python/cpython/commit/026337a7101369297c8083047d2f3c6fc9dd1e2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:42:46 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:42:46 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537591366.49.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8898

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:42:54 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:42:54 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537591374.95.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8899

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:43:05 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:43:05 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537591385.92.0.956365154283.issue34623@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8900

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:44:15 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:44:15 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537591455.3.0.956365154283.issue34759@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c0da582b227f311126e278b5553a7fa89c79b054 by Miss Islington (bot) (Nathaniel J. Smith) in branch 'master':
bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468)
https://github.com/python/cpython/commit/c0da582b227f311126e278b5553a7fa89c79b054


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:44:23 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:44:23 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537591463.19.0.956365154283.issue34759@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8901

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:47:53 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 22 Sep 2018 04:47:53 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537591673.64.0.956365154283.issue34759@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8902

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:57:05 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:57:05 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537592225.84.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 10be1d3f802b874914b2a13eb41407c7a582d9b3 by Miss Islington (bot) in branch '2.7':
[2.7] bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482) (GH-9490)
https://github.com/python/cpython/commit/10be1d3f802b874914b2a13eb41407c7a582d9b3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:57:31 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:57:31 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537592251.35.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d1b336e530472f316b1d164d04626724c83b16d7 by Miss Islington (bot) in branch '3.6':
[3.6] bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482) (GH-9489)
https://github.com/python/cpython/commit/d1b336e530472f316b1d164d04626724c83b16d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 00:57:49 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 04:57:49 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1537592269.73.0.956365154283.issue34623@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5c3d8b2efda1b99abe09ad925f366c5695bd66fb by Miss Islington (bot) in branch '3.7':
[3.7] bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482) (GH-9488)
https://github.com/python/cpython/commit/5c3d8b2efda1b99abe09ad925f366c5695bd66fb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Sat Sep 22 01:00:46 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 05:00:46 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537592446.98.0.956365154283.issue34759@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c00f7037df3607c89323e68db3ab996b7df394de by Miss Islington (bot) in branch '3.7':
bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468)
https://github.com/python/cpython/commit/c00f7037df3607c89323e68db3ab996b7df394de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Sat Sep 22 01:10:10 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Sep 2018 05:10:10 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537593010.72.0.956365154283.issue34759@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7529754d26f5e744ae25bee56fdc1937bcf08c7e by Miss Islington (bot) (Christian Heimes) in branch '3.6':
[3.6] bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468) (GH-9492)
https://github.com/python/cpython/commit/7529754d26f5e744ae25bee56fdc1937bcf08c7e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Sat Sep 22 01:25:05 2018
From: report at bugs.python.org (thautwarm)
Date: Sat, 22 Sep 2018 05:25:05 +0000
Subject: [issue32352] `inspect.getfullargspec` doesn't work fine for some
 builtin callable objects
In-Reply-To: <1513518429.74.0.213398074469.issue32352@psf.upfronthosting.co.za>
Message-ID: <1537593905.39.0.956365154283.issue32352@psf.upfronthosting.co.za>


thautwarm <yaoxiansamma at gmail.com> added the comment:

Maybe a few adjustments to this one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32352>
_______________________________________

From report at bugs.python.org  Sat Sep 22 01:26:36 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Sep 2018 05:26:36 +0000
Subject: [issue29577] Enum: mixin classes don't mix well with already mixed
 Enums
In-Reply-To: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za>
Message-ID: <1537593996.76.0.956365154283.issue29577@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 0c076caaa82a9c6596e1fe1dbe6384d53f30a1a3 by Ethan Furman in branch '3.7':
[3.7] bpo-29577: Enum: mixin classes don't mix well with already mixed Enums (GH-9328) (GH-9486)
https://github.com/python/cpython/commit/0c076caaa82a9c6596e1fe1dbe6384d53f30a1a3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29577>
_______________________________________

From report at bugs.python.org  Sat Sep 22 01:40:07 2018
From: report at bugs.python.org (thautwarm)
Date: Sat, 22 Sep 2018 05:40:07 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537594807.49.0.956365154283.issue32892@psf.upfronthosting.co.za>


thautwarm <yaoxiansamma at gmail.com> added the comment:

I'm in favor of this idea for prospective extensions that could be implemented through this brand-new ast.Constant.  

Actually I used to expect a more general ast.Constant when I was manipulating ASTs half a year ago, at that time my job is to make staging functions that take some user-defined types as constants(in these scenes, these types are definitely immutable and permanent) to gain performance improvements and avoid redundant allocations, and what I exactly wanted is such an ast.Constant.

----------
nosy: +thautwarm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Sat Sep 22 03:16:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 07:16:22 +0000
Subject: [issue24828] Segfault when using store-context AST node in a load
 context
In-Reply-To: <1439042614.34.0.045626812152.issue24828@psf.upfronthosting.co.za>
Message-ID: <1537600582.44.0.956365154283.issue24828@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Reproducible on latest 2.7 branch as well. Stack trace as below : 

Program received signal SIGSEGV, Segmentation fault.
dict_set_item_by_hash_or_entry (
    op={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, key=<optimized out>, hash=<optimized out>,
    value=<optimized out>, ep=<optimized out>) at Objects/dictobject.c:792
792	    Py_INCREF(value);
(gdb) bt
#0  dict_set_item_by_hash_or_entry (op={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, key=<optimized out>, hash=<optimized out>, value=<optimized out>, ep=<optimized out>) at Objects/dictobject.c:792
#1  PyDict_SetItem (op={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, key='foo', value=0x0) at Objects/dictobject.c:848
#2  0x00000001000ab62e in PyEval_EvalFrameEx (f=<unknown at remote 0x8>, throwflag=<optimized out>) at Python/ceval.c:2186
#3  0x00000001000a735a in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=0x0, argcount=<optimized out>, kws=<optimized out>, kwcount=<optimized out>, defs=0x0, defcount=<optimized out>, closure=<optimized out>) at Python/ceval.c:3604
#4  0x00000001000a6cb6 in PyEval_EvalCode (co=0x100293168, globals='foo', locals=0x0) at Python/ceval.c:669
#5  0x00000001000a302a in builtin_eval (self={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, args=<optimized out>) at Python/bltinmodule.c:679
#6  0x00000001000ae8a7 in call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4372
#7  PyEval_EvalFrameEx (f=Frame 0x1002d4bc0, for file ../backups/bpo24828.py, line 7, in <module> (), throwflag=<optimized out>) at Python/ceval.c:3009
#8  0x00000001000a735a in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=0x0, argcount=<optimized out>, kws=<optimized out>, kwcount=<optimized out>, defs=0x0, defcount=<optimized out>, closure=<optimized out>) at Python/ceval.c:3604
#9  0x00000001000a6cb6 in PyEval_EvalCode (co=0x100293168, globals='foo', locals=0x0) at Python/ceval.c:669
#10 0x00000001000d4de4 in run_mod (mod=<optimized out>, filename=<optimized out>, globals={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, locals={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, flags=<optimized out>, arena=<optimized out>) at Python/pythonrun.c:1385
#11 PyRun_FileExFlags (fp=<optimized out>, filename=<optimized out>, start=<optimized out>, globals={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, locals={'code': <code at remote 0x10059cc30>, 'ast': <module at remote 0x1005ab868>, '__builtins__': <module at remote 0x10023db08>, '__file__': '../backups/bpo24828.py', 'm': <Module(body=[<Expr(lineno=1, value=<Name(ctx=<Store at remote 0x1005a5f10>, id='foo', col_offset=0, lineno=1) at remote 0x1005c2790>, col_offset=0) at remote 0x1005c27d0>]) at remote 0x1005c2810>, '__package__': None, '__name__': '__main__', '__doc__': None}, closeit=1, flags=<optimized out>) at Python/pythonrun.c:1371
#12 0x00000001000d491a in PyRun_SimpleFileExFlags (fp=0x7fff71bec070, filename=0xc6079cb3d3de86bb <error: Cannot access memory at address 0xc6079cb3d3de86bb>, closeit=8, flags=0x7fff5fbffa70) at Python/pythonrun.c:957
#13 0x00000001000ea8f2 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:645
#14 0x00007fff8b5055c9 in start () from /usr/lib/system/libdyld.dylib
#15 0x00007fff8b5055c9 in start () from /usr/lib/system/libdyld.dylib
#16 0x0000000000000000 in ?? ()


Adding Benjamin since he is the 2.7 release manager and it's something specific to 2.7.


Thanks

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24828>
_______________________________________

From report at bugs.python.org  Sat Sep 22 03:27:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Sep 2018 07:27:41 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537601261.51.0.956365154283.issue34537@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thank you Elvis for the fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Sat Sep 22 03:30:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 07:30:34 +0000
Subject: [issue25952] code_context not available in exec()
In-Reply-To: <1451060087.44.0.968939849155.issue25952@psf.upfronthosting.co.za>
Message-ID: <1537601434.48.0.956365154283.issue25952@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25952>
_______________________________________

From report at bugs.python.org  Sat Sep 22 03:36:42 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 22 Sep 2018 07:36:42 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537601802.6.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I don't know that primes are important here, but neither do I know that they're _not_ important here.

Hashes are effectively computed modulo 2**N. "Primes" are meaningless in that setting (except for the prime 2 which does have a meaning). For example, 1000003 is prime but 1000003 + 2**64 is not. But these represent the same number modulo 2**64. Also, multiplication by any odd number is a permutation modulo 2**N, so every odd number is invertible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 03:42:59 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 07:42:59 +0000
Subject: [issue24834] pydoc should display the expression for a builtin
 argument default, not its result
In-Reply-To: <1439115056.44.0.0298304719355.issue24834@psf.upfronthosting.co.za>
Message-ID: <1537602179.66.0.956365154283.issue24834@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24834>
_______________________________________

From report at bugs.python.org  Sat Sep 22 03:44:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 07:44:21 +0000
Subject: [issue24174] Python crash on exit
In-Reply-To: <1431517823.23.0.704050374474.issue24174@psf.upfronthosting.co.za>
Message-ID: <1537602261.48.0.956365154283.issue24174@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24174>
_______________________________________

From report at bugs.python.org  Sat Sep 22 04:01:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 08:01:21 +0000
Subject: [issue24997] mock.call_args compares as equal and not equal
In-Reply-To: <1441343319.6.0.391788581363.issue24997@psf.upfronthosting.co.za>
Message-ID: <1537603281.59.0.956365154283.issue24997@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems to have been implemented with ce913877e42b7fa03434c2e765ace891e0f5c4dc . https://bugs.python.org/issue25195 

$ git checkout ce913877e42b7fa03434c2e765ace891e0f5c4dc~1 Lib/unittest/mock.py
$ ./python.exe ../backups/bpo24997.py
1  True
2  True

$ git checkout ce913877e42b7fa03434c2e765ace891e0f5c4dc Lib/unittest/mock.py
$ ./python.exe ../backups/bpo24997.py
1  True
2  False

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24997>
_______________________________________

From report at bugs.python.org  Sat Sep 22 04:03:42 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 22 Sep 2018 08:03:42 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537603422.94.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Which was your original suggestion.  Which you appear to be opposed to now?  I'm unclear about why, if so.

I'm not strictly opposed to that. It's just that I have less confidence in the current ad-hoc hash compared to something following the DJBX33A scheme.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 04:04:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 08:04:15 +0000
Subject: [issue24307] pip error on windows whose current user name contains
 non-ascii characters
In-Reply-To: <1432779659.79.0.171307025039.issue24307@psf.upfronthosting.co.za>
Message-ID: <1537603455.88.0.956365154283.issue24307@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24307>
_______________________________________

From report at bugs.python.org  Sat Sep 22 04:23:08 2018
From: report at bugs.python.org (=?utf-8?q?Vincent_Jug=C3=A9?=)
Date: Sat, 22 Sep 2018 08:23:08 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
In-Reply-To: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>
Message-ID: <1537604588.2.0.956365154283.issue34561@psf.upfronthosting.co.za>


Vincent Jug? <vincent.juge at u-pem.fr> added the comment:

I see... Indeed, my only goal when adapting Shivers Sort was to maintain some invariant that would make the analysis easy, while mimicking the arguments developed by Buss & Knop for their analysis of (plain) Shivers Sort. It is, however, sure that the n(H+4) upper bound I get should be refined when H is small, which more or less amounts to tackling the 3-run case you mention.

I am reasonably convinced that the current version of Adaptive Shivers Sort could be adapted to take this problem into account, while keeping its overall simple stricture and complexity analysis.

If this first step turns out to be feasible, I will also look at the latest version of runstack.py to investigate other possible improvements on Adaptive Shivers Sort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34561>
_______________________________________

From report at bugs.python.org  Sat Sep 22 04:39:30 2018
From: report at bugs.python.org (Antony Lee)
Date: Sat, 22 Sep 2018 08:39:30 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1537605570.07.0.956365154283.issue34750@psf.upfronthosting.co.za>


Antony Lee <anntzer.lee at gmail.com> added the comment:

> I agree though that adding an update method would be nice though and can be done in just a few lines of code.

Again, this can be done just be inheriting the methods from MutableMapping.

In fact even now one can just write

    class E(Enum): MutableMapping.update(locals(), {"a": 1})

and this will do the "right" thing but that's hardly an obvious way to do it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Sat Sep 22 05:12:44 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 22 Sep 2018 09:12:44 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537607564.65.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I'm not aware of any research papers about picking multipliers in this context, but would love to see one.

The only real condition that I can think of is that the order should be large: we do not want MULTIPLIER**n = 1 (mod 2**N) for a small number n.

Other than that, we could pick the multiplier to guarantee no hash collisions on some chosen subset of inputs. A bit like your product(range(100), repeat=4) example but then for more inputs.

If you agree with this approach, I could try to find a good multiplier this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 08:31:40 2018
From: report at bugs.python.org (Amos S)
Date: Sat, 22 Sep 2018 12:31:40 +0000
Subject: [issue34709] Suggestion: make getuser.getpass() also look at
 SUDO_USER environment variable
In-Reply-To: <1537160258.21.0.956365154283.issue34709@psf.upfronthosting.co.za>
Message-ID: <1537619500.85.0.956365154283.issue34709@psf.upfronthosting.co.za>


Change by Amos S <amos.shapira at gmail.com>:


----------
keywords: +patch
pull_requests: +8903
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34709>
_______________________________________

From report at bugs.python.org  Sat Sep 22 09:25:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 13:25:40 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537622740.86.0.956365154283.issue32892@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

thautwarm, ast.Constant is not new. You can use it since 3.8. What is new in this issue -- ast.parse() will produce ast.Constant instead of ast.Num, ast.Str, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Sat Sep 22 09:37:42 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 22 Sep 2018 13:37:42 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537623462.5.0.956365154283.issue22490@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As I said in msg284106, it seems that the __PYVENV_LAUNCHER__ should be removed from the stub launcher and then tests should confirm that framework builds aren't adversely affected. Unfortunately, I can't do this testing as I don't have a Mac, and have been hoping that one of the Mac platform experts (or indeed anyone who can build and test framework builds) can look at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sat Sep 22 09:43:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 13:43:22 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1537623802.57.0.956365154283.issue33346@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the status of this issue?

Similar change to the Grammar was just merged in issue32117. Both issue32117 and this issue extend already implemented PEPs (PEP 448 and PEP 525 correspondingly) to the corner case missed in the original PEP.

Pablo, Yury, could you please start a discussion about this on the Pythod-Dev mailing list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33346>
_______________________________________

From report at bugs.python.org  Sat Sep 22 10:39:44 2018
From: report at bugs.python.org (twisteroid ambassador)
Date: Sat, 22 Sep 2018 14:39:44 +0000
Subject: [issue34769] _asyncgen_finalizer_hook running in wrong thread
Message-ID: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za>


New submission from twisteroid ambassador <twisteroid.ambassador at gmail.com>:

When testing my happy eyeballs library, I occasionally run into issues with async generators seemingly not finalizing. After setting loop.set_debug(True), I have been seeing log entries like these:


Exception ignored in: <async_generator object builtin_resolver at 0x7fca945c8158>
Traceback (most recent call last):
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 466, in _asyncgen_finalizer_hook
    self.create_task(agen.aclose())
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 386, in create_task
    task = tasks.Task(coro, loop=self)
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 674, in call_soon
    self._check_thread()
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 712, in _check_thread
    "Non-thread-safe operation invoked on an event loop other "
RuntimeError: Non-thread-safe operation invoked on an event loop other than the current one
ERROR    asyncio Task was destroyed but it is pending!
source_traceback: Object created at (most recent call last):
  File "/opt/Python3.7.0/lib/python3.7/threading.py", line 885, in _bootstrap
    self._bootstrap_inner()
  File "/opt/Python3.7.0/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/opt/Python3.7.0/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/Python3.7.0/lib/python3.7/concurrent/futures/thread.py", line 80, in _worker
    work_item.run()
  File "/opt/Python3.7.0/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 746, in _getaddrinfo_debug
    msg.append(f'type={type!r}')
  File "/opt/Python3.7.0/lib/python3.7/enum.py", line 572, in __repr__
    self.__class__.__name__, self._name_, self._value_)
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 466, in _asyncgen_finalizer_hook
    self.create_task(agen.aclose())
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 386, in create_task
    task = tasks.Task(coro, loop=self)
task: <Task pending coro=<<async_generator_athrow without __name__>()> created at /opt/Python3.7.0/lib/python3.7/asyncio/base_events.py:386>



This is a typical instance. Usually several instances like this occur at once.

I'll try to reproduce these errors in a simple program. Meanwhile, here are some details about the actual program, which may or may not be related to the errors:

* I have several nested async generators (async for item in asyncgen: yield do_something(item); ), and when the errors appear, the above error messages and stack traces repeat several times, with the object names mentioned in "Exception ignored in: ..." being each of the nested async generators. Other parts of the error messages, including the stack traces, are exactly the same.

* I never used threads or loop.run_in_executor() explicitly in the program. However, the innermost async generator calls loop.getaddrinfo(), and that is implemented by running a Python function, socket.getaddrinfo(), with loop.run_in_executor(), so the program implicitly uses threads. (socket.getaddrinfo() is a Python function that calls a C function, _socket.getaddrinfo().)

* The outermost async generator is not iterated using `async for`. Instead, it is iterated by calling its `__aiter__` method, saving the returned async iterator object, and then awaiting on the `__anext__` method of the async iterator repeatedly. Of course, all of these are done in the same event loop.


Environment: Python 3.7.0 compiled from source, on Debian stretch.

----------
components: asyncio
messages: 326090
nosy: asvetlov, twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: _asyncgen_finalizer_hook running in wrong thread
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34769>
_______________________________________

From report at bugs.python.org  Sat Sep 22 10:51:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 14:51:58 +0000
Subject: [issue31506] Improve the error message logic for object_new &
 object_init
In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za>
Message-ID: <1537627918.97.0.956365154283.issue31506@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think this change should be reverted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31506>
_______________________________________

From report at bugs.python.org  Sat Sep 22 11:25:15 2018
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 22 Sep 2018 15:25:15 +0000
Subject: [issue30576] http.server should support HTTP compression (gzip)
In-Reply-To: <1496691724.59.0.955308322691.issue30576@psf.upfronthosting.co.za>
Message-ID: <1537629915.3.0.956365154283.issue30576@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

I have released the module as httpcompressionserver on PyPI : https://pypi.org/project/httpcompressionserver/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30576>
_______________________________________

From report at bugs.python.org  Sat Sep 22 11:38:54 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 15:38:54 +0000
Subject: [issue34709] Suggestion: make getuser.getpass() also look at
 SUDO_USER environment variable
In-Reply-To: <1537160258.21.0.956365154283.issue34709@psf.upfronthosting.co.za>
Message-ID: <1537630734.69.0.956365154283.issue34709@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34709>
_______________________________________

From report at bugs.python.org  Sat Sep 22 11:39:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 15:39:17 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1537630757.11.0.956365154283.issue33346@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33346>
_______________________________________

From report at bugs.python.org  Sat Sep 22 11:47:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 15:47:05 +0000
Subject: [issue23584] test_doctest lineendings fails in verbose mode
In-Reply-To: <1425487231.91.0.280595585638.issue23584@psf.upfronthosting.co.za>
Message-ID: <1537631225.08.0.956365154283.issue23584@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the patch. It seems this was fixed with 09a08de363cbe18a87392e1c2ebf0ac1f414592c (3.x) and c747e5564f0315357a3e7d2f580c6d1c8a3b4ab8 (2.7) by applying the code suggested in the patch. Can this be closed?

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23584>
_______________________________________

From report at bugs.python.org  Sat Sep 22 11:50:01 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 15:50:01 +0000
Subject: [issue23097] unittest can unnecessarily modify sys.path (and with the
 wrong case)
In-Reply-To: <1419151339.28.0.203745779889.issue23097@psf.upfronthosting.co.za>
Message-ID: <1537631401.63.0.956365154283.issue23097@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23097>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:01:01 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:01:01 +0000
Subject: [issue1180267] expanding platform module and making it work as it
 should
Message-ID: <1537632061.63.0.956365154283.issue1180267@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can this be closed as since platform.linx_distribution() was removed with https://bugs.python.org/issue28167 and distro is the recommended package which can be frequently updated.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1180267>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:02:42 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:02:42 +0000
Subject: [issue24063] Support Mageia and Arch Linux in the platform module
In-Reply-To: <1430077426.39.0.0830591110576.issue24063@psf.upfronthosting.co.za>
Message-ID: <1537632162.66.0.956365154283.issue24063@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Just to add some more context the function platform.linux_distribution() was removed in Python 3 with 8b94b41ab7b12f745dea744e8940631318816935. Refer https://bugs.python.org/issue28167 for more discussion. https://pypi.org/project/distro/ is the recommended package for this. I am not sure if this can be added to Python 2 though.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24063>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:04:18 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Sep 2018 16:04:18 +0000
Subject: [issue1180267] expanding platform module and making it work as it
 should
Message-ID: <1537632258.55.0.956365154283.issue1180267@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1180267>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:14:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:14:12 +0000
Subject: [issue23706] pathlib.Path.write_text should include a newline argument
In-Reply-To: <1426757561.17.0.481870343329.issue23706@psf.upfronthosting.co.za>
Message-ID: <1537632852.44.0.956365154283.issue23706@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems a similar API was suggested in the initial stages at https://bugs.python.org/issue20218#msg209017 . But looking at the reference library in the comment https://github.com/jaraco/path.py I think it's more about converting newlines in the given text with respect to the platform instead of adding one at the end.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23706>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:23:16 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:23:16 +0000
Subject: [issue24341] Test suite emits many DeprecationWarnings about
 sys.exc_clear() when -3 is enabled
In-Reply-To: <1433098290.5.0.721765999777.issue24341@psf.upfronthosting.co.za>
Message-ID: <1537633396.0.0.956365154283.issue24341@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24341>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:27:42 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:27:42 +0000
Subject: [issue21465] sqlite3 Row can return duplicate keys when using adapters
In-Reply-To: <1399672256.68.0.166250570949.issue21465@psf.upfronthosting.co.za>
Message-ID: <1537633662.43.0.956365154283.issue21465@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21465>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:28:32 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:28:32 +0000
Subject: [issue13822] is(upper/lower/title) are not exactly correct
In-Reply-To: <1326946975.13.0.733756833132.issue13822@psf.upfronthosting.co.za>
Message-ID: <1537633712.93.0.956365154283.issue13822@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13822>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:29:17 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Sep 2018 16:29:17 +0000
Subject: [issue21465] sqlite3 Row can return duplicate keys when using adapters
In-Reply-To: <1399672256.68.0.166250570949.issue21465@psf.upfronthosting.co.za>
Message-ID: <1537633757.94.0.956365154283.issue21465@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21465>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:35:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:35:12 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1537634112.98.0.956365154283.issue34476@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:44:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:44:28 +0000
Subject: [issue16360] argparse: comma in metavar causes assertion failure when
 formatting long usage message
In-Reply-To: <1351529348.85.0.0475227022594.issue16360@psf.upfronthosting.co.za>
Message-ID: <1537634668.7.0.956365154283.issue16360@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks @paul.j3 for the PR. The PR in the linked issue was merged and I cannot reproduce the original assertion error in the latest 2.7 branch with the script.

$ ./python.exe
Python 2.7.15+ (remotes/upstream/2.7:10be1d3f80, Sep 22 2018, 22:10:28)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ ./python.exe ../backups/bpo16360.py
usage: bpo16360.py [-h] [-w TIME] [-r N] [-j TIME] [-W TIME]
                   [-y COUNT|max|avg] [-o FILE] [-c CHANNEL[=LABEL],...]
                   FILE [FILE ...]
bpo16360.py: error: too few arguments


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16360>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:47:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:47:30 +0000
Subject: [issue30773] async generator receives wrong value when shared between
 coroutines
In-Reply-To: <1498503333.78.0.356156621032.issue30773@psf.upfronthosting.co.za>
Message-ID: <1537634850.73.0.956365154283.issue30773@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30773>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:47:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:47:41 +0000
Subject: [issue32181] runaway Tasks with Task.cancel() ignored.
In-Reply-To: <1512048559.34.0.213398074469.issue32181@psf.upfronthosting.co.za>
Message-ID: <1537634861.97.0.956365154283.issue32181@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32181>
_______________________________________

From report at bugs.python.org  Sat Sep 22 12:49:38 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:49:38 +0000
Subject: [issue31973] Incomplete DeprecationWarning for async/await keywords
In-Reply-To: <1510096549.91.0.213398074469.issue31973@psf.upfronthosting.co.za>
Message-ID: <1537634978.67.0.956365154283.issue31973@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31973>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:00:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:00:28 +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: <1537635628.32.0.956365154283.issue33039@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33039>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:00:58 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 22 Sep 2018 17:00:58 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
Message-ID: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

The GlobalLock() call in UpdateDropDescription() is not checked for failure.

----------
messages: 326098
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: pyshellext.cpp: Possible null pointer dereference
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:04:21 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 22 Sep 2018 17:04:21 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537635861.76.0.956365154283.issue34770@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8904
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:10:03 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 22 Sep 2018 17:10:03 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537636203.28.0.956365154283.issue22490@psf.upfronthosting.co.za>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +8905
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:16:15 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 22 Sep 2018 17:16:15 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537636575.66.0.956365154283.issue22490@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I went naively through the codebase and removed every reference to PYVENV_LAUNCHER and submitted as PR 9498. Does the CI runner at https://python.visualstudio.com/cpython/_build/results?buildId=31019&view=logs use a framework build such that it's an adequate test of the change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:27:04 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:27:04 +0000
Subject: [issue32897] test_gdb failed on Fedora 27
In-Reply-To: <1519241602.1.0.467229070634.issue32897@psf.upfronthosting.co.za>
Message-ID: <1537637224.36.0.956365154283.issue32897@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32897>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:28:08 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:28:08 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537637288.66.0.956365154283.issue34736@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:28:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:28:19 +0000
Subject: [issue32644] unittest.mock.call len() error
In-Reply-To: <1516776758.4.0.467229070634.issue32644@psf.upfronthosting.co.za>
Message-ID: <1537637299.72.0.956365154283.issue32644@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32644>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:31:11 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:31:11 +0000
Subject: [issue34609] Idle Unitest
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537637471.28.0.956365154283.issue34609@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:33:46 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:33:46 +0000
Subject: [issue33083] math.factorial accepts non-integral Decimal instances
In-Reply-To: <1521146313.09.0.467229070634.issue33083@psf.upfronthosting.co.za>
Message-ID: <1537637626.09.0.956365154283.issue33083@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33083>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:35:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:35:33 +0000
Subject: [issue31521] segfault in PyBytes_AsString
In-Reply-To: <1505845145.85.0.99143388289.issue31521@psf.upfronthosting.co.za>
Message-ID: <1537637733.92.0.956365154283.issue31521@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31521>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:35:52 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:35:52 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537637752.9.0.956365154283.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

The PR is ready for another review.

ISTM it should be good to go, after have addressing all of the significant issues brought up in the discussion here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:36:39 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:36:39 +0000
Subject: [issue31218] del expects __delitem__ if __setitem__ is defined
In-Reply-To: <1502880498.02.0.663608848315.issue31218@psf.upfronthosting.co.za>
Message-ID: <1537637799.89.0.956365154283.issue31218@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31218>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:48:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 17:48:26 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537638506.58.0.956365154283.issue34472@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6ec298114855b648a1f5fc4188ea3686a9d77fb3 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-34472: Add data descriptor signature to zipfile (GH-8871) (??-9407)
https://github.com/python/cpython/commit/6ec298114855b648a1f5fc4188ea3686a9d77fb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:51:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:51:41 +0000
Subject: [issue29164] make test always fail at 218/405 ( AssertionError: ',
 ' not found in '1234.5' )
In-Reply-To: <1483582865.63.0.483903091008.issue29164@psf.upfronthosting.co.za>
Message-ID: <1537638701.2.0.956365154283.issue29164@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29164>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:51:41 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:51:41 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1537638701.74.0.956365154283.issue34369@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +8906
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:53:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:53:34 +0000
Subject: [issue29081] time.strptime() return wrong result
In-Reply-To: <1482833112.13.0.0168836521105.issue29081@psf.upfronthosting.co.za>
Message-ID: <1537638814.51.0.956365154283.issue29081@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29081>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:55:42 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:55:42 +0000
Subject: [issue34609] Importing the certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537638942.18.0.956365154283.issue34609@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
title: Idle Unitest -> Importing the certain modules while debugging raises an exception

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:56:08 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:56:08 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537638968.01.0.956365154283.issue34609@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
title: Importing the certain modules while debugging raises an exception -> Importing certain modules while debugging raises an exception

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:56:12 2018
From: report at bugs.python.org (Frank Schaefer)
Date: Sat, 22 Sep 2018 17:56:12 +0000
Subject: [issue34771] test_ctypes failing on Linux SPARC64
Message-ID: <1537638972.94.0.956365154283.issue34771@psf.upfronthosting.co.za>


New submission from Frank Schaefer <kelledin at gmail.com>:

Python 3.6.6 on Linux 4.16.18 SPARC64 fails test_ctypes.  Specifically, it appears to be due to the _testfunc_large_struct_update_value() or _testfunc_reg_struct_update_value():

0:00:44 load avg: 46.24 [137/407/1] test_ctypes failed -- running: test_socket (44 sec), test_subprocess (35 sec), test_venv (43 sec), test_normalization (43 sec), test_signal (43 sec), test_multiprocessing_spawn (43 sec), test_concurrent_futures (43 sec), test_email (34 sec), test_cmd_line_script (43 sec), test_tools (43 sec), test_pickletools (34 sec), test_zipfile (30 sec), test_multiprocessing_fork (33 sec), test_pyclbr (31 sec), test_math (42 sec), test_calendar (35 sec), test_datetime (33 sec), test_distutils (30 sec)
test test_ctypes failed -- Traceback (most recent call last):
  File "/usr/src/dist/new/Python-3.6.6/Lib/ctypes/test/test_structures.py", line 416, in test_pass_by_value
    self.assertEqual(s.first, 0xdeadbeef)
AssertionError: 195948557 != 3735928559

Obviously, the "0xbadf00d" field setting is propagating back up through something that's supposed to be passed-by-value, and the test case quite rightly picks up on it.  I suspect this bug exists in 2.7.15 as well (2.7 just doesn't have the testcase to catch it).
 
This is built with gcc-8.2.0, glibc-2.27, kernel 4.16.18, CFLAGS="-O1 -mcpu=v9 -mtune=v9".  (FYI I had to turn down optimization to resolve another test failure, hence the "-O1".)

I'm guessing SPARC64 calling conventions are still passing certain large values by reference, and libffi isn't dealing with this?  I'm still investigating.  I've tried it with and without --with-system-libffi, with no difference (my system libffi is 3.2.1).

----------
components: ctypes
messages: 326102
nosy: kelledin-3
priority: normal
severity: normal
status: open
title: test_ctypes failing on Linux SPARC64
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34771>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:56:44 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:56:44 +0000
Subject: [issue29143] Logger should ignore propagate property for disabled
 handlers.
In-Reply-To: <1483465774.47.0.809201158116.issue29143@psf.upfronthosting.co.za>
Message-ID: <1537639004.77.0.956365154283.issue29143@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please attach a script that has a relevant sample logging configuration along with the output you are expecting?

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29143>
_______________________________________

From report at bugs.python.org  Sat Sep 22 13:58:14 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:58:14 +0000
Subject: [issue12294] multiprocessing.Pool: Need a way to find out if work are
 finished.
In-Reply-To: <1307627992.49.0.467043384727.issue12294@psf.upfronthosting.co.za>
Message-ID: <1537639094.02.0.956365154283.issue12294@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12294>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:00:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:00:18 +0000
Subject: [issue27709] difflib.HtmlDiff produces different output from
 difflib.ndiff
In-Reply-To: <1470670857.15.0.245619921121.issue27709@psf.upfronthosting.co.za>
Message-ID: <1537639218.53.0.956365154283.issue27709@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27709>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:02:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:02:56 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537639376.93.0.956365154283.issue34472@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ed21919d69ac22232cbc0dad0323477818112b6f by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-34472: Add data descriptor signature to zipfile (GH-8871) (GH-9398)
https://github.com/python/cpython/commit/ed21919d69ac22232cbc0dad0323477818112b6f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:03:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:03:08 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537639388.11.0.956365154283.issue34472@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 44989bc2696320cf55ae6f329aaf58edd49d792a by Serhiy Storchaka (Miss Islington (bot)) in branch '3.7':
bpo-34472: Add data descriptor signature to zipfile (GH-8871) (GH-9399)
https://github.com/python/cpython/commit/44989bc2696320cf55ae6f329aaf58edd49d792a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:03:34 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:03:34 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537639414.62.0.956365154283.issue34472@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:03:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:03:48 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1537639428.09.0.956365154283.issue34472@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution: rejected -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:14:31 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:14:31 +0000
Subject: [issue24638] asyncio "loop argument must agree with future" error
 message could be improved
In-Reply-To: <1436967590.12.0.584324642332.issue24638@psf.upfronthosting.co.za>
Message-ID: <1537640071.11.0.956365154283.issue24638@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24638>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:16:23 2018
From: report at bugs.python.org (Socob)
Date: Sat, 22 Sep 2018 18:16:23 +0000
Subject: [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1537640183.96.0.956365154283.issue34605@psf.upfronthosting.co.za>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34605>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:16:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:16:29 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537640189.45.0.956365154283.issue34610@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8907

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:16:31 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:16:31 +0000
Subject: [issue23082] pathlib relative_to() can give confusing error message
In-Reply-To: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za>
Message-ID: <1537640191.7.0.956365154283.issue23082@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23082>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:23:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:23:30 +0000
Subject: [issue27513] email.utils.getaddresses does not handle Header objects
In-Reply-To: <1468493411.01.0.0415400585896.issue27513@psf.upfronthosting.co.za>
Message-ID: <1537640610.4.0.956365154283.issue27513@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27513>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:25:20 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 Sep 2018 18:25:20 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537640720.94.0.956365154283.issue34736@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, I'm having trouble thinking of an alternative message that's both accurate and helpful. I think what I _really_ want as a user is for b64decode to reject strings containing "_" and/or "-" as invalid (assuming altchars has been provided), but that would be a backwards-incompatible change, and has already been discussed in #1466065. Not sure it's worth revisiting that discussion.

Maybe just something like "invalid number of base64 characters"? We could even embed the actual number of base64 characters in the error message, which would give the user a clue that some characters are not being considered base64 characters.

I find the "1 more than a multiple of 4" wording a bit clunky, and potentially misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:26:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:26:13 +0000
Subject: [issue33232] Segmentation fault in operator.attrgetter
In-Reply-To: <1522939744.33.0.682650639539.issue33232@psf.upfronthosting.co.za>
Message-ID: <1537640773.22.0.956365154283.issue33232@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33232>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:27:39 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:27:39 +0000
Subject: [issue33194] Path-file objects does not have method to delete itself
 if its a file
In-Reply-To: <1522550854.13.0.467229070634.issue33194@psf.upfronthosting.co.za>
Message-ID: <1537640859.41.0.956365154283.issue33194@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33194>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:31:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:31:42 +0000
Subject: [issue33871] Possible integer overflow in iov_setup()
In-Reply-To: <1529086477.01.0.579493977442.issue33871@psf.upfronthosting.co.za>
Message-ID: <1537641102.58.0.956365154283.issue33871@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/issue33871>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:34:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:34:26 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537641266.96.0.956365154283.issue34610@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 69d0bc1430d2e9cddf0b39054ddcb86dbbe7927e by Serhiy Storchaka in branch '2.7':
[2.7] bpo-34610: Fixed iterator of multiprocessing.managers.DictProxy. (GH-9113). (GH-9500)
https://github.com/python/cpython/commit/69d0bc1430d2e9cddf0b39054ddcb86dbbe7927e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34610>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:35:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 18:35:26 +0000
Subject: [issue34610] Incorrect iteration of Manager.dict() method of the
 multiprocessing module.
In-Reply-To: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>
Message-ID: <1537641326.98.0.956365154283.issue34610@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/issue34610>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:51:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:51:12 +0000
Subject: [issue33194] Path-file objects does not have method to delete itself
 if its a file
In-Reply-To: <1522550854.13.0.467229070634.issue33194@psf.upfronthosting.co.za>
Message-ID: <1537642272.91.0.956365154283.issue33194@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Maybe this can be added to list at the end (https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module) for more visibility.

There was a similar thread in python-ideas to add more functions : https://groups.google.com/forum/#!topic/python-ideas/X9Eim6z31Ik

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33194>
_______________________________________

From report at bugs.python.org  Sat Sep 22 14:52:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:52:28 +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: <1537642348.93.0.956365154283.issue33043@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33043>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:06:26 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 19:06:26 +0000
Subject: [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1537643186.02.0.956365154283.issue31737@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Just as an update current docs site uses Sphinx 1.7.6 and the rendering is correct.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31737>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:08:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 19:08:27 +0000
Subject: [issue30701] Exception parsing certain invalid email address headers
In-Reply-To: <1497864347.44.0.160991763633.issue30701@psf.upfronthosting.co.za>
Message-ID: <1537643307.03.0.956365154283.issue30701@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30701>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:12:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Sep 2018 19:12:11 +0000
Subject: [issue31949] Bugs in PyTraceBack_Print()
In-Reply-To: <1509890795.04.0.213398074469.issue31949@psf.upfronthosting.co.za>
Message-ID: <1537643531.49.0.956365154283.issue31949@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -4257

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31949>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:15:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 19:15:12 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1537643712.91.0.956365154283.issue25597@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:26:31 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 22 Sep 2018 19:26:31 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537644391.14.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

So you don't know of any directly relevant research either.  "Offhand I can't see anything wrong" is better than nothing, but very far from "and we know it will be OK because [see references 1 and 2]".

That Bernstein's DJBX33A has been widely used inspires no confidence whatsoever.  As already explained, Python _did_ use DJBX33X (with a different multiplier), and it systematically screwed up catastrophically in some nested tuple cases already spelled out.  Bernstein himself moved to DJBX33X (using xor instead of addition), and that would have screwed up too on a mix of smallish integers of both signs.

What Python does now, except for changing the multiplier, is essentially version 1a of the _also_ very widely used - but more recent - Fowler/Noll/Vo hash family[1]:

    # Version 1a, recommended over version 1 (which does * before ^).
    hash = offset_basis
    for each octet_of_data to be hashed
        hash = hash xor octet_of_data
        hash = hash * FNV_prime
    return hash

They did extensive studies, and very deliberately use a prime multiplier subject to a number of other constraints.  Not based on "offhand I can't see why not", but based on analysis and running extensive tests.

But, same as with Bernstein's variants (which predate FNV's work on picking "good" multipliers), they were developed in the context of hashing sequences of unsigned 8-bit integers.  There's no a priori reason I can see to expect them to work well in contexts other than that.  Indeed, FNV puts special constraints on the last 8 bits of the primes they pick, presumably because they're only concerned with hashing sequences of 8-bit values.

FYI, for 32-bit hashes they use multiplier 16777619, and for 64-bit 1099511628211.

In the absence of coherent analysis directly relevant to what Python actually needs here, we're all flying blind.  What we do have is over a decade of positive real-world experience with the made-up hacks Python used to worm around a class of gross flaws its prior DJBX33X approach suffered, taking DJBX33X out of its original context and applying it in an area it wasn't designed for.  Which made it close to FNV-1a, but also in a context _that_ wasn't designed for.

However, it _is_ structurally close to FNV-1a, and using prime multipliers was a big deal to them.  "But offhand I don't see why" isn't a good enough reason to abandon that.  To the contrary, in the absence of _proof_ that it doesn't actually matter, I'd be happiest using the same multipliers (given above) and initial values "the standard" FNV-1a algorithms use.

[1] http://www.isthe.com/chongo/tech/comp/fnv/index.html#FNV-1a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:54:19 2018
From: report at bugs.python.org (Socob)
Date: Sat, 22 Sep 2018 19:54:19 +0000
Subject: [issue34660] Replace ableist terms and pejoratives in source code.
In-Reply-To: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>
Message-ID: <1537646059.98.0.956365154283.issue34660@psf.upfronthosting.co.za>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34660>
_______________________________________

From report at bugs.python.org  Sat Sep 22 15:53:59 2018
From: report at bugs.python.org (Socob)
Date: Sat, 22 Sep 2018 19:53:59 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537646039.38.0.956365154283.issue34694@psf.upfronthosting.co.za>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Sat Sep 22 16:08:14 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 20:08:14 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537646894.67.0.956365154283.issue34736@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

> I think what I _really_ want as a user is for b64decode to reject strings containing...

Do you mean you'd like to have this behavior by default?  One can already use validate=True to have invalid characters cause an exception.  I too find it surprising the False is the default, but changing this would be backwards incompatible.

> I find the "1 more than a multiple of 4" wording a bit clunky, and potentially misleading.

I chose that to avoid mentioning "modulu" or "remainder".  I find it straightforward and clear, though admittedly a bit long and clumsy.  I don't believe it is inherently misleading, though.

I like your idea of including the number of base64 characters in the error message.  I find the phrase "base64 characters" ambiguous, though.  I suggest: "Invalid base64-encoded string: number of data characters (13) cannot be 1 more than a multiple of 4"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Sat Sep 22 16:13:10 2018
From: report at bugs.python.org (heiahh)
Date: Sat, 22 Sep 2018 20:13:10 +0000
Subject: [issue34772] Python will suddenly not plot
Message-ID: <1537647190.0.0.956365154283.issue34772@psf.upfronthosting.co.za>


New submission from heiahh <haldorn at gmail.com>:

Hi! I am experience a very strange behavior. As a student I've been using Spyder for my Python coding assignments. But some days ago I wanted to try out the Python environment in Visual Studio. So, I installed python environment in VS. But after that, none of even my simplest codes will produce any plots anymore. Even if I try the exact same code as I for sure know been showing a plot before. Initally I had a error message saying something like "mkl_aa_fw_init_workdivision...." + some more info and directory reference. So after some googling I deleted a mkl file in the directory witch was mentioned in the error message. After that there is no error message, but still no plot. If I try a simple test code like this:

import matplotlib.pyplot as plt
import numpy as np
x = np.linspace(0,5,11)
y = x**2
plt.plot(x,y)

The only thing happening is Ipython console says "Kernel died, restarting". Also in Visual Studio, there is no plot coming up.I have no idea about the cause and how to fix it, even after hours of search and trial. Really frustrating to use time on this instead of my assignments. The only difference befor, when it was working, and after, is that I tried the Visual Studio environment. I highly appreciate help on this issue!

----------
messages: 326112
nosy: heihaa
priority: normal
severity: normal
status: open
title: Python will suddenly not plot
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34772>
_______________________________________

From report at bugs.python.org  Sat Sep 22 16:41:47 2018
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 22 Sep 2018 20:41:47 +0000
Subject: [issue34772] Python will suddenly not plot
In-Reply-To: <1537647190.0.0.956365154283.issue34772@psf.upfronthosting.co.za>
Message-ID: <1537648907.82.0.956365154283.issue34772@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Hey heiahh,

This bug tracker is for issues pertaining to the python interpreter itself. You'd be better off asking your question on the matplotlib bug tracker or stack overflow:

https://github.com/matplotlib/matplotlib/issues

https://stackoverflow.com/

----------
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34772>
_______________________________________

From report at bugs.python.org  Sat Sep 22 16:49:16 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 22 Sep 2018 20:49:16 +0000
Subject: [issue24997] mock.call_args compares as equal and not equal
In-Reply-To: <1441343319.6.0.391788581363.issue24997@psf.upfronthosting.co.za>
Message-ID: <1537649356.05.0.956365154283.issue24997@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Correct, this has been fixed in issue 25195. Closing as 'out of date'. Thanks for triaging!

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24997>
_______________________________________

From report at bugs.python.org  Sat Sep 22 17:20:19 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 22 Sep 2018 21:20:19 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537651219.26.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Thanks for the reference, I never heard of the FNV hash. Unfortunately, I haven't seen a reference for the rationale of how they pick their multiplier.

It's not clear what you are suggesting though. Keep using the FNV-ish hash somehow? Or using a DJBX33A hash with the FNV multiplier?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 17:21:07 2018
From: report at bugs.python.org (Julien Palard)
Date: Sat, 22 Sep 2018 21:21:07 +0000
Subject: [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1537651267.7.0.956365154283.issue31737@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Thanks for the follow up!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31737>
_______________________________________

From report at bugs.python.org  Sat Sep 22 17:38:06 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 22 Sep 2018 21:38:06 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537652286.94.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> the made-up hacks Python used to worm around a class of gross flaws its prior DJBX33X approach suffered, taking DJBX33X out of its original context and applying it in an area it wasn't designed for.

But we know why the DJBX33A hash didn't work (nested tuples), so we can think of the best way to solve that. Python messes with the multiplier, which makes it quite a different hash. Surely, if you believe that the precise choice of multiplier matters a lot, then you should also agree that arbitrarily changing the multiplier in the loop is a bad idea.

My proposal instead is to keep the structure of the DJBX33A hash but change the hash of the individual items to be hashed. That's a much less invasive change to the known algorithm.

Finally, something that I haven't mentioned here: an additional advantage of my approach is that high-order bits become more important:

BEFORE:
>>> L = [n << 60 for n in range(100)]; T = [(a,b,c) for a in L for b in L for c in L]; len(set(hash(x) for x in T))
500000

AFTER:
>>> L = [n << 60 for n in range(100)]; T = [(a,b,c) for a in L for b in L for c in L]; len(set(hash(x) for x in T))
1000000

Again, I'm not claiming that this is a major issue. Just additional evidence that maybe my new hash might actually be slightly better than the existing hash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 20:01:53 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 23 Sep 2018 00:01:53 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537660913.91.0.956365154283.issue34751@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think any change should be made unless we agree that there is a real problem to be solved rather than because the OP is brazenly insistent on forcing through some change.  We shouldn't feel shoved into altering something that we don't agree is broken and into replacing it with something that we're less sure about.  Also, I'm concerned that that patch drops features like the post-addition of a constant and incorporating length signature -- it is as if we're starting from scratch rather than keeping the incremental improvements made over decades.  AFAICT, the only motivation for change is that the OP is relentless; otherwise, none of us would be giving this further thought.  I echo Eric's concern that it is easy to inadvertently make Python worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 20:16:30 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 23 Sep 2018 00:16:30 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537661790.93.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I strive not to believe anything in the absence of evidence ;-)

FNV-1a supplanted Bernstein's scheme in many projects because it works better.  Indeed, Python itself used FNV for string hashing before the security wonks got exercised over collision attacks.  It worked great.  But "better" depends on what you value.  For example, FNV-1a has far better "avalanche" behavior than Bernstein[1].

Please note that I don't _object_ to your code!  It may work fine.  Or it may not in some cases.  The problem is that we have no way to tell.  There's no theory here, just misleading appeals to experience with the algorithms in contexts they were _intended_ to be used in.  Nobody expected some patterns of nested tuples to fail catastrophically before, and nobody expected mixed-sign integers to lead to poor (but not catastrophic) behavior after the former was "repaired".  Nobody now expects the next 10 catastrophes either.

We can only rely on contrived tests and bug reports.  Python's current scheme is unbeatable on that count, because it's the only scheme for which over a decade of experience _in context_ exists.

Which experience says there are no known catastophically bad real cases.  Which is worth a whole lot in a project that's so widely used now.

That said, the "repair" before was at least as much pure hackery as your proposed hackery, and - I agree - completely undercut the _theory_ FNV was based on (although, to be fair, I doubt anyone else _knew_ they were re-inventing a damaged FNV-1a at the time).

So ... since FNV-1a is in fact better in its intended context than the Bernstein one-liners in the same context, how about adding your

    t += (t >> (4 * sizeof(t)));

hack to the _current_ code (& delete the code changing the multiplier)?  Then we could switch to the "official" FNV 32-bit and 64-bit multipliers too, and know at least that "almost everything" about the resulting algorithm is known to work exceedingly well in its original context.

[1] https://sites.google.com/site/murmurhash/avalanche

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 20:27:13 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 23 Sep 2018 00:27:13 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537662433.6.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Raymond, I share your concerns.  There's no reason at all to make gratuitous changes (like dropping the "post-addition of a constant and incorporating length signature"), apart from that there's no apparent reason for them existing to begin with ;-)

Unintended consequences can abound.

Still, the last repair was pretty hacky, and a very well-known and highly respected algorithm (FNV-1a) _is_ hiding under it.  I would like to pursue seeing whether a more direct form of FNV-1a can be rehabilitated to worm around the known problematic cases.  That would also, if successful, give us a principled way to pick a better multiplier for 64-bit boxes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:08:54 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 01:08:54 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
Message-ID: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I am about to review and test, including live testing on Windows, with an eye to merging before the Monday midnight deadline for the coming releases.  At the moment I have no personal preference, nor insight into likely user perferences.

Tal, what is your rationale for the proposal?  Personal preference? Do you think a majority of user will prefer this?  Have you hand-tested (or htested) on both Mac and Linux?

Cheryl, what do you think?

----------
nosy: +cheryl.sabella
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:13:15 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 01:13:15 +0000
Subject: [issue32117] Tuple unpacking in return and yield statements
In-Reply-To: <1511393509.38.0.213398074469.issue32117@psf.upfronthosting.co.za>
Message-ID: <1537665195.26.0.956365154283.issue32117@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8fabae3b00b2ccffd9f7bf4736734ae584ac5829 by Miss Islington (bot) (jChapman) in branch 'master':
bpo-32117: Iterable unpacking in return and yield documentation (GH-9487)
https://github.com/python/cpython/commit/8fabae3b00b2ccffd9f7bf4736734ae584ac5829


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32117>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:20:22 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 01:20:22 +0000
Subject: [issue16360] argparse: comma in metavar causes assertion failure when
 formatting long usage message
In-Reply-To: <1351529348.85.0.0475227022594.issue16360@psf.upfronthosting.co.za>
Message-ID: <1537665622.25.0.956365154283.issue16360@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

I'm closing this since the https://bugs.python.org/issue11874 fix also handles this issue.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16360>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:21:23 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 01:21:23 +0000
Subject: [issue34479] ArgumentParser subparser error display at the wrong level
In-Reply-To: <1535038332.48.0.56676864532.issue34479@psf.upfronthosting.co.za>
Message-ID: <1537665683.34.0.956365154283.issue34479@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34479>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:22:16 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 01:22:16 +0000
Subject: [issue34458] No way to alternate options
In-Reply-To: <1534896831.7.0.56676864532.issue34458@psf.upfronthosting.co.za>
Message-ID: <1537665736.8.0.956365154283.issue34458@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34458>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:22:59 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 23 Sep 2018 01:22:59 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537665779.84.0.956365154283.issue34548@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I did a review on the PR which probably answers your question, but I'll summarize here.

I think consistency in the windows would be good.  Consistency would include (but not limited to) foreground and background color, font style, font size, and behavior such as resizing.  If a user has changed to a dark theme with a font size of 20, then opening up the help or find windows should use that.

So, I think this is a good suggestion, but I think it should be considered within a larger scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:23:23 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 01:23:23 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1537665803.43.0.956365154283.issue34744@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:24:49 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 01:24:49 +0000
Subject: [issue34188] Allow dict choices to "transform" values in argpagse
In-Reply-To: <1532264030.24.0.56676864532.issue34188@psf.upfronthosting.co.za>
Message-ID: <1537665889.99.0.956365154283.issue34188@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34188>
_______________________________________

From report at bugs.python.org  Sat Sep 22 21:49:31 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 01:49:31 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537667371.66.0.956365154283.issue34548@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Investigating the code, I discovered that
  # TODO: get fg/bg from theme."
is my rewrite on 2016 8 31, a3623c8, of
  #elguavas - config placeholders til config stuff completed
Stephen Gava either wrote or modified the file in 2001.  Using the config settings was the original intention, and I thought two years ago and in subsequent revisions that we should at least try it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sat Sep 22 22:34:39 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 02:34:39 +0000
Subject: [issue34046] subparsers -> add_parser doesn't support hyphen char '-'
In-Reply-To: <1530721199.23.0.56676864532.issue34046@psf.upfronthosting.co.za>
Message-ID: <1537670079.35.0.956365154283.issue34046@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34046>
_______________________________________

From report at bugs.python.org  Sat Sep 22 22:54:41 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 02:54:41 +0000
Subject: [issue33396] IDLE: Improve and document help doc viewer
In-Reply-To: <1525147664.58.0.682650639539.issue33396@psf.upfronthosting.co.za>
Message-ID: <1537671281.11.0.956365154283.issue33396@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

8. Use configured colors.  #34548 does this for text viewer, so would be automatic if subclass from that.

9. Upgrade text viewer to include 1, 3, and 4.  It also should use proportional font that help viewer uses.

10 Can Scripts/rst2html be used to directly generate idlelib/help.html from Doc/library/idle.rst?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33396>
_______________________________________

From report at bugs.python.org  Sat Sep 22 23:14:51 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 03:14:51 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1537672491.18.0.956365154283.issue26952@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

If I add an argument to the mutexGroup as suggested by xiang

In [7]: mutexGroup.add_argument('--foo', action='store_true')
Out[7]: _StoreTrueAction(option_strings=['--foo'], dest='foo', nargs=0, const=True, default=False, type=None, choices=None, help=None, metavar=None)
In [8]: parser.print_usage()
usage: ipython3 [-h] -u URL -p PROJECT [--dump] --mergeInput MERGEINPUT
                [--removeDisabled] -c CHECKERS --foo
In [9]: parser.print_help()
usage: ipython3 [-h] -u URL -p PROJECT [--dump] --mergeInput MERGEINPUT
                [--removeDisabled] -c CHECKERS --foo

Sets the checkers of a klocwork project

optional arguments:
  -h, --help            show this help message and exit
  -c CHECKERS, --checkers CHECKERS
                        File which lists the checkers to be enabled.

the argument_group arguments show up in the usage, but without mutually_exclusive markings.  But they don't show up in the help lines.  I suspect all those group arguments will be tested as one mutually exclusive group, not two subgroups.

If I put the argument groups in the main parser, and omit the mutually_exclusive group I get this help:

In [11]: parser.print_help()
usage: ipython3 [-h] -u URL -p PROJECT [--dump] --mergeInput MERGEINPUT
                [--removeDisabled] -c CHECKERS

Sets the checkers of a klocwork project

optional arguments:
  -h, --help            show this help message and exit
  -c CHECKERS, --checkers CHECKERS
                        File which lists the checkers to be enabled.

serverGroup:
  -u URL, --url URL     klocwork server URL.
  -p PROJECT, --project PROJECT
                        klocwork project name.
  --dump                Dump the current checkers config.

mergeGroup:
  --mergeInput MERGEINPUT
                        Input file to merge for the '--checkers' file. Format:
                        checkerName Enabled|Disabled
  --removeDisabled      Disabled checkers will be removed from the '--
                        checkers' file.

The argument groups appear as intended in the help lines.

add_argument_group is inherited from _ActionsContainer.  The parser ArgumentParser also inherits this method.  A possible fix is to override this method in the _MutuallyExclusiveGroup class to raise some sort of not-implemented error.

The documentation, as written, does not suggest or hint that an argument_group can be added to anything but a parser.  But a  stronger disclaimer could be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26952>
_______________________________________

From report at bugs.python.org  Sat Sep 22 23:20:08 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 03:20:08 +0000
Subject: [issue33415] When add_mutually_exclusive_group is built without
 argument, the help breaks with "IndexError: list index out of range"
In-Reply-To: <1525335986.39.0.682650639539.issue33415@psf.upfronthosting.co.za>
Message-ID: <1537672808.11.0.956365154283.issue33415@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

This is duplicate of https://bugs.python.org/issue26952 - argparse help formatter crashes

The same issue - a mutually exclusive group without arguments.

It also deals with issue of nesting groups.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33415>
_______________________________________

From report at bugs.python.org  Sat Sep 22 23:26:59 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 23 Sep 2018 03:26:59 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1537673219.89.0.956365154283.issue26952@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

https://bugs.python.org/issue29553 deals with a similar problem, the usage display when one mutually exclusive group is embedded in another mutually exclusive group.  In that case, usage is displayed, but with some missing brackets.  

As here there are two issues - the usage formatter is brittle, and groups are not designed for nesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26952>
_______________________________________

From report at bugs.python.org  Sat Sep 22 23:37:19 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 23 Sep 2018 03:37:19 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1537673839.03.0.956365154283.issue27117@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8908

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sat Sep 22 23:39:39 2018
From: report at bugs.python.org (thautwarm)
Date: Sun, 23 Sep 2018 03:39:39 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537673979.42.0.956365154283.issue32892@psf.upfronthosting.co.za>


thautwarm <yaoxiansamma at gmail.com> added the comment:

Thank you, Serhiy. 

I learned python ast through ast.parse and pretty print, which prevented me from knowing this useful one.

In fact, I wonder if we could support more species of constant values accepted by ast.Constant?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Sun Sep 23 00:04:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 04:04:24 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537675464.07.0.956365154283.issue34548@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After live testing, I like 'after' at least as well as 'before'.  I also decided that people who selects a dark theme because black on white is obnoxious to their eyes should have their choice on all text panes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 00:04:46 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 04:04:46 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537675486.41.0.956365154283.issue34548@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 00:08:29 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 04:08:29 +0000
Subject: [issue33396] IDLE: Improve and document help doc viewer
In-Reply-To: <1525147664.58.0.682650639539.issue33396@psf.upfronthosting.co.za>
Message-ID: <1537675709.2.0.956365154283.issue33396@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
dependencies: +IDLE: Make TextView use the configured theme colors

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33396>
_______________________________________

From report at bugs.python.org  Sun Sep 23 00:48:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 04:48:58 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537678138.5.0.956365154283.issue34609@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sun Sep 23 01:13:20 2018
From: report at bugs.python.org (Shankar)
Date: Sun, 23 Sep 2018 05:13:20 +0000
Subject: [issue34773] sqlite3 module inconsistently returning only some rows
 from a table
Message-ID: <1537679600.14.0.956365154283.issue34773@psf.upfronthosting.co.za>


New submission from Shankar <shankargopal at myfastmail.com>:

I am running a Python based system on an Android phone. The database is in Sqlite3.  It has been running well for approximately five years now, with various upgraded phones, changes to the system, etc.

However, in the last week or so, there has been a problem in the system that is very peculiar.  One of the tables on the system is called "Invoices" and it currently has approximately 21,500 records in it.  However, reading the database from Python on the phone, using the sqlite3 module, will suddenly return only around 2,400 records.  If I copy the database over to a PC and open it in Python via Linux, the same thing will happen.  If I then open it with the command line `sqlite3` tool, the table will read correctly.  After that, it will start working correctly in Python as well.  If I copy the same database back to the phone, it will work correctly there as well - for approximately three or four hours (i.e., given the usual frequency of my program, about 90 - 120 reads / writes).  Then the problem will return.

I have changed phones in case this was a problem in the phone's memory, but that didn't help.  I have run `vacuum` on the sqlite3 database in question as well, to no avail.  There do not appear to be any other obvious errors in the database. 

What could be the reason for this behaviour?  

Below I've posted some of the code that I use to read the database.  Have cut out some extraneous stuff so you may see variables that are not defined etc. But I'm fairly sure it's not the code, as this same code has been running for years with no trouble.


    def sqlite_exec(sqlcommand, dbname, inserttable = "", insertstuff = None, returndict = 0, override_stop = False, returncheck = False, nojournal = False, onlyjournal = False):
        #...
        if sqlcommand == "insert":
            # Substitute single quotes with double quotes in input text to avoid sqlite syntax errors
            actual_command = "INSERT INTO {0} ({1}) VALUES ({2});".format(inserttable, ", ".join(insertstuff.keys()), ", ".join(["'" + re.sub("'",'"',valuetext) + "'" for valuetext in insertstuff.values()]))
        else:
            actual_command = sqlcommand
        conn = sqlite3.connect(dbname,timeout = 40.0,isolation_level=None, detect_types=sqlite3.PARSE_DECLTYPES)
        if returndict:
            # Using the sqlite module documentation example; this happens to be better suited for our purposes than the sqlite.Row object
            def dict_factory(cursor, row):
                d = dict((col[0],row[idx]) for idx,col in enumerate(cursor.description))
                return d
            conn.row_factory = dict_factory
        sqliteobj = conn.cursor()
        # ...
        if not onlyjournal:
            try:
                sqliteobj.execute(actual_command)
            # except...
        return sqliteobj

----------
components: Extension Modules
messages: 326132
nosy: shankargopal
priority: normal
severity: normal
status: open
title: sqlite3 module inconsistently returning only some rows from a table
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34773>
_______________________________________

From report at bugs.python.org  Sun Sep 23 01:34:58 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 05:34:58 +0000
Subject: [issue34774] IDLE: use theme colors for help viewer
Message-ID: <1537680898.84.0.956365154283.issue34774@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Follow-up to #34548.  Use user-selected color theme for Help => IDLE Help.  (Patch coming.)

----------
messages: 326133
nosy: terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: use theme colors for help viewer
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34774>
_______________________________________

From report at bugs.python.org  Sun Sep 23 01:36:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Sep 2018 05:36:00 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537680959.99.0.956365154283.issue34609@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sun Sep 23 01:48:25 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 05:48:25 +0000
Subject: [issue24307] pip error on windows whose current user name contains
 non-ascii characters
In-Reply-To: <1432779659.79.0.171307025039.issue24307@psf.upfronthosting.co.za>
Message-ID: <1537681705.25.0.956365154283.issue24307@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the patch. Would you like to make a GitHub PR. I think it's a problem with optparse in general while trying to have a default value with unicode character and %default in the help string. The same code is present in Python 3 but strings are unicode by default. An example code will be below : 

# -*- coding: utf-8 -*-

from optparse import OptionParser

parser = OptionParser()
parser.add_option("-f", "--file", dest="filename",
                  help="write to FILE. Default value %default", metavar="FILE", default="???")

(options, args) = parser.parse_args()

$ python3.6 ../backups/bpo24307.py --help
Usage: bpo24307.py [options]

Options:
  -h, --help            show this help message and exit
  -f FILE, --file=FILE  write to FILE. Default value ???

$ python2.7 ../backups/bpo24307.py --help
Traceback (most recent call last):
  File "../backups/bpo24307.py", line 9, in <module>
    (options, args) = parser.parse_args()
  File "/usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1400, in parse_args
    stop = self._process_args(largs, rargs, values)
  File "/usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1440, in _process_args
    self._process_long_opt(rargs, values)
  File "/usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1515, in _process_long_opt
    option.process(opt, value, values, self)
  File "/usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 789, in process
    self.action, self.dest, opt, value, values, parser)
  File "/usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 811, in take_action
    parser.print_help()
  File "/usr/local/Cellar/python at 2/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1670, in print_help
    file.write(self.format_help().encode(encoding, "replace"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 148: ordinal not in range(128)


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24307>
_______________________________________

From report at bugs.python.org  Sun Sep 23 01:53:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 05:53:08 +0000
Subject: [issue34774] IDLE: use theme colors for help viewer
In-Reply-To: <1537680898.84.0.956365154283.issue34774@psf.upfronthosting.co.za>
Message-ID: <1537681988.88.0.956365154283.issue34774@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +8909

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34774>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:08:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 06:08:18 +0000
Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass
 inheritance
In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
Message-ID: <1537682898.14.0.956365154283.issue21919@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21919>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:09:12 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 06:09:12 +0000
Subject: [issue34774] IDLE: use theme colors for help viewer
In-Reply-To: <1537680898.84.0.956365154283.issue34774@psf.upfronthosting.co.za>
Message-ID: <1537682952.02.0.956365154283.issue34774@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If HelpText is ever subclassed from a view text class, the color_config and call will be deleted.  But changing the two fixed colors will be needed in any case.

The background option in
  self.tag_configure('pre', font=(fixedfont, 12), background='#f6f6ff')
was intended to give fixed-pitch words a very light bluish background, but I cannot see any difference, so deleting it is no loss.

For the pre block, "background='#eeffcc'" gives the block a yellow background that matches the one used in online docs, as viewed by me with Firefox.  So it is made conditional on the foreground color being the default solid black (which is different from tk's 'black').

Border colors appear to be fixed at some black, making the border invisible on a black or near-black background.  But it does not seem worthwhile to try to decide when to omit it.

----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34774>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:09:58 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 06:09:58 +0000
Subject: [issue34774] IDLE: use theme colors for help viewer
In-Reply-To: <1537680898.84.0.956365154283.issue34774@psf.upfronthosting.co.za>
Message-ID: <1537682998.48.0.956365154283.issue34774@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have tested this on Windows with both light and dark themes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34774>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:13:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Sep 2018 06:13:03 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537683183.74.0.956365154283.issue34421@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4b860fd777e983f5d2a6bd1288e2b53099c6a803 by Serhiy Storchaka in branch 'master':
bpo-34421: Improve distutils logging for non-ASCII strings. (GH-9126)
https://github.com/python/cpython/commit/4b860fd777e983f5d2a6bd1288e2b53099c6a803


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:13:14 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 06:13:14 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537683194.25.0.956365154283.issue34421@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8910
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:13:23 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 06:13:23 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537683203.19.0.956365154283.issue34421@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:19:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 06:19:56 +0000
Subject: [issue9350] add remove_argument_group to argparse
In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za>
Message-ID: <1537683596.18.0.956365154283.issue9350@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9350>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:32:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 06:32:17 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537684337.16.0.956365154283.issue34609@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: terry.reedy -> 
components:  -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:32:35 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 06:32:35 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537684355.02.0.956365154283.issue34670@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9fb051f032c36b9f6086b79086b4d6b7755a3d70 by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-34670: Add TLS 1.3 post handshake auth (GH-9460)
https://github.com/python/cpython/commit/9fb051f032c36b9f6086b79086b4d6b7755a3d70


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:33:11 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 06:33:11 +0000
Subject: [issue17185] unittest mock create_autospec doesn't correctly replace
 mocksignature
In-Reply-To: <1360621900.03.0.519438692167.issue17185@psf.upfronthosting.co.za>
Message-ID: <1537684391.45.0.956365154283.issue17185@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17185>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:34:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 06:34:17 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537684457.33.0.956365154283.issue34548@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The first follow-up, #34774, makes the help viewer use the current theme. It would be good if it were separately tested on Linux/Mac, as it uses multiple tags.

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:41:45 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 23 Sep 2018 06:41:45 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537684905.74.0.956365154283.issue34670@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8912

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Sun Sep 23 02:51:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Sep 2018 06:51:00 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537685460.95.0.956365154283.issue34421@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8913

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:00:03 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 23 Sep 2018 07:00:03 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537686003.04.0.956365154283.issue34670@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8914

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:02:08 2018
From: report at bugs.python.org (Roger Aiudi)
Date: Sun, 23 Sep 2018 07:02:08 +0000
Subject: [issue34775] pathlib.PurePath division raises TypeError instead of
 returning NotImplemented
Message-ID: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za>


New submission from Roger Aiudi <aiudirog at gmail.com>:

PurePath.__truediv__ and __rtruediv__ raise a TypeError when passed something which is not an instance of string or PurePath. This prevents creating any sort of compatible class that doesn't inherit from the previously mentioned types.

----------
components: Library (Lib)
messages: 326140
nosy: Roger Aiudi
priority: normal
pull_requests: 8915
severity: normal
status: open
title: pathlib.PurePath division raises TypeError instead of returning NotImplemented
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/issue34775>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:22:56 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 07:22:56 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537687376.13.0.956365154283.issue34670@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2756ef31656399a120589b7aa19c32e2b91a4758 by Miss Islington (bot) (Christian Heimes) in branch '3.7':
[3.7] bpo-34670: Add TLS 1.3 post handshake auth (GH-9460) (GH-9505)
https://github.com/python/cpython/commit/2756ef31656399a120589b7aa19c32e2b91a4758


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:23:05 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 07:23:05 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537687385.13.0.956365154283.issue34670@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 94812f717dde8b11a9ad9c0fd5be66ff9bd53f58 by Miss Islington (bot) (Christian Heimes) in branch '3.6':
[3.6] bpo-34670: Add TLS 1.3 post handshake auth (GH-9460) (GH-9507)
https://github.com/python/cpython/commit/94812f717dde8b11a9ad9c0fd5be66ff9bd53f58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:31:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Sep 2018 07:31:56 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537687916.44.0.956365154283.issue34421@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c73df53569f86d0c7742bafa55958c53d57a02e4 by Serhiy Storchaka in branch '3.7':
bpo-34421: Improve distutils logging for non-ASCII strings. (GH-9126) (GH-9506)
https://github.com/python/cpython/commit/c73df53569f86d0c7742bafa55958c53d57a02e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:32:07 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 07:32:07 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537687927.37.0.956365154283.issue34421@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8916

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:50:37 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 07:50:37 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537689037.32.0.956365154283.issue17239@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 17b1d5d4e36aa57a9b25a0e694affbd1ee637e45 by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-17239: Disable external entities in SAX parser (GH-9217)
https://github.com/python/cpython/commit/17b1d5d4e36aa57a9b25a0e694affbd1ee637e45


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:54:02 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 07:54:02 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537689242.89.0.956365154283.issue34421@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0b67995bfa45393585e2e0017c82c706c4a04b04 by Miss Islington (bot) in branch '3.6':
bpo-34421: Improve distutils logging for non-ASCII strings. (GH-9126) (GH-9506)
https://github.com/python/cpython/commit/0b67995bfa45393585e2e0017c82c706c4a04b04


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:58:01 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 23 Sep 2018 07:58:01 +0000
Subject: [issue34775] pathlib.PurePath division raises TypeError instead of
 returning NotImplemented
In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za>
Message-ID: <1537689481.08.0.956365154283.issue34775@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report and for the PR. Could you give us a little bit more information about your use case? Couldn't you make the class you want to use implement the __fspath__ protocol?

    import pathlib as p

    class Spam:
        def __fspath__(self):
            return 'pathlib.py'

And we can use it like:

    >>> p.Path('Lib') / Spam()
    PosixPath('Lib/pathlib.py')
    >>> (p.Path('Lib') / Spam()).exists()
    True

(3.4 and 3.5 are in security-fix-only mode, so I removed them from the versions field.)

----------
nosy: +berker.peksag
stage:  -> test needed
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34775>
_______________________________________

From report at bugs.python.org  Sun Sep 23 03:58:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 23 Sep 2018 07:58:46 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537689526.03.0.956365154283.issue17239@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8917

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Sun Sep 23 04:02:49 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 23 Sep 2018 08:02:49 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537689769.1.0.956365154283.issue17239@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Sun Sep 23 04:20:43 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 08:20:43 +0000
Subject: [issue34775] pathlib.PurePath division raises TypeError instead of
 returning NotImplemented
In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za>
Message-ID: <1537690843.92.0.956365154283.issue34775@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34775>
_______________________________________

From report at bugs.python.org  Sun Sep 23 04:29:19 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 23 Sep 2018 08:29:19 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537691359.62.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> We shouldn't feel shoved into altering something that we don't agree is broken

It *is* broken. You are just denying the reality.

That's also the reason that I'm insisting so much: I don't want to push my personal fix (despite that it may seem so), I want to fix a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sun Sep 23 04:50:57 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 23 Sep 2018 08:50:57 +0000
Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass
 inheritance
In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
Message-ID: <1537692657.06.0.956365154283.issue21919@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21919>
_______________________________________

From report at bugs.python.org  Sun Sep 23 04:51:32 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 23 Sep 2018 08:51:32 +0000
Subject: [issue17185] unittest mock create_autospec doesn't correctly replace
 mocksignature
In-Reply-To: <1360621900.03.0.519438692167.issue17185@psf.upfronthosting.co.za>
Message-ID: <1537692692.94.0.956365154283.issue17185@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17185>
_______________________________________

From report at bugs.python.org  Sun Sep 23 06:45:30 2018
From: report at bugs.python.org (David Hagen)
Date: Sun, 23 Sep 2018 10:45:30 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
Message-ID: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>


New submission from David Hagen <david at drhagen.com>:

The new postponed annotations have an unexpected interaction with dataclasses. Namely, you cannot get the type hints of any of the data classes methods.

For example, I have some code that inspects the type parameters of a class's `__init__` method. (The real use case is to provide a default serializer for the class, but that is not important here.)  

```
from dataclasses import dataclass
from typing import get_type_hints

class Foo:
    pass

@dataclass
class Bar:
    foo: Foo

print(get_type_hints(Bar.__init__))
```

In Python 3.6 and 3.7, this does what is expected; it prints `{'foo': <class '__main__.Foo'>, 'return': <class 'NoneType'>}`.

However, if in Python 3.7, I add `from __future__ import annotations`, then this fails with an error:

```
NameError: name 'Foo' is not defined
```

I know why this is happening. The `__init__` method is defined in the `dataclasses` module which does not have the `Foo` object in its environment, and the `Foo` annotation is being passed to `dataclass` and attached to `__init__` as the string `"Foo"` rather than as the original object `Foo`, but `get_type_hints` for the new annotations only does a name lookup in the module where `__init__` is defined not where the annotation is defined.

I know that the use of lambdas to implement PEP 563 was rejected for performance reasons. I could be wrong, but I think this was motivated by variable annotations because the lambda would have to be constructed each time the function body ran. I was wondering if I could motivate storing the annotations as lambdas in class bodies and function signatures, in which the environment is already being captured and is code that usually only runs once.

Original mailing list discussion: https://mail.python.org/pipermail/python-dev/2018-September/155289.html

----------
messages: 326148
nosy: drhagen
priority: normal
severity: normal
status: open
title: Postponed annotations break inspection of dataclasses
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Sun Sep 23 06:59:46 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 Sep 2018 10:59:46 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537700386.26.0.956365154283.issue22490@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The pull request is wrong, the use of __PYVENV_LAUNCHER__ in pythonw.c is correct and should not be removed. Where the current code goes wrong is that it doesn't clear the environment as soon as possible.

This patch should basically do the trick (but requires testing and probably adjustments to some other code):

diff --git a/Modules/main.c b/Modules/main.c
index 3a6cf31fc8..c673d06c56 100644
--- a/Modules/main.c
+++ b/Modules/main.c
@@ -1360,6 +1360,8 @@ config_init_program_name(_PyCoreConfig *config)
                                          "variable", (Py_ssize_t)len);
             }
             config->program_name = program_name;
+
+           unsetenv("__PYVENV_LAUNCHER__");
             return _Py_INIT_OK();
         }
     }


Some background information on why and environment variable is used on macOS when using a framework install:  To use system GUI frameworks on macOS the executable should be part of an application bundle (".app"), otherwise a number of APIs just don't work (which would affect the use of for example Tkinter in command-line scripts).  To work around this platform limitation a framework install of Python has the actual interpreter in a Python.app bundle stored in the framework, and "{sys.prefix}/bin/python" is a small stub executable that launches the real interpreter. 

The environment variable is used to pass the path to the stub executable to the real interpreter, to enable it to behave correctly (look at venv configuration files, have sys.executable be correct, ...). 

That said, looking at the code it might be possible to do away with the environment variable after call because the code in pythonw.c suggests the the environment variable is only necessary for OSX 10.5 or earlier.

I'm working on an alternative pull request that implements the patch I included inline in this message, with some additional documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 07:11:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Sep 2018 11:11:42 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <1537701102.04.0.956365154283.issue34421@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sun Sep 23 08:23:23 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 12:23:23 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537705403.84.0.956365154283.issue34548@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c87d9f406bb23657c1b4cd63017bb7bd7693a1fb by Miss Islington (bot) (Tal Einat) in branch 'master':
bpo-34548: IDLE: use configured theme colors in TextView (GH-9008)
https://github.com/python/cpython/commit/c87d9f406bb23657c1b4cd63017bb7bd7693a1fb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 08:23:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 12:23:40 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537705420.79.0.956365154283.issue34548@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8919
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 08:23:48 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 12:23:48 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537705428.48.0.956365154283.issue34548@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8920

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 09:02:05 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 23 Sep 2018 13:02:05 +0000
Subject: [issue34774] IDLE: use theme colors for help viewer
In-Reply-To: <1537680898.84.0.956365154283.issue34774@psf.upfronthosting.co.za>
Message-ID: <1537707725.47.0.956365154283.issue34774@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

This is working on Ubuntu.  Probably not a big deal, but because the help viewer is not modal, it's possible to change the theme with the help window open and the text isn't updated on the help window.  If the help is closed and reopened, then the new theme appears.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34774>
_______________________________________

From report at bugs.python.org  Sun Sep 23 09:31:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 13:31:40 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537709500.71.0.956365154283.issue34548@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset aeadf59e457ca0ee20983eb1ed78b348f0b453e3 by Miss Islington (bot) in branch '3.7':
bpo-34548: IDLE: use configured theme colors in TextView (GH-9008)
https://github.com/python/cpython/commit/aeadf59e457ca0ee20983eb1ed78b348f0b453e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 09:31:55 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Sep 2018 13:31:55 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537709515.2.0.956365154283.issue34548@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6b48f9854e2ae35fd74bcd359451eb37ae65f798 by Miss Islington (bot) in branch '3.6':
bpo-34548: IDLE: use configured theme colors in TextView (GH-9008)
https://github.com/python/cpython/commit/6b48f9854e2ae35fd74bcd359451eb37ae65f798


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 09:33:30 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 23 Sep 2018 13:33:30 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537709610.03.0.956365154283.issue34548@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the review, discussion and approval, Cheryl and Terry!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 09:35:55 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 23 Sep 2018 13:35:55 +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: <1537709755.97.0.956365154283.issue32990@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8921
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32990>
_______________________________________

From report at bugs.python.org  Sun Sep 23 09:41:17 2018
From: report at bugs.python.org (Tulir Asokan)
Date: Sun, 23 Sep 2018 13:41:17 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1537710077.32.0.956365154283.issue19081@psf.upfronthosting.co.za>


Change by Tulir Asokan <tulir at maunium.net>:


----------
nosy: +tulir

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:34:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:34:27 +0000
Subject: [issue28418] Raise Deprecation warning for tokenize.generate_tokens
In-Reply-To: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za>
Message-ID: <1537713267.04.0.956365154283.issue28418@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I just stumbled upon this issue while triaging. With the related issue https://bugs.python.org/issue12486 closed making generate_tokens public can this issue be closed since the original issue is not valid?

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28418>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:35:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:35:22 +0000
Subject: [issue32915] Running Python 2 with -3 flag doesn't complain about
 cmp/__cmp__
In-Reply-To: <1519342915.53.0.467229070634.issue32915@psf.upfronthosting.co.za>
Message-ID: <1537713322.0.0.956365154283.issue32915@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32915>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:41:44 2018
From: report at bugs.python.org (Roger Aiudi)
Date: Sun, 23 Sep 2018 14:41:44 +0000
Subject: [issue34775] pathlib.PurePath division raises TypeError instead of
 returning NotImplemented
In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za>
Message-ID: <1537713704.83.0.956365154283.issue34775@psf.upfronthosting.co.za>


Roger Aiudi <aiudirog at gmail.com> added the comment:

Using your above example, my use case is returning an instance of Spam instead of PurePath from the division operation. The Spam class would have extra properties and methods for dealing with a substructure of our file system that can exist in different places, so being able to use a normal Path to locate it later with the division operation would be useful. (I know I could have a method that would do that, but I personally think reading the division left to right is clearer.)

The current implementation makes this impossible and I found raising a TypeError to be inconsistent with how Python handles operator overloading in the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34775>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:42:49 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:42:49 +0000
Subject: [issue33340] Inaccurate docs on `import` behaviour
In-Reply-To: <1524477096.11.0.682650639539.issue33340@psf.upfronthosting.co.za>
Message-ID: <1537713769.1.0.956365154283.issue33340@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33340>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:43:21 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 Sep 2018 14:43:21 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537713801.51.0.956365154283.issue22490@psf.upfronthosting.co.za>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
pull_requests: +8922

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:47:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:47:24 +0000
Subject: [issue33947] Dataclasses can raise RecursionError in __repr__
In-Reply-To: <1529758726.17.0.56676864532.issue33947@psf.upfronthosting.co.za>
Message-ID: <1537714044.53.0.956365154283.issue33947@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33947>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:51:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:51:05 +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: <1537714265.51.0.956365154283.issue33002@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33002>
_______________________________________

From report at bugs.python.org  Sun Sep 23 10:53:28 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 Sep 2018 14:53:28 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537714408.88.0.956365154283.issue22490@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've added PR 9516 that just clears __PYVENV_LAUNCHER__ from the environment as soon as it is no longer needed.

A more involved change would be to change both the interpreter and the stub executable to avoid the need to use an environment variable in the first place:

- Add and "-X" flag to the interpreter to pass the information that's currently passed using an environment variable
- Change pythonw.c to add this new option to the argv vector.

This would be slightly cleaner, at the cost of having more complicated code (and is a change that would IMHO not qualify for a back port, while my current PR is minimal enough for a back port)

Note that both with and without this PR sys.executable points to the python executable inside the venv (when using a env).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:00:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:00:12 +0000
Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in
 two same calls
In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za>
Message-ID: <1537714812.55.0.956365154283.issue26752@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26752>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:03:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:03:19 +0000
Subject: [issue9134] sre bug: lastmark_save/restore
In-Reply-To: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>
Message-ID: <1537714999.92.0.956365154283.issue9134@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9134>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:13:50 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 15:13:50 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537715630.18.0.956365154283.issue34609@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

The Pdb bug and the IDLE bug are unrelated to each other:

   Pdb fails because it is attempting to import the readline module every time its `trace_dispatch` is called, and the import implementation is not reentrant in that way.

   IDLE is crashing because the uninitialized _ModuleLock instance raised an error when `repr` is called, and the IDLE debugger lacks code to catch that exception.

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:15:25 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:15:25 +0000
Subject: [issue27261] io.BytesIO.truncate does not work as advertised
In-Reply-To: <1465332777.38.0.718878645897.issue27261@psf.upfronthosting.co.za>
Message-ID: <1537715725.75.0.956365154283.issue27261@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27261>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:16:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:16:52 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1537715812.49.0.956365154283.issue27154@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27154>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:30:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:30:06 +0000
Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5
In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>
Message-ID: <1537716606.85.0.956365154283.issue25403@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25403>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:36:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:36:15 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
In-Reply-To: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>
Message-ID: <1537716975.11.0.956365154283.issue26144@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this was fixed with https://bugs.python.org/issue34200 though the patch was not applied to 3.5 and 3.4 as they are in security bug fixes mode.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26144>
_______________________________________

From report at bugs.python.org  Sun Sep 23 11:42:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 15:42:50 +0000
Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free
In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>
Message-ID: <1537717370.58.0.956365154283.issue26000@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this still reproducible? On master (Python 3.8) with a debug build it throws a SyntaxError. I don't have Python 3.5 installed to check this though

$ ./python.exe
Python 3.8.0a0 (heads/master:c87d9f406b, Sep 23 2018, 19:48:30)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
?  cpython git:(master) ./python.exe -c 'with open("vuln.py", "wb") as f: f.write(b"\x61\x73\x00\x0a\x79\x6e\x63\x5c\x0a\xef")'
?  cpython git:(master) ? ./python.exe vuln.py
  File "vuln.py", line 2
SyntaxError: Non-UTF-8 code starting with '\xef' in file vuln.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
?  cpython git:(master) ? ./python.exe -c 'with open("vuln2.py", "wb") as f: f.write(b"\x61\x73\x00\x0a\x79\x6e\x63\x5c\x0a\x00\x0d\xdd")'
?  cpython git:(master) ? ./python.exe vuln2.py
  File "vuln2.py", line 3
SyntaxError: Non-UTF-8 code starting with '\xdd' in file vuln2.py on line 3, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26000>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:01:54 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:01:54 +0000
Subject: [issue33553] Documentation improvement proposal for multiprocessing
In-Reply-To: <1526541318.79.0.682650639539.issue33553@psf.upfronthosting.co.za>
Message-ID: <1537718514.36.0.956365154283.issue33553@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33553>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:07:47 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:07:47 +0000
Subject: [issue26374] concurrent_futures Executor.map semantics better
 specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1537718867.91.0.956365154283.issue26374@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There were some improvements made that clarify differences between builtin map with https://bugs.python.org/issue32306 and https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26374>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:07:48 2018
From: report at bugs.python.org (Jose Gama)
Date: Sun, 23 Sep 2018 16:07:48 +0000
Subject: [issue34777] urllib.request accepts anything as a header parameter
 for some URLs
Message-ID: <1537718868.74.0.956365154283.issue34777@psf.upfronthosting.co.za>


New submission from Jose Gama <josephgama at yahoo.com>:

It is possible to use urllib.request defining a header that can be junk in some cases and still get the contents without any warning or error.
The behavior depends on the URL and also on the header.

----------
components: IO
files: header-illegal.py
messages: 326162
nosy: tuxcell
priority: normal
severity: normal
status: open
title: urllib.request accepts anything as a header parameter for some URLs
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47819/header-illegal.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:13:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:13:17 +0000
Subject: [issue25567] shlex.quote doesn't work on bytestrings
In-Reply-To: <1446814343.82.0.823951892686.issue25567@psf.upfronthosting.co.za>
Message-ID: <1537719197.19.0.956365154283.issue25567@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the patch since the current workflow uses GitHub PR the patch can be made as a PR to move it forward. It seems there are some conflicts as I tried to apply the attached patch against latest master.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25567>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:15:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:15:22 +0000
Subject: [issue24653] Mock.assert_has_calls([]) is surprising for users
In-Reply-To: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za>
Message-ID: <1537719322.51.0.956365154283.issue24653@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24653>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:16:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:16:06 +0000
Subject: [issue20463] sqlite dumpiter dumps invalid script when virtual tables
 are used
In-Reply-To: <1391198256.46.0.541752876278.issue20463@psf.upfronthosting.co.za>
Message-ID: <1537719366.55.0.956365154283.issue20463@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20463>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:35:44 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 23 Sep 2018 16:35:44 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537720544.07.0.956365154283.issue34776@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

[Adding to nosy people who were on the original email]

Copying (part of) my response from the email thread:

These work:
print(get_type_hints(Bar.__init__, globals()))
print(get_type_hints(Bar.__init__, Bar.__module__))

But I agree that maybe doing something with dataclasses to address this would be good. Especially as the first one requires being in the same module as Foo.

See this for Yury's self-described "hack-ish fix we can use" until we do something better:

https://gist.github.com/1st1/37fdd3cc84cd65b9af3471b935b722df

----------
nosy: +eric.smith, gvanrossum, ivan, lukasz.langa, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:38:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 16:38:19 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
In-Reply-To: <1537664934.71.0.956365154283.issue34548@psf.upfronthosting.co.za>
Message-ID: <1537720699.79.0.956365154283.issue34548@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I removed 2.7 because I stopped routinely backporting to 2.7 some time ago because a) renaming files (which could not be backported) and using ttk widgets (ditto) made it much harder, and b) it was empirically too easy to introduce regressions without *thorough* hand testing. Given that most beginners now start with 3.x, I prefer merging more patches for current 3.x.

----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Sun Sep 23 12:53:12 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 23 Sep 2018 16:53:12 +0000
Subject: [issue28418] Raise Deprecation warning for tokenize.generate_tokens
In-Reply-To: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za>
Message-ID: <1537721592.52.0.956365154283.issue28418@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

Yes, I think this can be closed now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28418>
_______________________________________

From report at bugs.python.org  Sun Sep 23 13:16:46 2018
From: report at bugs.python.org (James Lu)
Date: Sun, 23 Sep 2018 17:16:46 +0000
Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636
In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za>
Message-ID: <1537723006.59.0.956365154283.issue22499@psf.upfronthosting.co.za>


Change by James Lu <bitflip3 at gmail.com>:


----------
nosy: +tacocat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22499>
_______________________________________

From report at bugs.python.org  Sun Sep 23 13:18:16 2018
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 23 Sep 2018 17:18:16 +0000
Subject: [issue9134] sre bug: lastmark_save/restore
In-Reply-To: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>
Message-ID: <1537723096.87.0.956365154283.issue9134@psf.upfronthosting.co.za>


Change by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9134>
_______________________________________

From report at bugs.python.org  Sun Sep 23 13:51:38 2018
From: report at bugs.python.org (Laurent Gautier)
Date: Sun, 23 Sep 2018 17:51:38 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
Message-ID: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>


New submission from Laurent Gautier <lgautier at gmail.com>:

The buffer protocol is accounting for the row-major or column-major arrays, and that information is shown in the attributes, `c_contiguous` and `f_contiguous` respectively, of a memoryview object.

Using the method `cast` allows one to specify a shape but does not allow
to specify whether row or column major:

```
# column-major 3x2 array of bytes that was serialized
b = bytearray([1,2,3,4,5,6])

mv = memoryview(b)
mv_b = mv.cast('b', shape=(3,2))
```

The result object is believed to be row-major and little can be done
to correct it:


```
>>> mv_int.c_contiguous
True
>>> mv_int.c_contiguous = False
AttributeError: attribute 'c_contiguous' of 'memoryview' objects is not writable
```

----------
components: Interpreter Core
messages: 326167
nosy: lgautier
priority: normal
severity: normal
status: open
title: Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve
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/issue34778>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:14:03 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 18:14:03 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1537726443.04.0.956365154283.issue34609@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The IDLE issue here is a duplicate of #33065, where the OP said that only step, not go, created the problem.  ppperry, thank you for the solution.

Cheryl, please open a new issue for the pdb bug with a little more detail and ppperry's comment.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE debugger: problem importing user created module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:23:32 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 18:23:32 +0000
Subject: [issue33065] IDLE debugger: problem importing user created module
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1537727012.46.0.956365154283.issue33065@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:25:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 23 Sep 2018 18:25:32 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537727132.18.0.956365154283.issue34776@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8923
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:25:53 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 23 Sep 2018 18:25:53 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537727153.93.0.956365154283.issue22490@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Is it documented anywhere how to do a framework build of Python? When I try to do a framework build by running `./configure --enable-framework` then `make`, `./python.exe` emits the following:

dyld: Library not loaded: /Library/Frameworks/Python.framework/Versions/3.8/Python
  Referenced from: /Users/jaraco/code/public/cpython/./python.exe
  Reason: image not found
Aborted (core dumped)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:29:35 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 18:29:35 +0000
Subject: [issue33065] IDLE debugger crashes when `repr` raises an exception
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1537727375.74.0.956365154283.issue33065@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: IDLE debugger: problem importing user created module -> IDLE debugger crashes when `repr` raises an exception

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:31:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 23 Sep 2018 18:31:42 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537727502.57.0.956365154283.issue34776@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> See this for Yury's self-described "hack-ish fix we can use" until we do something better:

Actually, I think I found a better solution that doesn't require any changes to anything besides dataclasses.

Currently, dataclasses uses 'exec()' function to dynamically create methods like '__init__'.  The generated code for '__init__' needs to access MISSING and _HAS_DEFAULT_FACTORY constants from the dataclasses module.  To do that, we compile the code with 'exec()' with globals set to a dict with {MISSING, _HAS_DEFAULT_FACTORY} keys in it.  This does the trick, but '__init__.__globals__' ends up pointing to that custom dict, instead of pointing to the module's dict.

The other way around is to use a closure around __init__ to inject MISSING and _HAS_DEFAULT_FACTORY values *and* to compile the code in a proper __dict__ of the module the dataclass was defined in.  Please take a look at the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:33:27 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 23 Sep 2018 18:33:27 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537727607.49.0.956365154283.issue34776@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

And FWIF I don't think we need to use lambdas for annotations to solve issues like this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:39:03 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 18:39:03 +0000
Subject: [issue34779] IDLE internals show up in tracebacks when returning
 objects that cannot be `repr`ed
Message-ID: <1537727943.66.0.956365154283.issue34779@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

>>> class NoRepr:
	def __repr__(self):
		raise ValueError
>>> NoRepr()
Traceback (most recent call last):
  File "<pyshell#44>", line 1, in <module>
    NoRepr()
  File "C:\Program Files\Python37\lib\idlelib\rpc.py", line 617, in displayhook
    text = repr(value)
  File "<pyshell#43>", line 3, in __repr__
    raise ValueError
ValueError

What should happen in this case isn't exactly clear, but the current traceback is wrong in multiple ways.

----------
assignee: terry.reedy
components: IDLE
messages: 326172
nosy: ppperry, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE internals show up in tracebacks when returning objects that cannot be `repr`ed
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34779>
_______________________________________

From report at bugs.python.org  Sun Sep 23 15:13:59 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 23 Sep 2018 19:13:59 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537730039.09.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Oh, I don't agree that it's "broken" either.  There's still no real-world test case here demonstrating catastrophic behavior, neither even a contrived test case demonstrating that, nor a coherent characterization of what "the problem" is.

I'm nevertheless open to making improvements, but keeping in mind foremost that _all_ changes are potentially damaging to patterns of data we know nothing about precisely because they've been working fine for many years.  So, e.g., there's no chance that gratuitous changes will be accepted.  For example, don't _like_ adding 97531UL at the end?  Tough luck - it's staying, and it's not worth one word of argument.

To my eyes, the _strongest_ case in all these messages is for boosting the multiplier size on 64-bit boxes.  That's principled and well-motivated.  Python itself changed the multiplier from 3 to 1000003 long ago for the same reasons.  But that apparently has nothing to do with "the problem" this report was opened about ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sun Sep 23 15:30:53 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 Sep 2018 19:30:53 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537731053.93.0.956365154283.issue22490@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

To use the framework build you either have to install, use or set "DYLD_FRAMEWORK_PATH" in the environment (See the definition of RUNFORSHARED in Makefile for the value to use).

To properly test the this issue you have to install (or trick the system into thinking there is an install: I created a symlink in /Library/Frameworks/Python.framework/Versions: /Library/Frameworks/Python.framework/Versions/3.8 -> /Users/ronald/Projects/python/github/cpython-ronald/build/Python.framework/Versions/3.8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:00:35 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 23 Sep 2018 20:00:35 +0000
Subject: [issue34780] Hang on startup if stdin refers to a pipe with an
 outstanding concurrent operation on Windows
Message-ID: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

In the following code inspired by a production issue I had to debug recently subprocess.call() won't return:

import os
import subprocess
import sys
import time

r, w = os.pipe()
p1 = subprocess.Popen([sys.executable, '-c',
                       'import sys; sys.stdin.read()'],
                      stdin=r)

time.sleep(1)
subprocess.call([sys.executable, '-c', ''], stdin=r)

os.close(w)
p1.wait()

The underlying reason is the same as in #22976. Python performs certain operations on stdin during it's initialization (different in 2.7 and 3.x), which block because there is an outstanding ReadFile() on the pipe end stdin refers to. Assuming that subprocess.call() runs some app that doesn't use stdin at all, if a developer doesn't control how the app is run (which was my case), I don't see any way to workaround this in pure Python. (An obvious workaround is to make a wrapper which closes stdin or redirects it to something else, but this wrapper can't be run with CPython).

I propose to fix this in CPython. The details are slightly different for 2.7 and 3.x.

2.7 calls fstat(stdin) in dircheck() (Objects/fileobject.c). This hangs because msvcrt calls PeekNamedPipe() if stdin refers to a pipe. Ironically, this fstat() call is completely useless on Windows because msvcrt never sets S_IFDIR in st_mode (it can't distinguish between a file and a directory because it uses GetFileType() and doesn't perform extra checks). I've implemented a PR that skips dircheck() on Windows. (If we do want to add a proper dircheck() to 2.7, it should do something similar to 3.x).

3.x performs the dir check without relying on fstat(), but it also calls lseek() (in _buffered_init() (Modules/_io/bufferedio.c), if removed, there is another one in _io_TextIOWrapper___init___impl (Modules/_io/textio.c). mscvrt calls SetFilePointerEx(), which hangs too, which is somewhat surprising because its docs [1] say:

You cannot use the SetFilePointerEx function with a handle to a nonseeking device such as a pipe or a communications device.

The wording is unclear though -- it doesn't say what happens if I try. lseek() docs [2] contain the following:

On devices incapable of seeking (such as terminals and printers), the return value is undefined.

In practice, lseek() succeeds on pipes on Windows, but is nearly useless:

Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
>>> import os
>>> r, w = os.pipe()
>>> os.write(w, b'xyz')
3
>>> os.lseek(r, 0, os.SEEK_CUR)
0
>>> os.lseek(r, 0, os.SEEK_END)
3
>>> os.lseek(r, 2, os.SEEK_SET)
2
>>> os.read(r, 1)
b'x'
>>> os.lseek(r, 0, os.SEEK_CUR)
2
>>> os.read(r, 1)
b'y'
>>> os.lseek(r, 0, os.SEEK_CUR)
2
>>> os.lseek(r, 0, os.SEEK_END)
1

So lseek() can be used to check the current pipe buffer size, and that seems about it. Given the above, I suggest two solutions for the hang on Windows:

1) Make lseek() fail on pipes on Windows, as it does on Unix. A number of projects have already done that:

https://referencesource.microsoft.com/#mscorlib/system/io/filestream.cs,1029
https://go.googlesource.com/go/+/ce58a39fca067a19c505220c0c907ccf32793427/src/syscall/syscall_windows.go#374
https://trac.ffmpeg.org/ticket/986 (workaround: https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2012-June/051590.html)
https://github.com/erikd/libsndfile/blob/123cb9f9a5a356b951a23e9e2ab8527f967425cc/src/file_io.c#L266

2) Delay lseek() until it's really needed. In both cases (BufferedIO and TextIO), lseek() is used to set some cached fields, so ISTM it's not necessary to do it during initialization. This would also be an optimization (skip lseek() syscall until a user really wants to tell()/seek()). This can be done as a sole fix or can be combined with the above (as an optimization).

I'd like to hear other people's opinions before doing anything for Python 3.

[1] https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-setfilepointerex
[2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/lseek-lseeki64

----------
components: IO, Windows
messages: 326175
nosy: eryksun, izbyshev, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Hang on startup if stdin refers to a pipe with an outstanding concurrent operation on Windows
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/issue34780>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:06:16 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 23 Sep 2018 20:06:16 +0000
Subject: [issue34780] Hang on startup if stdin refers to a pipe with an
 outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1537733176.3.0.956365154283.issue34780@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8924
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:08:23 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 23 Sep 2018 20:08:23 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1537731053.93.0.956365154283.issue22490@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKj_0vaXbzKM4ZjzNG=-1Ou+8LqP5SXkmLw-Nomjos2hg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Jason if you could test this we would be grateful!

Ronald what do you think of marking this as backportable to 3.7, 3.6 and
3.5?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:12:34 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 Sep 2018 20:12:34 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537733554.83.0.956365154283.issue22490@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've added back port labels for 3.6 and 3.7. 

AFAIK 3.5 is closed for bugfixes at this point (except for security fixes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:30:41 2018
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBCb3VkYQ==?=)
Date: Sun, 23 Sep 2018 20:30:41 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
Message-ID: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>


New submission from Tom?? Bouda <tomas.bouda at gmail.com>:

I have encountered a possible bug inside multiprocessing.Pool which behaves like race-condition while I don't believe it is a typical one.

Simply put, Pool from time to time freezes. It is occasional and hard to reproduce, but e.g. unit-tests running 3/day freeze several times a week.

We are using Pool heavily in our applications. Usually tens of workers and heavy load for each one of them. This production environment is using Python 2.7 (RHEL) and custom build, etc. However, I reproduced the same behavior in Python 3.6 (OSX) on my local machine.

When I run the following script like 20x, I get one or two frozen instances. You may notice in the output that ForkPoolWorker-42 never calls self.run(). The application than freezes as-is since it is probably waiting for the process.

It is easier to reproduce the behavior using debugger (PyCharm-Pro in my case), however, in our production environment there is just clean run, the bug occurs more often since multiprocessing is used quite a lot in there.

Thanks,
Tomas


--- My script:

import logging
from multiprocessing.pool import Pool
from multiprocessing.util import log_to_stderr

def f(i):
    print(i)

log_to_stderr(logging.DEBUG)

pool = Pool(50)
pool.map(f, range(2))
pool.close()
pool.join()

--- Output:

[DEBUG/MainProcess] created semlock with handle 9
[DEBUG/MainProcess] created semlock with handle 10
[DEBUG/MainProcess] created semlock with handle 13
[DEBUG/MainProcess] created semlock with handle 14
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-1] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-2] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-3] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-4] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-5] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-6] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-7] child process calling self.run()
[INFO/ForkPoolWorker-9] child process calling self.run()
[INFO/ForkPoolWorker-10] child process calling self.run()
[INFO/ForkPoolWorker-8] child process calling self.run()
[INFO/ForkPoolWorker-12] child process calling self.run()
[INFO/ForkPoolWorker-13] child process calling self.run()
[INFO/ForkPoolWorker-11] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-14] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-15] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-16] child process calling self.run()
[INFO/ForkPoolWorker-17] child process calling self.run()
[INFO/ForkPoolWorker-18] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-19] child process calling self.run()
[INFO/ForkPoolWorker-20] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-21] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-22] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-23] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-24] child process calling self.run()
[INFO/ForkPoolWorker-25] child process calling self.run()
[INFO/ForkPoolWorker-26] child process calling self.run()
[INFO/ForkPoolWorker-27] child process calling self.run()
[INFO/ForkPoolWorker-28] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-29] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-30] child process calling self.run()
[INFO/ForkPoolWorker-31] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-32] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-33] child process calling self.run()
[INFO/ForkPoolWorker-34] child process calling self.run()
[INFO/ForkPoolWorker-35] child process calling self.run()
[INFO/ForkPoolWorker-36] child process calling self.run()
[INFO/ForkPoolWorker-37] child process calling self.run()
[INFO/ForkPoolWorker-38] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-39] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-40] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-41] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-43] child process calling self.run()
[INFO/ForkPoolWorker-44] child process calling self.run()
[INFO/ForkPoolWorker-45] child process calling self.run()
[INFO/ForkPoolWorker-46] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-47] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
0
1
[INFO/ForkPoolWorker-48] child process calling self.run()
[DEBUG/MainProcess] closing pool
[DEBUG/MainProcess] joining pool
[DEBUG/MainProcess] worker handler exiting
[DEBUG/MainProcess] task handler got sentinel
[DEBUG/MainProcess] task handler sending sentinel to result handler
[DEBUG/MainProcess] task handler sending sentinel to workers
[DEBUG/ForkPoolWorker-3] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-4] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-5] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-3] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-6] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-4] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-7] worker got sentinel -- exiting
[INFO/ForkPoolWorker-3] process shutting down
[DEBUG/ForkPoolWorker-5] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-10] worker got sentinel -- exiting
[INFO/ForkPoolWorker-4] process shutting down
[DEBUG/ForkPoolWorker-6] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-7] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-3] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-4] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-8] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-10] worker exiting after 0 tasks
[INFO/ForkPoolWorker-5] process shutting down
[INFO/ForkPoolWorker-7] process shutting down
[INFO/ForkPoolWorker-6] process shutting down
[DEBUG/ForkPoolWorker-3] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-8] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-4] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-7] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-6] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-5] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-10] process shutting down
[INFO/ForkPoolWorker-8] process shutting down
[INFO/ForkPoolWorker-3] process exiting with exitcode 0
[INFO/ForkPoolWorker-4] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-10] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-7] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-8] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-5] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-7] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-10] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-9] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-6] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-5] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-8] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-9] worker exiting after 0 tasks
[INFO/ForkPoolWorker-10] process exiting with exitcode 0
[INFO/ForkPoolWorker-6] process exiting with exitcode 0
[INFO/ForkPoolWorker-8] process exiting with exitcode 0
[INFO/ForkPoolWorker-9] process shutting down
[DEBUG/ForkPoolWorker-9] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-12] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-12] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-13] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-11] worker got sentinel -- exiting
[INFO/ForkPoolWorker-12] process shutting down
[DEBUG/ForkPoolWorker-14] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-13] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-11] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-15] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-12] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-14] worker exiting after 0 tasks
[INFO/ForkPoolWorker-13] process shutting down
[DEBUG/ForkPoolWorker-16] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-15] worker exiting after 0 tasks
[INFO/ForkPoolWorker-11] process shutting down
[DEBUG/ForkPoolWorker-12] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-13] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-16] worker exiting after 0 tasks
[INFO/ForkPoolWorker-14] process shutting down
[DEBUG/ForkPoolWorker-17] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-11] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-18] worker got sentinel -- exiting
[INFO/ForkPoolWorker-15] process shutting down
[INFO/ForkPoolWorker-12] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-14] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-16] process shutting down
[DEBUG/ForkPoolWorker-13] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-17] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-15] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-18] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-19] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-16] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-13] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-11] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-14] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-15] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-11] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-19] worker exiting after 0 tasks
[INFO/ForkPoolWorker-17] process shutting down
[INFO/ForkPoolWorker-14] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-16] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-15] process exiting with exitcode 0
[INFO/ForkPoolWorker-19] process shutting down
[INFO/ForkPoolWorker-16] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-20] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-17] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-19] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-18] process shutting down
[DEBUG/ForkPoolWorker-20] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-19] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-18] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-17] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-20] process shutting down
[DEBUG/ForkPoolWorker-21] worker got sentinel -- exiting
[INFO/ForkPoolWorker-19] process exiting with exitcode 0
[DEBUG/MainProcess] result handler got sentinel
[INFO/ForkPoolWorker-17] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-18] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-20] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-21] worker exiting after 0 tasks
[DEBUG/MainProcess] ensuring that outqueue is not full
[DEBUG/ForkPoolWorker-22] worker got sentinel -- exiting
[INFO/ForkPoolWorker-18] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-20] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-21] process shutting down
[DEBUG/ForkPoolWorker-23] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-22] worker exiting after 0 tasks
[INFO/ForkPoolWorker-20] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-21] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-23] worker exiting after 0 tasks
[INFO/ForkPoolWorker-22] process shutting down
[DEBUG/ForkPoolWorker-24] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-21] running the remaining "atexit" finalizers
[DEBUG/MainProcess] result handler exiting: len(cache)=0, thread._state=0
[INFO/ForkPoolWorker-23] process shutting down
[DEBUG/ForkPoolWorker-22] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-25] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-24] worker exiting after 0 tasks
[INFO/ForkPoolWorker-21] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-23] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-25] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-22] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-26] worker got sentinel -- exiting
[INFO/ForkPoolWorker-24] process shutting down
[DEBUG/ForkPoolWorker-23] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-25] process shutting down
[INFO/ForkPoolWorker-22] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-26] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-24] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-27] worker got sentinel -- exiting
[INFO/ForkPoolWorker-23] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-25] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-26] process shutting down
[DEBUG/ForkPoolWorker-27] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-24] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-28] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-25] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-26] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-24] process exiting with exitcode 0
[INFO/ForkPoolWorker-27] process shutting down
[DEBUG/ForkPoolWorker-28] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-29] worker got sentinel -- exiting
[INFO/ForkPoolWorker-25] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-26] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-27] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-30] worker got sentinel -- exiting
[INFO/ForkPoolWorker-28] process shutting down
[DEBUG/ForkPoolWorker-29] worker exiting after 0 tasks
[INFO/ForkPoolWorker-26] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-31] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-30] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-27] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-28] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-29] process shutting down
[DEBUG/ForkPoolWorker-31] worker exiting after 0 tasks
[INFO/ForkPoolWorker-27] process exiting with exitcode 0
[INFO/ForkPoolWorker-30] process shutting down
[DEBUG/ForkPoolWorker-28] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-29] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-31] process shutting down
[DEBUG/ForkPoolWorker-30] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-33] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-32] worker got sentinel -- exiting
[INFO/ForkPoolWorker-28] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-29] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-31] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-33] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-30] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-32] worker exiting after 0 tasks
[INFO/ForkPoolWorker-29] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-31] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-33] process shutting down
[INFO/ForkPoolWorker-30] process exiting with exitcode 0
[INFO/ForkPoolWorker-32] process shutting down
[DEBUG/ForkPoolWorker-34] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-35] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-33] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-31] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-32] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-34] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-35] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-33] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-34] process shutting down
[DEBUG/ForkPoolWorker-32] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-36] worker got sentinel -- exiting
[INFO/ForkPoolWorker-35] process shutting down
[INFO/ForkPoolWorker-33] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-34] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-32] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-37] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-35] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-36] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-38] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-34] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-37] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-39] worker got sentinel -- exiting
[INFO/ForkPoolWorker-36] process shutting down
[DEBUG/ForkPoolWorker-35] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-34] process exiting with exitcode 0
[INFO/ForkPoolWorker-37] process shutting down
[DEBUG/ForkPoolWorker-36] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-38] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-39] worker exiting after 0 tasks
[INFO/ForkPoolWorker-35] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-37] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-38] process shutting down
[DEBUG/ForkPoolWorker-36] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-39] process shutting down
[DEBUG/ForkPoolWorker-37] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-38] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-39] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-36] process exiting with exitcode 0
[INFO/ForkPoolWorker-37] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-38] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-39] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-38] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-9] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-39] process exiting with exitcode 0
[INFO/ForkPoolWorker-9] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-40] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-41] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-40] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-41] worker exiting after 0 tasks
[INFO/ForkPoolWorker-40] process shutting down
[DEBUG/ForkPoolWorker-40] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-41] process shutting down
[DEBUG/ForkPoolWorker-41] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-43] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-40] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-44] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-41] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-43] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-45] worker got sentinel -- exiting
[INFO/ForkPoolWorker-40] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-44] worker exiting after 0 tasks
[INFO/ForkPoolWorker-41] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-45] worker exiting after 0 tasks
[INFO/ForkPoolWorker-43] process shutting down
[INFO/ForkPoolWorker-44] process shutting down
[DEBUG/ForkPoolWorker-43] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-44] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-45] process shutting down
[DEBUG/ForkPoolWorker-43] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-45] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-44] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-43] process exiting with exitcode 0
[INFO/ForkPoolWorker-44] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-45] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-45] process exiting with exitcode 0
[INFO/ForkPoolWorker-50] child process calling self.run()
[INFO/ForkPoolWorker-49] child process calling self.run()
[DEBUG/ForkPoolWorker-46] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-46] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-1] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-47] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-2] worker got sentinel -- exiting
[INFO/ForkPoolWorker-46] process shutting down
[DEBUG/ForkPoolWorker-1] worker exiting after 1 tasks
[DEBUG/ForkPoolWorker-47] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-2] worker exiting after 1 tasks
[INFO/ForkPoolWorker-1] process shutting down
[INFO/ForkPoolWorker-47] process shutting down
[DEBUG/ForkPoolWorker-46] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-2] process shutting down
[DEBUG/ForkPoolWorker-1] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-47] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-2] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-46] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-1] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-47] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-46] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-2] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-1] process exiting with exitcode 0
[INFO/ForkPoolWorker-47] process exiting with exitcode 0
[INFO/ForkPoolWorker-2] process exiting with exitcode 0
[DEBUG/MainProcess] task handler exiting
[DEBUG/ForkPoolWorker-50] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-48] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-48] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-50] worker exiting after 0 tasks
[INFO/ForkPoolWorker-48] process shutting down
[INFO/ForkPoolWorker-50] process shutting down
[DEBUG/ForkPoolWorker-49] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-48] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-50] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-49] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-50] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-48] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-49] process shutting down
[INFO/ForkPoolWorker-50] process exiting with exitcode 0
[INFO/ForkPoolWorker-48] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-49] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-49] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-49] process exiting with exitcode 0

----------
messages: 326178
nosy: coells
priority: normal
severity: normal
status: open
title: infinite waiting in multiprocessing.Pool
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:32:27 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 20:32:27 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1537734747.87.0.956365154283.issue33065@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The problem is not limited to user modules.  In duplicate issue #34609 (not closed), the same traceback was obtained with unittest.  I also got the same with asyncio.  There will not be a problem if the module is already loaded in sys.modules, so that importlib is not invoked.

The traceback is obscured by the fact that the executed importlib is frozen, leaving it traceable, but the code not directly available.  Hence the code is omitted from the debugger display and traceback.  However, the line numbers can be used to find the code within Lib/importlib._bootstrap.py.  Using current master (updated last night), the functions and lines executed by stepping with import unittest are (as expected when reading the code, up to the unexpected exception):

_find_and_load: 980
ModuleLock.__init__: 144, 145
ModuleLock.__enter__: 148
_get_module_lock: 163-168, 170-171, 174: lock = _ModuleLock(name)
_ModuleLock.__init__: 59: self.lock = _thread.allocate_lock()

IDLE's visual debugger has name-value panels for locals, including non-locals, and for globals.  It uses repr to gets value representations.  The locals panel is displayed by default.

Before line 174, 'lock' is bound to None, so before executing line 59, the display is "lock:None\nname:'unittest'".  After line 59, debugger apparently tries to get the repr of the in-process instance.  Since the call in 174 has not completed and should not have rebound 'lock' to the instance, I do not understand why.  (Brett, I now understand what you wrote to be pointing as this puzzle also.)  ppperry, additional light would be appreciated.

Given that debugger does try to get the repr of the instance, both Brett Cannon, here, and (ppperry), on duplicate issue #34609 (now closed), have pointed out that _ModuleLock.__repr__ uses self.name:
        return '_ModuleLock({!r}) at {}'.format(self.name, id(self))

I verified that updating the locals panel is the problem by starting over and turning the panel off until past the the assignment to self.name, at which point, the lock value is "_ModuleLock('unittest') at ...".

Debugger should be prepared for repr to fail, and display something informative.  In the present case, perhaps

repr raised "AttributeError: '_ModuleLock' object has no attribute 'name'"

with a check for whether the exception message contains "'.*' object" (and add such if not present).

----------
nosy:  -ppperry
title: IDLE debugger crashes when `repr` raises an exception -> IDLE debugger: failure stepping through module loading
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:36:23 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 23 Sep 2018 20:36:23 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537734982.99.0.956365154283.issue34705@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

I can't tell if you think this is something that should be fixed, or not? (Also, I'm not getting email notifications from bpo, sorry for the delay).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:46:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 20:46:24 +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: <1537735584.63.0.956365154283.issue33012@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I click the link for PR 6748, I see a page with "We went looking everywhere, but couldn?t find those commits."  Maybe the PR needs to be refreshed or closed and maybe reopened. PR 6749 looks normal.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33012>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:59:41 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 23 Sep 2018 20:59:41 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537736381.28.0.956365154283.issue22490@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I would love to know how to repro the original bug so I can demonstrate this actually fixes it.

Here's what I think should be the repro:

/Library/Frameworks/Python.framework/Versions/3.8/bin/python3  -c 'import subprocess; p = subprocess.Popen([".mypy/venv/bin/python3","-m","mypy.dmypy","-h"]).communicate()'

The setup is that .mypy/venv is a virtualenv that has mypy.dmypy installed. This is what failed for the user who reported this.

Unfortunately this does not fail for me (with a framework build from master installed). Would I have to do the install via brew? (I would have to learn about locally testing modified brew recipes, I suppose.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:00:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 21:00:30 +0000
Subject: [issue34734] Azure linux buildbot failure
In-Reply-To: <1537350711.76.0.956365154283.issue34734@psf.upfronthosting.co.za>
Message-ID: <1537736430.52.0.956365154283.issue34734@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems this is a known problem with VSTS and I am closing this as third party. Reference : https://mail.python.org/pipermail/python-committers/2018-September/006084.html

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34734>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:06:40 2018
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Sep 2018 21:06:40 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537736800.98.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8925

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:15:49 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 21:15:49 +0000
Subject: [issue34779] IDLE internals show up in tracebacks when returning
 objects that cannot be `repr`ed
In-Reply-To: <1537727943.66.0.956365154283.issue34779@psf.upfronthosting.co.za>
Message-ID: <1537737349.11.0.956365154283.issue34779@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The baseline for what should happen is what does happen in interactive python.exe.

>>> class N:
...   def __repr__(self): raise ValueError
...
>>> N()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in __repr__
ValueError

IDLE's Shell very intentionally improves on this by including the code, which would be present if one ran the code from a file.  This is most definitely not a bug.

idlelib.run.cleanup_traceback removes internal items from the beginning and end of tracebacks (as long as something is left) but intentionally leaves them in the middle, as they may add useful information.  (Situations like this are rare.)  This is also not a bug.  These details are not part of the language definition.

In this case, I think the extra line will on net be informative to beginners.  But even if you disagree, there is no way for code to decide.  I cannot imagine what else you think is 'wrong'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34779>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:22:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Sep 2018 21:22:26 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537737746.18.0.956365154283.issue34705@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think that this can be fixed. But this is not easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:38:01 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 21:38:01 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
Message-ID: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

class FakeContainer:
	def __getitem__(self, key)
		raise KeyError(key)
pdb.run("pass",{},FakeContainer())

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    pdb.run("pass",{},FakeContainer())
  File "C:\Program Files\Python37\lib\pdb.py", line 1590, in run
    Pdb().run(statement, globals, locals)
  File "C:\Program Files\Python37\lib\bdb.py", line 585, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <module>
  File "C:\Program Files\Python37\lib\bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Program Files\Python37\lib\bdb.py", line 112, in dispatch_line
    self.user_line(frame)
  File "C:\Program Files\Python37\lib\pdb.py", line 261, in user_line
    self.interaction(frame, None)
  File "C:\Program Files\Python37\lib\pdb.py", line 351, in interaction
    self.print_stack_entry(self.stack[self.curindex])
  File "C:\Program Files\Python37\lib\pdb.py", line 1453, in print_stack_entry
    self.format_stack_entry(frame_lineno, prompt_prefix))
  File "C:\Program Files\Python37\lib\bdb.py", line 549, in format_stack_entry
    if '__args__' in frame.f_locals:
  File "<pyshell#3>", line 3, in __getitem__
    raise KeyError
KeyError: 0

Obviously, the debugger shouldn't crash in this case (running code outside of the debugger works as expected, producing a NameError on variable reads and a TypeError whenever a name is assigned).

----------
components: Library (Lib)
messages: 326186
nosy: ppperry
priority: normal
severity: normal
status: open
title: Pdb crashes when code is executed in a mapping that does not define `__contains__`
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:39:57 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 21:39:57 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1537738797.65.0.956365154283.issue34782@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Sun Sep 23 17:51:08 2018
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBCb3VkYQ==?=)
Date: Sun, 23 Sep 2018 21:51:08 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537739468.14.0.956365154283.issue34781@psf.upfronthosting.co.za>


Tom?? Bouda <tomas.bouda at gmail.com> added the comment:

After more digging, I found that the following happens:

popen_fork.py -> _launch(self, process_obj) -> self.pid = os.fork()

When I let process (both child and parent) print resulting pid, on freezing I can see:
a) 50-times pid > 0
b) 49-times pid == 0

That means the parent is aware of 50 children, while only 49 of them get to the next line. Not sure if the one remaining process crashes on segfault, but parent apparently hangs later in os.waitpid() on this valid pid of the missing child.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Sun Sep 23 18:59:06 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 23 Sep 2018 22:59:06 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537743546.47.0.956365154283.issue2771@psf.upfronthosting.co.za>


Change by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Sep 23 19:04:20 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Sep 2018 23:04:20 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537743860.41.0.956365154283.issue2771@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

test

----------
nosy:  -nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Sep 23 19:06:59 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Sep 2018 23:06:59 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537744019.91.0.956365154283.issue2771@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

test

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Sep 23 19:07:36 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 23 Sep 2018 23:07:36 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537744056.26.0.956365154283.issue2771@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

A test comment from nedbat

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:00:48 2018
From: report at bugs.python.org (eohm)
Date: Mon, 24 Sep 2018 00:00:48 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
Message-ID: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>


New submission from eohm <info at eliasohm.de>:

segmentation-fault/core dump when try to run non-existing file specified on commandline (pymain_run_filename)

https://github.com/docker-library/python/issues/320

----------
messages: 326191
nosy: eohm
priority: normal
severity: normal
status: open
title: segmentation-fault/core dump when try to run non-existing file specified on commandline
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:02:42 2018
From: report at bugs.python.org (eohm)
Date: Mon, 24 Sep 2018 00:02:42 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537747362.9.0.956365154283.issue34783@psf.upfronthosting.co.za>


eohm <info at eliasohm.de> added the comment:

bug was probably introduced here: python/cpython at 1976086#diff-75445bdc3b6b3dd20b005698fa165444R2443 (but I did not test the version from before that commit)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:15:06 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 Sep 2018 00:15:06 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537748106.7.0.956365154283.issue34751@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> To my eyes, the _strongest_ case in all these messages is 
> for boosting the multiplier size on 64-bit boxes.  That's
> principled and well-motivated.

Yes, that would be perfectly reasonable (though to some extent the objects in the tuple also share some of the responsibility for getting all bits into play).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:33:46 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Sep 2018 00:33:46 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537749226.73.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Has anyone figured out the real source of the degeneration when mixing in negative integers?  I have not.  XOR always permutes the hash range - it's one-to-one.  No possible outputs are lost, and XOR with a negative int isn't "obviously degenerate" in general:

>>> for i in range(-16, 17):
...    print(i, i ^ -5)
-16 11
-15 10
-14 9
-13 8
-12 15
-11 14
-10 13
-9 12
-8 3
-7 2
-6 1
-5 0
-4 7
-3 6
-2 5
-1 4
0 -5
1 -6
2 -7
3 -8
4 -1
5 -2
6 -3
7 -4
8 -13
9 -14
10 -15
11 -16
12 -9
13 -10
14 -11
15 -12
16 -21

Clear enough? "Distinct integers in, distinct integers out", but with the twist that the sign bit flips.  That's _seemingly_ minor to me.  Yet it has massive effects on tuple hash distribution.  Here's a function to show that:

    def doit(cands, repeat=4):
        from collections import Counter
        from itertools import product

        print(len(cands), "cands **", repeat, "=", len(cands)**repeat)
        c1 = Counter(map(hash, product(cands, repeat=repeat)))
        print(len(c1), "distinct hash codes")
        c2 = Counter(c1.values())
        for dups in sorted(c2):
            print(dups, c2[dups])

Then an example we're proud of:

>>> doit(range(100))
100 cands ** 4 = 100000000
100000000 distinct hash codes
1 100000000

Much the same, mixing in negative ints, but _excluding_ the problematic -1 and -2 inputs:

>>> cands = list(range(-50, 51))
>>> cands.remove(-1) # hashes to -2
>>> cands.remove(-2) # for j odd, j ^ -2 == -j
>>> doit(cands)
99 cands ** 4 = 96059601
15736247 distinct hash codes
1 70827
2 1005882
3 228578
4 5000424
5 19728
6 1047762
8 8363046

What accounts for such a massive difference?  It's not merely that we're using negative ints:

>>> doit(range(-101, -1)) # leave -2 in, for a change
100 cands ** 4 = 100000000
100000000 distinct hash codes
1 100000000

So, on their own, negative ints are as spectacularly well-behaved in this range as positive ints, and including -2 creates no problems.

I suspect it's related to that x ^ -(x + 1) == -1, but not in a way obvious enough to be ... well, obvious ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:35:04 2018
From: report at bugs.python.org (Lisa Roach)
Date: Mon, 24 Sep 2018 00:35:04 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537749304.35.0.956365154283.issue34659@psf.upfronthosting.co.za>


Lisa Roach <lisaroach14 at gmail.com> added the comment:


New changeset 9718b59ee5f2416cdb8116ea5837b062faf0d9f8 by Lisa Roach in branch 'master':
bpo-34659: Adds initial kwarg to itertools.accumulate() (GH-9345)
https://github.com/python/cpython/commit/9718b59ee5f2416cdb8116ea5837b062faf0d9f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:35:17 2018
From: report at bugs.python.org (eohm)
Date: Mon, 24 Sep 2018 00:35:17 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537749317.24.0.956365154283.issue34783@psf.upfronthosting.co.za>


Change by eohm <info at eliasohm.de>:


----------
keywords: +patch
pull_requests: +8926
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:37:40 2018
From: report at bugs.python.org (eohm)
Date: Mon, 24 Sep 2018 00:37:40 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537749460.25.0.956365154283.issue34783@psf.upfronthosting.co.za>


eohm <info at eliasohm.de> added the comment:

Did a quick cross-check with other Distro.
With a debian stretch for example there is no SEGV and core-dump but a "(null)" output for program name instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Sun Sep 23 20:41:19 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Sep 2018 00:41:19 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537749679.41.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

[Raymond, on boosting the multiplier on 64-bit boxes]
> Yes, that would be perfectly reasonable (though to some
> extent the objects in the tuple also share some of the
> responsibility for getting all bits into play).

It's of value independent of that.  Tuples of ints used as keys and set elements are very important, and I doubt we'll ever give up on that `hash(i) == i` for the typically "not huge" ints used in such contexts.  Jeroen gave a reasonable example of how boosting the multiplier can help in a case of that above:

https://bugs.python.org/msg326032

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sun Sep 23 21:19:01 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Sep 2018 01:19:01 +0000
Subject: [issue33962] IDLE: use ttk.spinbox with configdialog
In-Reply-To: <1529983748.27.0.56676864532.issue33962@psf.upfronthosting.co.za>
Message-ID: <1537751941.21.0.956365154283.issue33962@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: IDLE: use ttk.spinbox -> IDLE: use ttk.spinbox with configdialog

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33962>
_______________________________________

From report at bugs.python.org  Sun Sep 23 22:40:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 02:40:18 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537756818.44.0.956365154283.issue34783@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Sun Sep 23 22:43:34 2018
From: report at bugs.python.org (William Bowling)
Date: Mon, 24 Sep 2018 02:43:34 +0000
Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free
In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>
Message-ID: <1537757014.5.0.956365154283.issue26000@psf.upfronthosting.co.za>


William Bowling <will at wbowling.info> added the comment:

> Is this still reproducible? On master (Python 3.8) with a debug build it throws a SyntaxError. I don't have Python 3.5 installed to check this though

Looks like it's fixed in master and 3.6.6 but still happening in 3.5.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26000>
_______________________________________

From report at bugs.python.org  Sun Sep 23 22:43:40 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 02:43:40 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1537757020.77.0.956365154283.issue34782@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Mon Sep 24 00:16:31 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Sep 2018 04:16:31 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537762591.54.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

FYI, using this for the guts of the tuple hash works well on everything we've discussed.  In particular, no collisions in the current test_tuple hash test, and none either in the cases mixing negative and positive little ints.  This all remains so using the current multiplier, or "the standard" FNV-1a multipliers 16777619UL (32 bit) and 1099511628211UL (64 bit).  I've done no other tests:

while (--len >= 0) {
        y = PyObject_Hash(*p++);
        if (y == -1)
            return -1;
		Py_uhash_t t = (Py_uhash_t)y;
		t ^= t << 7;
		x = (x ^ t) * mult;
}

Note that the multiplier doesn't change anymore.  The twist is adding

		t ^= t << 7;

to _permute_ the native hash space (stuff like "t += t >> 16" is a many-to-one function, not a permutation).  Other than that, it's exactly FNV-1a.  I don't know that 7 is especially magical - it's just the first thing I tried.

In the absence of a real analysis, the intuition is simply that "t ^= t << 7" will clear masses of leading sign bits when hashing "small" negative integers.  For whatever reason(s), they appear to be the cause of the troubles.

However, since that line of code permutes the space, exactly the same statistics can be provoked by some other inputs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 00:35:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 24 Sep 2018 04:35:38 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537763738.34.0.956365154283.issue34783@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/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 00:50:11 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 24 Sep 2018 04:50:11 +0000
Subject: [issue34780] Hang on startup if stdin refers to a pipe with an
 outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1537764611.97.0.956365154283.issue34780@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> lseek() succeeds on pipes on Windows, but is nearly useless

lseek isn't meaningful for pipe and character files (i.e. FILE_TYPE_PIPE and FILE_TYPE_CHAR). While SEEK_SET and SEEK_CUR operations trivially succeed in these cases, the underlying device simply ignores the current file position. I think it would be reasonable to fail these cases instead of succeeding misleadingly.

When a file is opened for synchronous access, its  FilePositionInformation is managed by the I/O manager, not the device or file system. All the I/O manager does is get or set the CurrentByteOffset value in the File object [1]. It doesn't matter whether the device actually uses this information. 

Regarding the observed SEEK_END behavior, the named-pipe file system (NPFS) supports querying the FileStandardInformation of a pipe, in which it sets the EndOfFile value as the number of bytes available to be read from the pipe's inbound (server-side) queue. So SEEK_END (or WinAPI FILE_END) does provide some information to us, but it's misleading because the seek itself is meaningless.

[1]: https://msdn.microsoft.com/en-us/library/windows/hardware/ff545834

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Mon Sep 24 01:07:00 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 24 Sep 2018 05:07:00 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537765620.73.0.956365154283.issue22490@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I had the some problem when using mypy. What does reproduce the issue is the following:

* Create *two* venv environments
* Install mypy in one of them
* Activate the other
* Run the subprocess call in the activated venv

I then get a message about not being able to find mypy:

.../some-env/bin/python3: No module named mypy.dmypy

I don't get the message when I call subprocess outside of a venv.

I haven't checked yet if my patch fixes this issue, that will have to wait for later this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Mon Sep 24 01:11:58 2018
From: report at bugs.python.org (Windson Yang)
Date: Mon, 24 Sep 2018 05:11:58 +0000
Subject: [issue34753] Use coroutine object or coroutine function instead of
 coroutine
In-Reply-To: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>
Message-ID: <1537765918.87.0.956365154283.issue34753@psf.upfronthosting.co.za>


Change by Windson Yang <wiwindson at gmail.com>:


----------
keywords: +patch
pull_requests: +8928
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34753>
_______________________________________

From report at bugs.python.org  Mon Sep 24 01:50:59 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Sep 2018 05:50:59 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537768259.36.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

BTW, those tests were all done under a 64-bit build.  Some differences in a 32-bit build:

1. The test_tuple hash test started with 6 collisions.  With the change, it went down to 4.  Also changing to the FNV-1a 32-bit multiplier boosted it to 8.  The test passes in all those cases.

2. For 4-tuples taken from range(-50, 51) omitting -1 and -2:  massive number of collisions under the current code.  Died with MemoryError with the change - ran out of memory to build the Counter recording all the distinct hash codes.

Changing it to 3-tuples instead:  somewhere around 140 collisions with the change, and also changing to the FNV-1a 32-bit multiplier eliminated all collisions.

All of this was done under Win 10, using Visual Studio 2017.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 03:08:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 07:08:21 +0000
Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free
In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>
Message-ID: <1537772901.8.0.956365154283.issue26000@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks William for the information. I can reproduce this on 3.5.6. I was able to bisect this down to
#31852 that deals with similar cases and fixed with commit 690c36f2f1085145d364a89bfed5944dd2470308.

$ cpython git:(master) git checkout 690c36f2f1085145d364a89bfed5944dd2470308
HEAD is now at 690c36f2f1 [3.6] bpo-31852: Fix segfault caused by using the async soft keyword (GH-4122)
$ cpython git:(690c36f2f1) git clean -xdf && ./configure --with-pydebug && make -s -j4
$ cpython git:(690c36f2f1) ./python.exe ../backups/vuln.py
  File "../backups/vuln.py", line 2
SyntaxError: Non-UTF-8 code starting with '\xef' in file ../backups/vuln.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
$ cpython git:(690c36f2f1) ./python.exe ../backups/vuln2.py
  File "../backups/vuln2.py", line 3
SyntaxError: Non-UTF-8 code starting with '\xdd' in file ../backups/vuln2.py on line 3, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

# Reproduce the crash

?  cpython git:(690c36f2f1) git checkout 690c36f2f1085145d364a89bfed5944dd2470308~1
Previous HEAD position was 690c36f2f1 [3.6] bpo-31852: Fix segfault caused by using the async soft keyword (GH-4122)
HEAD is now at 2702380870 bpo-31304: Update starmap_async documentation. (GH-4168) (GH-4177)
?  cpython git:(2702380870) make
?  cpython git:(2702380870) ./python.exe ../backups/vuln2.py
Assertion failed: (!PyErr_Occurred()), function PyObject_Call, file Objects/abstract.c, line 2247.
^[[A[2]    71701 abort      ./python.exe ../backups/vuln2.py
?  cpython git:(2702380870) ./python.exe ../backups/vuln.py
Assertion failed: (!PyErr_Occurred()), function PyObject_Call, file Objects/abstract.c, line 2247.
[2]    71712 abort      ./python.exe ../backups/vuln.py

It doesn't affect master, 3.7.0 and v3.6.4+ . Since 3.5 is in security mode and was not backported to 3.5 in the linked ticket. I propose to close this ticket and reopen a separate one with Larry added to it if the fix needs an explicit backport to 3.5.6 on priority.


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26000>
_______________________________________

From report at bugs.python.org  Mon Sep 24 03:23:17 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 24 Sep 2018 07:23:17 +0000
Subject: [issue34784] Heap-allocated StructSequences
Message-ID: <1537773797.44.0.956365154283.issue34784@psf.upfronthosting.co.za>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

PyStructSequence_NewType does not currently work. Read the full analysis here: https://mail.python.org/pipermail/python-dev/2018-September/155069.html

This aims to fix the implementation of PyStructSequence_NewType.

----------
components: Library (Lib)
messages: 326205
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Heap-allocated StructSequences
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34784>
_______________________________________

From report at bugs.python.org  Mon Sep 24 03:25:19 2018
From: report at bugs.python.org (Jarry Shaw)
Date: Mon, 24 Sep 2018 07:25:19 +0000
Subject: [issue34785] pty.spawn -- auto-termination after child process is
 dead (a zombie)
Message-ID: <1537773919.52.0.956365154283.issue34785@psf.upfronthosting.co.za>


New submission from Jarry Shaw <jarryshaw at icloud.com>:

As in pty.spawn, once started, the parent process will be hanged, even if the child process is already dead (or a zombie), and must wait for a KeyboardInterrupt or else to terminate the whole process.

Thus, I propose to revise `_copy` function, where the parent process hung, to check if the child process is dead periodically and if so, terminate the whole process then return as shown in the patch file.

----------
components: Library (Lib)
files: pty-diff.patch
keywords: patch
messages: 326206
nosy: jarryshaw
priority: normal
severity: normal
status: open
title: pty.spawn -- auto-termination after child process is dead (a zombie)
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47820/pty-diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34785>
_______________________________________

From report at bugs.python.org  Mon Sep 24 03:31:45 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 24 Sep 2018 07:31:45 +0000
Subject: [issue34784] Heap-allocated StructSequences
In-Reply-To: <1537773797.44.0.956365154283.issue34784@psf.upfronthosting.co.za>
Message-ID: <1537774305.13.0.956365154283.issue34784@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch
pull_requests: +8929
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34784>
_______________________________________

From report at bugs.python.org  Mon Sep 24 03:36:46 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 07:36:46 +0000
Subject: [issue29685] test_gdb failed
In-Reply-To: <1488382954.54.0.564501434146.issue29685@psf.upfronthosting.co.za>
Message-ID: <1537774606.2.0.956365154283.issue29685@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add your GDB version? The version parsing is done with regex r"^GNU gdb.*?\b(\d+)\.(\d+)" and I think it's not matching your version which seems to be empty. Adding the output of `gdb -nx --version` will be helpful in debugging this since the output is the string used against the regex.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29685>
_______________________________________

From report at bugs.python.org  Mon Sep 24 03:41:12 2018
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 24 Sep 2018 07:41:12 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1537774872.54.0.956365154283.issue34778@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/issue34778>
_______________________________________

From report at bugs.python.org  Mon Sep 24 04:00:58 2018
From: report at bugs.python.org (Vostretsov Nikita)
Date: Mon, 24 Sep 2018 08:00:58 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1537776058.26.0.956365154283.issue34744@psf.upfronthosting.co.za>


Vostretsov Nikita <whalebot.helmsman at gmail.com> added the comment:

>'option_strings' is already being used in '_format_action_invocation()'.  So I don't see why this flag needs to appear again in the help line.

'option_strings' is available as a whole list, you can not use just first element of it

>Though the user can certainly hard code it into the line when defining the 'add_argument'

Same logic can be applied to other members of this dictionary, but it's purpose
>The help strings can include various format specifiers to avoid repetition of things like the program name or the argument default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Mon Sep 24 04:10:12 2018
From: report at bugs.python.org (Jarry Shaw)
Date: Mon, 24 Sep 2018 08:10:12 +0000
Subject: [issue34785] pty.spawn -- auto-termination after child process is
 dead (a zombie)
In-Reply-To: <1537773919.52.0.956365154283.issue34785@psf.upfronthosting.co.za>
Message-ID: <1537776612.23.0.956365154283.issue34785@psf.upfronthosting.co.za>


Change by Jarry Shaw <jarryshaw at icloud.com>:


----------
pull_requests: +8930
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34785>
_______________________________________

From report at bugs.python.org  Mon Sep 24 04:59:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 08:59:56 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537779596.11.0.956365154283.issue32892@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Serhiy Storchaka: "ast.Constant is not new. You can use it since 3.8."

Since Python 3.6 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:40:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 09:40:26 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537782026.91.0.956365154283.issue34783@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8931

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:41:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 09:41:21 +0000
Subject: [issue34783] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537782081.24.0.956365154283.issue34783@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

eohm: thank you for your bug report and great job of your analysis of the root cause! Your PR works as expected, but I prefer to get the current core configuration rather than keeping our old copy longer than previously in main.c. I wrote a PR 9526 to reorganize the code to make it closer to the master branch: clarify the lifetime of the "local config" in main.c, and as soon as possible, switch to the core configuration attached to the interpreter state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:43:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 09:43:25 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537782205.74.0.956365154283.issue34783@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Note: the master branch is not affected, I already fixed the bug in master. My PR backports the fix.

----------
title: segmentation-fault/core dump when try to run non-existing file specified on commandline -> [3.7] segmentation-fault/core dump when try to run non-existing file specified on commandline

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:45:54 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 09:45:54 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537782354.87.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Has anyone figured out the real source of the degeneration when mixing in negative integers?

The underlying reason for the collisions is the following mathematical relation:

x ^ -x = -2 << i

where i is the index of the smallest set bit of x. In particular, x ^ -x = -2 for odd x.

Now consider two consecutive hash iterations:

y = (x ^ a) * m1
z = (y ^ b) * m2

and suppose that x ^ a is odd. Now if we replace a by a ^ -2, then x ^ a will be replaced by -(x ^ a) and y will be replaced by -y. If we also replace b by b ^ -2, then y ^ b will be replaced by y ^ b. In other words, we have a collision.

This kind of bad interaction between ^ and * only happens with the FNV-style hashing. The Bernstein hash using + instead of ^ does not suffer from this problem. That makes it a better choice in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:51:26 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 24 Sep 2018 09:51:26 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
In-Reply-To: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>
Message-ID: <1537782686.62.0.956365154283.issue34728@psf.upfronthosting.co.za>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 558c49bcf3a8543d64a68de836b5d855efd56696 by Carol Willing (Jo?o J?nior) in branch 'master':
bpo-34728: Remove deprecate *loop* argument in asyncio.sleep (GH-9415)
https://github.com/python/cpython/commit/558c49bcf3a8543d64a68de836b5d855efd56696


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:52:53 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 09:52:53 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537782773.24.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

While writing up the analysis above, it occurred to me that collisions already happen for 2-tuples:

>>> hash((3, -2)) == hash((-3, 0))
True

These kind of 2-tuples of small integers don't look contrived at all. I can easily see them appearing, in mathematical applications for example.

As for real-world usage: the only thing that I can say is that I discovered these hash collisions a while ago, while working on SageMath. I was testing the hash for a custom class and I found collisions, which I traced back to collisions for tuples.

In any case, it is hard to find real-world problems where a bad hash really matters, since Python works fine with a broken hash too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:55:53 2018
From: report at bugs.python.org (Carol Willing)
Date: Mon, 24 Sep 2018 09:55:53 +0000
Subject: [issue34728] deprecate *loop* argument for asyncio.sleep
In-Reply-To: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>
Message-ID: <1537782953.97.0.956365154283.issue34728@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34728>
_______________________________________

From report at bugs.python.org  Mon Sep 24 05:58:41 2018
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 24 Sep 2018 09:58:41 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537783121.77.0.956365154283.issue34705@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

The new behaviour looks the more correct to me.

Arguably the sequence should not include the second "4 line", but is otherwise correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Mon Sep 24 06:01:02 2018
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 24 Sep 2018 10:01:02 +0000
Subject: [issue34705] Python 3.8 changes how returns through finally clauses
 are traced
In-Reply-To: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>
Message-ID: <1537783262.87.0.956365154283.issue34705@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

When I get a chance I'll see what happens with https://github.com/python/cpython/pull/6641

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________

From report at bugs.python.org  Mon Sep 24 06:01:11 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 10:01:11 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537783271.67.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> stuff like "t += t >> 16" is a many-to-one function, not a permutation

Yes, I am aware of that. However, the number of collisions here is really quite small. It's very unlikely to hit one by accident.

I also chose >> over << for two reasons:

1. It brings the high-order in play: https://bugs.python.org/msg326117

2. It avoids collisions on the low-order bits: when you do t ^= t << 7, then you are not changing the lower 7 bits at all. So applications using hash(x) % 128 will still see all the problems that we are trying to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 06:33:17 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 10:33:17 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537785197.46.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> For example, FNV-1a has far better "avalanche" behavior than Bernstein

We don't care about that though. We want to have no collisions, not a random output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 06:39:51 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 10:39:51 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537785591.61.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> In the absence of a real analysis, the intuition is simply that "t ^= t << 7" will clear masses of leading sign bits when hashing "small" negative integers.

That's a clever solution. If you want to go that route, I would rather suggest t ^= t << 1 which is essentially the same fix but which has probably less collisions on the low-order bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 06:42:44 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 24 Sep 2018 10:42:44 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1537785764.09.0.956365154283.issue24937@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 2d3ff2b5ea6c903973f99d2155c9c1b60591dceb by Petr Viktorin in branch 'master':
bpo-24937: Replace the extension module porting HOWTO by links to external projects (GH-9317)
https://github.com/python/cpython/commit/2d3ff2b5ea6c903973f99d2155c9c1b60591dceb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Mon Sep 24 06:44:31 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 24 Sep 2018 10:44:31 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1537785871.11.0.956365154283.issue24937@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Mon Sep 24 07:14:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 11:14:17 +0000
Subject: [issue34752] warnings.warn fails silently with unicode input
In-Reply-To: <1537452937.66.0.956365154283.issue34752@psf.upfronthosting.co.za>
Message-ID: <1537787657.11.0.956365154283.issue34752@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this a known limitation as per https://bugs.python.org/issue23637#msg239361 where non-ASCII characters would require byte string. I couldn't find the relevant documentation for it though.

$ ./python.exe
Python 2.7.15+ (remotes/upstream/2.7:69d0bc1430, Sep 24 2018, 16:02:09)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>>
>>> warnings.warn(b'bl?')
__main__:1: UserWarning: bl?
>>> warnings.warn(u'bl?')
>>>

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34752>
_______________________________________

From report at bugs.python.org  Mon Sep 24 07:30:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 11:30:05 +0000
Subject: [issue34752] warnings.warn fails silently with unicode input
In-Reply-To: <1537452937.66.0.956365154283.issue34752@psf.upfronthosting.co.za>
Message-ID: <1537788605.67.0.956365154283.issue34752@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I looked some more into the linked issue and I think this is an explicit decision and the comment in the code indicates that the warning will be lost : https://github.com/python/cpython/blob/69d0bc1430d2e9cddf0b39054ddcb86dbbe7927e/Lib/warnings.py#L34 . I understand your perspective on failing silently but I am proposing to close this since enabling the error by removing UnicodeDecodeError in the except clause will be an incompatible change at this point.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34752>
_______________________________________

From report at bugs.python.org  Mon Sep 24 07:44:55 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Sep 2018 11:44:55 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537789495.37.0.956365154283.issue34582@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 57675090b0fe7d6c7d72e56384dc2ff6798f1723 by Steve Dower in branch 'master':
bpo-34582: Update syntax of Azure Pipelines builds (GH-9521)
https://github.com/python/cpython/commit/57675090b0fe7d6c7d72e56384dc2ff6798f1723


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 07:45:14 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 11:45:14 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537789514.76.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8933

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 07:51:15 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Sep 2018 11:51:15 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537789875.05.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:03:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 12:03:04 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537790584.52.0.956365154283.issue34783@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset ddc163df25191af5bf8000091dbf8f6500b1d7c9 by Victor Stinner in branch '3.7':
bpo-34783: Fix Py_Main() (GH-9526)
https://github.com/python/cpython/commit/ddc163df25191af5bf8000091dbf8f6500b1d7c9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:05:57 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Sep 2018 12:05:57 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537790757.66.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8935

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:06:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 24 Sep 2018 12:06:19 +0000
Subject: [issue31506] Improve the error message logic for object_new &
 object_init
In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za>
Message-ID: <1537790779.49.0.956365154283.issue31506@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We added the method names to help provide a nudge that the issue is likely to be a missing method implementation in the subclassing case, so I'd like to keep them if we can find a way to make the messages accurate again.

What if we updated the offending format strings in typeobject.c to state the exact nature of the expected argument that is missing?

    PyErr_SetString(PyExc_TypeError, "object.__init__() takes exactly one argument (the instance to initialize)");

    PyErr_Format(PyExc_TypeError, "%.200s.__init__() takes exactly one argument (the instance to initialize)", type->tp_name);

    PyErr_SetString(PyExc_TypeError, "object.__new__() takes exactly one argument (the type to instantiate)")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31506>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:30:14 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 24 Sep 2018 12:30:14 +0000
Subject: [issue28604] Exception raised by python3.5 when using en_GB locale
In-Reply-To: <1478208394.68.0.721396484587.issue28604@psf.upfronthosting.co.za>
Message-ID: <1537792214.3.0.956365154283.issue28604@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28604>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:32:16 2018
From: report at bugs.python.org (=?utf-8?b?Sm9uaSBLw6Row6Ryw6Q=?=)
Date: Mon, 24 Sep 2018 12:32:16 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
Message-ID: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>


New submission from Joni K?h?r? <joni.kahara at async.fi>:

https://docs.python.org/3.8/library/concurrent.futures.html

"initializer is an optional callable that is called at the start of each worker process; initargs is a tuple of arguments passed to the initializer. Should initializer raise an exception, all currently pending jobs will raise a BrokenThreadPool, as well any attempt to submit more jobs to the pool."

This should be BrokenProcessPool?

----------
assignee: docs at python
components: Documentation
messages: 326226
nosy: Joni K?h?r?, docs at python
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor documentation reports wrong exception being raised
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:34:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Sep 2018 12:34:07 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537792447.51.0.956365154283.issue34786@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8936
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:38:00 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 12:38:00 +0000
Subject: [issue34752] warnings.warn fails silently with unicode input
In-Reply-To: <1537452937.66.0.956365154283.issue34752@psf.upfronthosting.co.za>
Message-ID: <1537792680.6.0.956365154283.issue34752@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Since Nick had some issue on adding a message to the issue I am adding the email sent to me as a message below : 


(sorry I can't see how to post a reply message on the bugs page, I'm still new to this)

anyhow here's what I wanted to post:

Thanks for finding the bug!
Maybe a preferable behaviour would be to split the error types
 - an IOError could still pass (I'm really not sure what the ideal treatment in that case is
 - a Unicode error would still print a warning but it would be something like a generic 'warning: non-standard text found in warning text so only printing this' (I'm sure there's something better sounding / more consistent with other warnings but I don't know them that well)

so the code would look something like:
except (UnicodeError):
    message = "non-standard text found in warning text so only printing this"
    file.write(formatwarning(message, category, filename, lineno, line))
except (IOError):
        pass # the file (probably stderr) is invalid - this warning
 gets lost.



but I'm not sure if an IOError inside the UnicodeError handling would still be caught (?)

anyhow I'm not sure how standard/appropriate a generic warning would be within the broader context of python (?) I think for us we'll probably just bite the bullet and switch to python3 to avoid this kind of thing since we'll potentially have a lot of unicode messages in the near future.

thanks again,
Nick Parslow

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34752>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:38:36 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 12:38:36 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537792716.05.0.956365154283.issue17239@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 582d188e6e3487180891f1fc457a80dec8be26a8 by Miss Islington (bot) (Christian Heimes) in branch '3.6':
[3.6] bpo-17239: Disable external entities in SAX parser (GH-9217) (GH-9512)
https://github.com/python/cpython/commit/582d188e6e3487180891f1fc457a80dec8be26a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:38:40 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 12:38:40 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1537792720.52.0.956365154283.issue17239@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 394e55a9279d17240ef6fe85d3b4ea3fe7b6dff5 by Miss Islington (bot) (Christian Heimes) in branch '3.7':
[3.7] bpo-17239: Disable external entities in SAX parser (GH-9217) (GH-9511)
https://github.com/python/cpython/commit/394e55a9279d17240ef6fe85d3b4ea3fe7b6dff5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:43:39 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Sep 2018 12:43:39 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537793019.13.0.956365154283.issue34582@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 657fdf2eba617ade49052de91cafeb373b652077 by Steve Dower (Miss Islington (bot)) in branch '3.7':
bpo-34582: Update syntax of Azure Pipelines builds (GH-9521)
https://github.com/python/cpython/commit/657fdf2eba617ade49052de91cafeb373b652077


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:47:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 12:47:27 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537793247.81.0.956365154283.issue34786@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:51:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 12:51:52 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537793512.12.0.956365154283.issue34786@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think it raises BrokenThreadPool . A sample program that I tried as below raising an exception in the initializer. Maybe I am wrong here. Can you please attach a script that triggers BrokenProcessPool?

# bpo34786.py

import concurrent.futures
import time

def bar(i):
    raise Exception(i) # Raise exception from the initializer

def foo(i):
    time.sleep(i)
    return "1"

with concurrent.futures.ThreadPoolExecutor(max_workers=5,
                                           initializer=bar, initargs=(1,)) as executor:
    future_to_url = {executor.submit(foo, i, 60): i for i in range(10)}
    for future in concurrent.futures.as_completed(future_to_url):
        try:
            data = future.result()
        except Exception as exc:
            print('generated an exception: %s' % (exc))
        else:
            print('%d bytes' % (len(data)))

# Run the program

./python.exe ../backups/bpo34786.py
Exception in initializer:
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/thread.py", line 69, in _worker
    initializer(*initargs)
  File "../backups/bpo34786.py", line 5, in bar
    raise Exception(i)
Exception: 1
Exception in initializer:
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/thread.py", line 69, in _worker
    initializer(*initargs)
  File "../backups/bpo34786.py", line 5, in bar
    raise Exception(i)
Exception: 1
Traceback (most recent call last):
  File "../backups/bpo34786.py", line 13, in <module>
    future_to_url = {executor.submit(foo, i, 60): i for i in range(10)}
  File "../backups/bpo34786.py", line 13, in <dictcomp>
    future_to_url = {executor.submit(foo, i, 60): i for i in range(10)}
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/thread.py", line 148, in submit
    raise BrokenThreadPool(self._broken)
concurrent.futures.thread.BrokenThreadPool: A thread initializer failed, the thread pool is not usable anymore



Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 08:53:39 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 12:53:39 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537793619.04.0.956365154283.issue34582@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 73653062b1ef76b879c01a09163db2cff6548c3c by Miss Islington (bot) (Steve Dower) in branch '3.6':
[3.6] bpo-34582: Update syntax of Azure Pipelines builds (GH-9521) (GH-9528)
https://github.com/python/cpython/commit/73653062b1ef76b879c01a09163db2cff6548c3c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 09:03:06 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 13:03:06 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537794186.91.0.956365154283.issue34582@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1b77f929f8d18e9a97335a8ec5e838e5be506568 by Miss Islington (bot) (Steve Dower) in branch 'master':
bpo-34582: Fixes Python version used for patch check (GH-9532)
https://github.com/python/cpython/commit/1b77f929f8d18e9a97335a8ec5e838e5be506568


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 09:15:38 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Sep 2018 13:15:38 +0000
Subject: [issue34582] VSTS builds should use jobs, pools, and test results
In-Reply-To: <1536871033.37.0.956365154283.issue34582@psf.upfronthosting.co.za>
Message-ID: <1537794938.34.0.956365154283.issue34582@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34582>
_______________________________________

From report at bugs.python.org  Mon Sep 24 09:24:06 2018
From: report at bugs.python.org (=?utf-8?b?Sm9uaSBLw6Row6Ryw6Q=?=)
Date: Mon, 24 Sep 2018 13:24:06 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537795446.51.0.956365154283.issue34786@psf.upfronthosting.co.za>


Joni K?h?r? <joni.kahara at async.fi> added the comment:

Perhaps I wasn't clear that this considered ProcessPoolExecutor documentation, not ThreadPoolExecutor. Taking the example from documentation and adding an initializer like this:


import concurrent.futures
import math

PRIMES = [
    112272535095293,
    112582705942171,
    112272535095293,
    115280095190773,
    115797848077099,
    1099726899285419]

def is_prime(n):
    if n % 2 == 0:
        return False

    sqrt_n = int(math.floor(math.sqrt(n)))
    for i in range(3, sqrt_n + 1, 2):
        if n % i == 0:
            return False
    return True

def init():
    raise Exception()

def main():
    with concurrent.futures.ProcessPoolExecutor(initializer=init) as executor:
        for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
            print('%d is prime: %s' % (number, prime))

if __name__ == '__main__':
    main()


...yields the following:


Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Traceback (most recent call last):
  File "/tmp/bpo34786.py", line 33, in <module>
    main()
  File "/tmp/bpo34786.py", line 29, in main
    for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 476, in _chain_from_iterable_of_lists
    for element in iterable:
  File "/Users/developer/cpython/Lib/concurrent/futures/_base.py", line 594, in result_iterator
    yield fs.pop().result()
  File "/Users/developer/cpython/Lib/concurrent/futures/_base.py", line 436, in result
    return self.__get_result()
  File "/Users/developer/cpython/Lib/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 09:40:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 13:40:05 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537796405.98.0.956365154283.issue34786@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Got it. Sorry about that I copy pasted the quoted string and assumed ThreadPoolExecutor overlooking the PR. The change is reasonable to me.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 09:41:27 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 13:41:27 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537796487.57.0.956365154283.issue34751@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +8937

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 09:48:28 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 13:48:28 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537796908.12.0.956365154283.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I created a new PR based on Tim's t ^= t << 7 idea, except that I'm using << 1 instead, to have more mixing in the lower bits.

With the standard FNV multiplier on 64 bits, I did get collisions while testing. I haven't figured out exactly why these occurred, but it's probably due to the high number of 0 bits. Instead, I chose 3**41 as multiplier. But of course, there are still plenty of bikeshedding opportunities for the multiplier...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:21:07 2018
From: report at bugs.python.org (lorenzogotuned)
Date: Mon, 24 Sep 2018 14:21:07 +0000
Subject: [issue34787] imghdr raise TypeError for PNG
Message-ID: <1537798867.67.0.956365154283.issue34787@psf.upfronthosting.co.za>


New submission from lorenzogotuned <tunedconsulting at gmail.com>:

Found on Python 3.6

This line https://github.com/python/cpython/blob/master/Lib/imghdr.py#L45
always raises`TypeError`as `startswith` does not accept bytes.

----------
messages: 326237
nosy: lorenzogotuned
priority: normal
severity: normal
status: open
title: imghdr raise TypeError for PNG
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34787>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:22:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 14:22:16 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537798936.48.0.956365154283.issue34783@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8938

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:22:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 14:22:37 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537798957.39.0.956365154283.issue34783@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote a non regression test: PR 9535.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:25:24 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 24 Sep 2018 14:25:24 +0000
Subject: [issue34787] imghdr raise TypeError for PNG
In-Reply-To: <1537798867.67.0.956365154283.issue34787@psf.upfronthosting.co.za>
Message-ID: <1537799124.69.0.956365154283.issue34787@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

startswith supports bytes just fine:

$ python3
Python 3.6.6 (default, Jul 19 2018, 14:25:17) 
[GCC 8.1.1 20180712 (Red Hat 8.1.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> with open('test.png', 'rb') as f:
...     header = f.read(1024)
... 
>>> header.startswith(b'\211PNG\r\n\032\n')
True

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34787>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:30:04 2018
From: report at bugs.python.org (Jeremy McMillan)
Date: Mon, 24 Sep 2018 14:30:04 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
Message-ID: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>


New submission from Jeremy McMillan <jeremy.mcmillan at gmail.com>:

ipaddress module has no support for scoped IPv6 addresses which prevents the use of ipaddress.ip_address() and ipaddress.IPv6Address() with (always available by default on IPv6 systems) RFC conforming IPv6 link local addresses that specify interface scope.

https://tools.ietf.org/html/rfc4007

This is bad because interface scope is required for connect() and bind() operations on multihomed machines, and virtualized or software defined networking will make this case very common.

eg.

>>> ipaddress.IPv6Address('fe80::dead:dead:beef:ffff')
IPv6Address('fe80::dead:dead:beef:ffff')
>>> ipaddress.IPv6Address('fe80::dead:dead:beef:ffff%eth0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1900, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1716, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in 'ffff%eth0' in 'fe80::dead:dead:beef:ffff%eth0'
>>> ipaddress.IPv6Interface('fe80::dead:dead:beef:ffff%eth0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 2060, in __init__
    IPv6Address.__init__(self, addr[0])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1900, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1716, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in 'ffff%eth0' in 'fe80::dead:dead:beef:ffff%eth0'

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 326240
nosy: Jeremy McMillan, docs at python
priority: normal
severity: normal
status: open
title: ipaddress module fails on rfc4007 scoped IPv6 addresses
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/issue34788>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:32:24 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Mon, 24 Sep 2018 14:32:24 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537799544.96.0.956365154283.issue34648@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

> The question that needs to be answered here is "why we should support
> Iterable[FrameSummary]?" and you're one the one who needs to answer
> it

Okay, here are a few reasons:
1) A function that requires that an input be a List invites the question ?why is an Iterable, or a Collection, or a Sequence, not sufficient??. Of course the best way to handle that question is to widen the API to accept at least a Sequence so that the question isn?t even asked, but the next-best way to handle the question is with an answer like ?because the function mutates the given List?. But that?s not the answer to the question here (which is a big part of why I opened the bug, asking the question more directly). So far the answer seems to be ?because we wanted to be conservative in our API design? and ?because we didn?t want to support what we weren?t testing?. Those are good answers, but I?d like to persuade you that they are no longer good enough.
2) Because List is invariant in element type whereas Sequence, Collection, and Iterable are covariant (I'm nearly certain) in element type, format_list is hard to use with type-checked code (see the discussion in https://github.com/python/typeshed/pull/2436 if you?re not following it already). Should the typeshed-canonicalized type of format_list?s ?extracted_list? parameter be ?List[FrameSummary]?? If so, then given a subclass MyFrameSummarySubclass of FrameSummary, List[MyFrameSummarySubclass] would *not* be valid to pass to format_list. That seems like a poor developer experience, right? If the type of ?extracted_list? were widened to Sequence[FrameSummary], Collection[FrameSummary], or (ideally) Iterable[FrameSummary], then an expression of type Iterable[MyFrameSummarySubclass] would be perfectly fine to pass for ?extracted_list?.
3) I tried to pass an Iterable[FrameSummary] to traceback.format_list in my own code. My situation is not itself open source but is a bit like this:

    def _FormatFrames(frame) -> str:
        """Generate a traceback of the current position of the thread in the code."""
        frame_tuples = []
        while frame:
            filename = <censored>
            lineno = frame.f_lineno
            line = <censored>
            frame_tuples.append((filename, lineno, frame.f_code.co_name, line,))
            frame = frame.f_back
        formatted_frame_strings = traceback.format_list(
            traceback.FrameSummary(file_name, line_number, frame_name, line=line)
            for file_name, line_number, frame_name, line in frame_tuples)
        return ''.join(formatted_frame_strings)

.

> instead of saying our design decisions were "absurd" and "not wise",
> without giving any concrete use cases for your "wider" design choice.

According to what we?ve learned over the course of the life and use of Python, and according to what we understand as best practices in the year 2018: I believe it is absolutely unwise to have offer an API that requires that a given parameter be a List without documenting the reasons sustaining that extremely limited design. Why won?t a Sequence suffice? Heck, why won?t some other implementation of MutableSequence suffice? Notice that I opened this bug with the question ?wait, really?? rather than the statement ?this is wrong and must be changed? - it might be the case that List is the best choice for the type of the parameter (though I now doubt it even more) but certainly it?s clear that *the documentation does not establish or communicate why a List is required*.

> Initial docstring for format_list() were added in 2000:
> https://github.com/python/cpython/commit/e7b146fb3bdc#diff-e57ff53a569d0ebbe201ad0c102ee27e
>
>     Given a list of tuples as returned by extract_tb() or
>     extract_stack(), return a list of strings ready for printing.

I have no doubt that that?s what was written in 2000, when we didn?t know nearly as much as we do today and when what were considered best practices were radically different. Now we know more - particularly for this case ?never ask for a List where asking for a MutableSequence will do, and never ask for a MutableSequence where asking for a Sequence will do, and never ask for a Sequence where asking for a Collection will do, and never ask for a Collection where asking for an Iterable will do?. The big question for format_list is ?will an Iterable do??. If not, that?s strange and unique by today?s standards and practices and the function?s documentation should at least give some enlightenment as to why it is the case.

> There are no tests for iterables other than list at
> https://github.com/python/cpython/blob/master/Lib/test/test_traceback.py 

I?d be happy to add some? except test_traceback.py doesn?t appear to contain any direct testing of format_list, and I can?t find ?the format_list tests? to which it alludes (https://github.com/python/cpython/search?q=format_list&unscoped_q=format_list). Is there any direct call to traceback.format_list under Lib/test? Where should tests of passing an Iterable to format_list be added?

> So we won't change documentation and docstrings, add more tests without seeing concrete
> use cases.

I wouldn?t be here if I were personally affected in my own use case, and as more and more users start statically verifying their code with mypy and pytype, more and more of them will be affected. This problem is worth solving.

> I meant an iterable that is extracted from a traceback object manually without
> using extract_tb() or extract_stack() functions (by using a custom function, an
> external dependency, or HTTP API) How people can get
> Iterable[FrameSummary] as an input and pass it to format_list()?

FrameSummary is a public class with a public constructor. Anyone can construct instances of it for any reason and aggregate them in any Iterable they please; the question before us is whether or not format_list should accept any such Iterable or should insist that callers re-aggregate their FrameSummarys in a List. I?ve only described here the only use case that I happen personally to have encountered, but I think it?s worth bearing in mind that *public code elements invite public use*, so we shouldn?t be surprised when FrameSummary and format_list get used for purposes for which they appear well-suited, but which weren?t necessarily envisioned.

> Are you serious?

Yes.

> No, we've introduced the new API and spent weeks designing it just
> to play with people. They should stick with the old one for no reason.

Thank you for this very strong affirmation, which is more constructive than I suspect you meant it to be. Note that the documentation of format_list doesn?t mention a preference for passing FrameSummarys over passing Tuples, but that may simply be a consequence of not writing the documentation with passing of caller-constructed-values-that-were-not-returned-by-extract_tb-or-extract_stack in mind. Over in https://github.com/python/typeshed/pull/2436 there?s some back-and-forth over what the *element type* of ?extracted_list? should be, and I?m in favor of going the extra mile and making it FrameSummary in 3.5-and-later rather than Union[Tuple[str, int, str, Optional[str]], FrameSummary]. It?s reasonable to say that if an author is being diligent enough to type-check their code, we can presume that they are diligent enough to use an API according to current best practices rather than making use of a backwards compatibility carve-out, right? It sounds like you might feel similarly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:41:31 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 24 Sep 2018 14:41:31 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537800091.33.0.956365154283.issue34334@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I debugged this issue and found that `format()` is being called twice and appending the traceback twice.

The first call - 
QueueHandler.emit() -> QueueHandler.prepare() -> self.format()  (which is the default Formatter)  -- this gets called with self.msg = 'Look out!' in this example.

The second call - 
StreamHandler.emit() ->  self.format() -- gets called with a record.msg = 'Look out!' + the traceback added in the first call above.  This call to format also appends the traceback because even though record.exc_info is None, record.exc_text is still set.


Because of the following note in `format()`:

        if record.exc_info:
            # Cache the traceback text to avoid converting it multiple times
            # (it's constant anyway)
            if not record.exc_text:
                record.exc_text = self.formatException(record.exc_info)


Even when record.exc_info has been set to None before the second call, record.exc_text still contains the cached value, which is re-appended in the next line:
        if record.exc_text:
            if s[-1:] != "\n":
                s = s + "\n"
            s = s + record.exc_text 

So the traceback appears twice.


Based on the design of this, my guess is the record.msg was never intended to contain the value with the traceback already appended to it, so I've made a PR with that change.  This will still allow record.message to have the change from issue31084, but record.msg won't get the traceback twice.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Mon Sep 24 10:57:45 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 24 Sep 2018 14:57:45 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537801065.16.0.956365154283.issue34334@psf.upfronthosting.co.za>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +8939
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:03:03 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 Sep 2018 15:03:03 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537801383.14.0.956365154283.issue34736@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Do you mean you'd like to have this behavior by default?

Ideally, yes, but I think that's out of scope for this bug report.

> I don't believe it is inherently misleading, though.

Yes, the "1 more than a multiple of 4" bit is clunky, but not misleading per se. It becomes misleading in combination with "length cannot be", since the obvious meaning of "length" here is the length of the string passed to the "b64decode" function, and that's not the correct interpretation in this context.

Your suggested rewording gets rid of the "length" reference, and looks like an improvement to me. "data characters" seems fairly clear, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:03:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:03:14 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1537801394.57.0.956365154283.issue34687@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8940
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:05:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:05:27 +0000
Subject: [issue23584] test_doctest lineendings fails in verbose mode
In-Reply-To: <1425487231.91.0.280595585638.issue23584@psf.upfronthosting.co.za>
Message-ID: <1537801527.66.0.956365154283.issue23584@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the patch. As part of triaging I am closing this as fixed since the patch was applied with the below commits except for 3.4 branch : 

09a08de363cbe18a87392e1c2ebf0ac1f414592c (3.5)
c747e5564f0315357a3e7d2f580c6d1c8a3b4ab8 (2.7)

Thanks

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23584>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:06:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:06:34 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537801594.31.0.956365154283.issue34783@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a46467ff198c42c8f34768c7be4b4562f6f44736 by Victor Stinner in branch 'master':
bpo-34783: Add test_cmd_line_script.test_nonexisting_script() (GH-9535)
https://github.com/python/cpython/commit/a46467ff198c42c8f34768c7be4b4562f6f44736


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:06:51 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 15:06:51 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537801611.58.0.956365154283.issue34783@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8941

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:07:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:07:02 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
In-Reply-To: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>
Message-ID: <1537801622.92.0.956365154283.issue34537@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:10:01 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 24 Sep 2018 15:10:01 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1537801801.32.0.956365154283.issue32797@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +8942

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:15:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:15:28 +0000
Subject: [issue28418] Raise Deprecation warning for tokenize.generate_tokens
In-Reply-To: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za>
Message-ID: <1537802128.15.0.956365154283.issue28418@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Since generate_tokens was made public and documented with issue12486 I am closing this issue as won't fix as part of triaging. Feel free to reopen this issue if needed.

Thanks

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28418>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:17:16 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:17:16 +0000
Subject: [issue32706] test_check_hostname() of test_ftplib started to fail
 randomly
In-Reply-To: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>
Message-ID: <1537802236.07.0.956365154283.issue32706@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Christian: It seems like the test now pass on my Fedora 27. Is it time to enable the test again?

Ignore my comment. I forgot that it's a race condition and I'm still able to get the failure using msg311097 scenario.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:23:59 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:23:59 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
In-Reply-To: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>
Message-ID: <1537802639.42.0.956365154283.issue26144@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am closing this issue as duplicate as part of triaging adding issue34200 as superseder that reports the same error along with a PR and discussion. There have been no failures reported with respect to test_pkg after the fix was merged. Feel free to reopen this if needed.

Thanks

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> importlib: python -m test test_pkg fails semi-randomly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26144>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:28:31 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 15:28:31 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537802911.07.0.956365154283.issue34783@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7a26222d7caa507fc46119ba9246f163502eb1fd by Miss Islington (bot) in branch '3.7':
bpo-34783: Add test_cmd_line_script.test_nonexisting_script() (GH-9535)
https://github.com/python/cpython/commit/7a26222d7caa507fc46119ba9246f163502eb1fd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:32:03 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:32:03 +0000
Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free
In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>
Message-ID: <1537803123.53.0.956365154283.issue26000@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

As part of triaging I am closing this issue as duplicate adding issue31852 as superseder which has the relevant PR and discussion about the fix. I have also verified the fix as in https://bugs.python.org/issue26000#msg326204. I think backporting the fix to Python 3.5 can be opened as a separate issue adding Larry since 3.5 is in security fixes mode if needed.

Thanks again everyone for the details.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Crashes with lines of the form "async \"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26000>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:34:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:34:52 +0000
Subject: [issue34783] [3.7] segmentation-fault/core dump when try to run
 non-existing file specified on commandline
In-Reply-To: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>
Message-ID: <1537803292.55.0.956365154283.issue34783@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thank you again eohm for your bug report and your analysis. Sadly, I chose to fix the issue differently, to reduce the maintenance burden on main.c: make the code closer to the master branch. My change is part of a long serie of changes to rework the Python initialization.

I added non regression test to 3.7 and master as well.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34783>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:37:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:37:50 +0000
Subject: [issue34223] PYTHONDUMPREFS=1 ./python -c pass does crash
In-Reply-To: <1532526817.78.0.56676864532.issue34223@psf.upfronthosting.co.za>
Message-ID: <1537803470.22.0.956365154283.issue34223@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I mark this issue as a duplicate of 30156.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> PYTHONDUMPREFS segfaults on exit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34223>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:38:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:38:28 +0000
Subject: [issue33309] Unittest Mock objects do not freeze arguments they are
 called with
In-Reply-To: <1524066784.49.0.682650639539.issue33309@psf.upfronthosting.co.za>
Message-ID: <1537803508.53.0.956365154283.issue33309@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the details. As part of triaging I am closing this as not a bug since passing mutable  arguments to a mock object and modifying it is a documented behavior at https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments . Feel free to reopen this if needed.

Thanks

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33309>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:41:06 2018
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 24 Sep 2018 15:41:06 +0000
Subject: [issue34648] Confirm the types of parameters of traceback.format_list
 and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537803666.03.0.956365154283.issue34648@psf.upfronthosting.co.za>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

> How people can get Iterable[FrameSummary] as an input and pass it to format_list()?

If I want to format a traceback, but omit traceback lines that refer to a particular module (for example, code for a coroutine runner), I could write `format_list(filter(lambda fs: 'asyncio' not in fs.filename, extract_stack())`.

I would also favor broadening the documented argument type for `format_list()` to say it accepts an iterable of FrameSummaries. No code change is necessary and it makes the code more flexible.

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34648>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:42:26 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:42:26 +0000
Subject: [issue31535] configparser unable to write comment with a upper cas
 letter
In-Reply-To: <1505924902.42.0.843371526892.issue31535@psf.upfronthosting.co.za>
Message-ID: <1537803746.73.0.956365154283.issue31535@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

All config options including comment are converted to lowercase when they are stored. You can customize this behavior using https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform . You can also refer to https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour for more customization. I am closing this as not a bug as part of triaging. Feel free to reopen this if needed.

Thanks for the report Philippe!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31535>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:49:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:49:08 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1537804148.06.0.956365154283.issue30156@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8943

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:50:48 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:50:48 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
In-Reply-To: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>
Message-ID: <1537804248.33.0.956365154283.issue34539@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks ?lvaro for the report and script. As part of triaging I am closing this as out of date since this bug seemed to have been fixed with issue34087 and is not reproducible on latest master and 3.7 branch. Feel free to reopen this if needed.

Thanks again!

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:52:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:52:54 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1537804374.68.0.956365154283.issue30156@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

PR 9541: my new attempt to remove the micro-optimization. Commit message:

bpo-30156: Remove property_descr_get() optimization

property_descr_get() uses a "cached" tuple to optimize function
calls. But this tuple can be discovered in debug mode with
sys.getobjects(). Remove the optimization, it's not really worth it
and it causes 3 different crashes last years.

Microbenchmark:

./python -m perf timeit -v \
    -s "from collections import namedtuple; P = namedtuple('P', 'x y'); p = P(1, 2)" \
    --duplicate 1024 "p.x"

Result:

Mean +- std dev: [ref] 32.8 ns +- 0.8 ns -> [patch] 40.4 ns +- 1.3 ns: 1.23x slower (+23%)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:54:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:54:05 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1537804445.84.0.956365154283.issue30156@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Is this optiization really worth it? 7 nanoseconds faster, but leak a weird tuple which caused 3 different crashes...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:58:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:58:45 +0000
Subject: [issue34037] asyncio: BaseEventLoop.close() shutdowns the executor
 without waiting causing leak of dangling threads
In-Reply-To: <1530658646.63.0.56676864532.issue34037@psf.upfronthosting.co.za>
Message-ID: <1537804725.13.0.956365154283.issue34037@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Maybe.  At least we need to add a "timeout" argument to asyncio.run() to let it wait for executor jobs.

The shutdown() method of concurrent.futures.Executor API doesn't accept a timeout. It waits for multiple things.

I added "block_on_close = True" class attribute to socketserver.ForkingMixIn and socketserver.ThreadingMixIn. By default, server_close() waits until all children complete, but the wait is non-blocking if block_on_close is false.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34037>
_______________________________________

From report at bugs.python.org  Mon Sep 24 11:59:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 15:59:22 +0000
Subject: [issue33977] [Windows] test_compileall fails randomly with
 PermissionError: [WinError 5] Access is denied: (...).pyc
In-Reply-To: <1530090995.62.0.56676864532.issue33977@psf.upfronthosting.co.za>
Message-ID: <1537804762.61.0.956365154283.issue33977@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33977>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:00:32 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 16:00:32 +0000
Subject: [issue26452] Wrong line number attributed to comprehension expressions
In-Reply-To: <1456640149.75.0.85936592027.issue26452@psf.upfronthosting.co.za>
Message-ID: <1537804832.0.0.956365154283.issue26452@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks much Greg for the details but I am closing this as fixed since there have been some improvements merged with issue12458 along with tests. The original issue reported regarding multi-line comprehension was fixed as I have tested it on https://bugs.python.org/issue26452#msg325985. I tested the patch but unfortunately had runtime errors. Feel free to reopen this if needed or any cases have been missed in the patch that you would like to make a PR.

Thanks :)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26452>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:04:07 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 16:04:07 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
Message-ID: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

Doc says:

"If parser_list is provided, it must be a *sequence* of strings which name modules that have a function named create_parser()"

but code concatenas parser_list with an existing list:

for parser_name in parser_list + default_parser_list:

Fix this by stating parser_list must be a specific kind of sequence, that is, a list.

----------
assignee: docs at python
components: Documentation
messages: 326261
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc xml.sax.make_parser expects a list not just any sequence
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:05:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 16:05:00 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1537805100.97.0.956365154283.issue34788@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34788>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:06:06 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 16:06:06 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537805166.8.0.956365154283.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
keywords: +patch
pull_requests: +8944
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:24:40 2018
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 24 Sep 2018 16:24:40 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537806280.67.0.956365154283.issue34789@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

I'm just going to presume this issue has been around a long time, but I think that's a pretty safe presumption.

Accepting a general sequence instead of only a list would reasonable, and I'd support a fix that caused the code to accept a general sequence (or any iterable) by calling list() on the passed-in value, starting with 3.8.

The patch provided looks good for versions in maintenance.  (It would also be fine for 3.8 if there's no interest in generalizing the code to accept arbitrary iterables).

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:29:17 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 24 Sep 2018 16:29:17 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1537806557.67.0.956365154283.issue22490@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks, I have confirmed that this reproduces our issue and that your PR fixes it. I guess at this point we need someone to test with Brew.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:30:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 16:30:09 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1537806609.26.0.956365154283.issue34788@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34788>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:30:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2018 16:30:48 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
 lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1537806648.03.0.956365154283.issue12458@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/issue12458>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:33:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2018 16:33:21 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
In-Reply-To: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>
Message-ID: <1537806801.69.0.956365154283.issue34364@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:35:09 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 24 Sep 2018 16:35:09 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
In-Reply-To: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>
Message-ID: <1537806909.95.0.956365154283.issue34364@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I worked on this at the core sprint, and I have a patch almost ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:39:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2018 16:39:24 +0000
Subject: [issue34372] Parenthesized expression has incorrect line numbers
In-Reply-To: <1533913344.46.0.56676864532.issue34372@psf.upfronthosting.co.za>
Message-ID: <1537807164.0.0.956365154283.issue34372@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Tracebacks should contain the first line of continuation lines
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:42:33 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 16:42:33 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
Message-ID: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.wait() accepts coroutines, wraps them into Tasks, and later returns those implicitly created Tasks in (done, pending) sets.  This is very confusing to new asyncio users and it's almost impossible to figure out what is going on.  See the first PR to the docs for more info.

Andrew, I think we should deprecate passing coroutines to asyncio.wait() in 3.8, and disallow that in 4.0.

----------
components: asyncio
messages: 326265
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate passing coroutine objects to asyncio.wait()
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:45:53 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 24 Sep 2018 16:45:53 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537807553.2.0.956365154283.issue34776@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Ned: I'm marking this as a release blocker because I'd like to get it in 3.7.1. If I can't do that in the next 5 hours or so, I'll remove the release blocker tag.

----------
assignee:  -> eric.smith
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:47:30 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 24 Sep 2018 16:47:30 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
Message-ID: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

On two occasions, the xml package uses environment variables to override parser / DOM implementations: xml.sax package and xml.dom.domreg module. On both occasions, the code should not use env vars to override module names, when the interpreter is started with flags like -E or -I.

----------
components: XML
messages: 326267
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: xml package does not obey sys.flags.ignore_environment
type: security
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:48:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 16:48:28 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537807708.61.0.956365154283.issue34790@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +8945
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:48:48 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2018 16:48:48 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
In-Reply-To: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>
Message-ID: <1537807728.71.0.956365154283.issue34364@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Great! I was going to take it. Will be glad to make a review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:53:09 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 24 Sep 2018 16:53:09 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>
Message-ID: <1537807989.28.0.956365154283.issue34791@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +8946
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:53:45 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 24 Sep 2018 16:53:45 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
In-Reply-To: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>
Message-ID: <1537808025.58.0.956365154283.issue34364@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

It's more elaborate than I'd like, but I think it's the right way to solve it: I'm passing in the starting line and column number to the parser machinery.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:56:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2018 16:56:26 +0000
Subject: [issue13607] Move generator specific sections out of ceval.
In-Reply-To: <1323993774.57.0.570625937446.issue13607@psf.upfronthosting.co.za>
Message-ID: <1537808186.45.0.956365154283.issue13607@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> out of date
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13607>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:56:40 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 24 Sep 2018 16:56:40 +0000
Subject: [issue31084] QueueHandler not formatting messages
In-Reply-To: <1501451530.82.0.0352443251136.issue31084@psf.upfronthosting.co.za>
Message-ID: <1537808200.88.0.956365154283.issue31084@psf.upfronthosting.co.za>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +8947

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31084>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:04:56 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 Sep 2018 17:04:56 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537808696.45.0.956365154283.issue34334@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Having looked at it again, Adrian Dries might be right that setting exc_text to None will also do the trick, and perhaps in a better way. The reasoning:

Handler.format() formats record.msg % record.args, and caches it in record.message. If there is exception information, it will format that and cache it in record.exc_text, then append the exception text to the message and return that.

So prepare() calling

msg = self.format(record)

will return the complete message and exception text in msg, and record will have record.message = record.msg % record.args, and record.exc_info and record.exc_text will have exception info.

When preparing, the prepare() method pretends that the already-formatted message was logged - record.msg % record.args is equivalent to record.message with no args, so it does

record.msg = msg (contains formatted message + exception info)
record.args = None (since the args have already been used)
record.exc_info = None (since the exception info has already been used)

but I forgot that record.exc_text should also be zapped, as it should always reflect the contents of record.exc_info. So I think that setting record.exc_text to None is perhaps the correct thing to do here, as Adrian originally suggested.

There should be a test that specifically exercises this with a QueueHandler and QueueListener - test_queue_listener needs to test for this case in case a regression reappears.

The reason for converting record.msg, record.args, record.exc_info and record.exc_text to record.msg = fully formatted message, None, None and None is that the arguments and exception trace may not be pickleable, which is a consideration when using multiprocessing queues. Otherwise we could just have passed them over unchanged.

Are you OK with changing the PR in line with the above, Cheryl?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:06:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2018 17:06:13 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537808773.43.0.956365154283.issue34790@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

4.0 is too far. Why not disallow them in 3.10?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:15:33 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 17:15:33 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537809333.4.0.956365154283.issue34790@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> 4.0 is too far. Why not disallow them in 3.10?

What's the current plan?  I thought it's going to be 3.8, 3.9, 4.0.  Is there a PEP detailing this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:21:16 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 17:21:16 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>
Message-ID: <1537809676.14.0.956365154283.issue34791@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 223e501fb9c2b6ae21b96054e20c4c31d94a5d96 by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-34791: xml package obeys ignore env flags (GH-9544)
https://github.com/python/cpython/commit/223e501fb9c2b6ae21b96054e20c4c31d94a5d96


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:21:27 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 17:21:27 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>
Message-ID: <1537809687.9.0.956365154283.issue34791@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8948

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:21:38 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 17:21:38 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>
Message-ID: <1537809698.18.0.956365154283.issue34791@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8949

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:21:51 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Sep 2018 17:21:51 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>
Message-ID: <1537809711.25.0.956365154283.issue34791@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:42:14 2018
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 24 Sep 2018 17:42:14 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1537810934.3.0.956365154283.issue32528@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com> added the comment:

What a shame, I've seen this error many times as well.

Surely making it BaseException will not break that much code?...

----------
nosy: +gustavo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:47:33 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 17:47:33 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1537811253.74.0.956365154283.issue32528@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Closing this issue as I, personally, don't see this happening and there's no point in keeping it open.

Actually, Andrew and I changed our opinion on this, so I'm re-opening the issue.

After visiting three conferences this summer and talking to asyncio users, it seems that this is a very serious pitfall.  At least 8 different people shared stories about really hard to debug problems caused by "except Exception" code blocking cancellation.

I now think we should fix this and make CancelledError a BaseException.  Doing that isn't as straightforward as it seems as we have to first fix how asyncio handles BaseExceptions (my next ToDo).

----------
resolution: rejected -> 
stage: resolved -> 
status: closed -> open
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:53:17 2018
From: report at bugs.python.org (mattip)
Date: Mon, 24 Sep 2018 17:53:17 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1537811597.16.0.956365154283.issue34778@psf.upfronthosting.co.za>


mattip <matti.picus at gmail.com> added the comment:

This could be done via a `shape` kwarg to `cast`

----------
nosy: +mattip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Mon Sep 24 13:58:52 2018
From: report at bugs.python.org (Mark Diekhans)
Date: Mon, 24 Sep 2018 17:58:52 +0000
Subject: [issue34792] Tutorial doesn''t discuss / and * function arguments
Message-ID: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>


New submission from Mark Diekhans <markd at kermodei.com>:

https://docs.python.org/3/tutorial/controlflow.html doest not discuss / and * arguments (end of positional, keyword required)

----------
assignee: docs at python
components: Documentation
messages: 326277
nosy: diekhans, docs at python
priority: normal
severity: normal
status: open
title: Tutorial doesn''t discuss / and * function arguments
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34792>
_______________________________________

From report at bugs.python.org  Mon Sep 24 14:05:12 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Sep 2018 18:05:12 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537812312.33.0.956365154283.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

> when you do t ^= t << 7, then you are not changing
> the lower 7 bits at all.

I want to leave low-order hash bits alone.  That's deliberate.

The most important tuple component types, for tuples that are hashable, are strings and contiguous ranges of "not huge" ints.  The current string hash works hard to "act randomly" in every bit position - there's no point in trying to "improve" anything about the hashes it already produces.

In contrast, the hashes of any contiguous range of N not-huge integers (excluding -1) are already, by construction, guaranteed to have no collisions at all in their low-order (roughly) log2(N) bits.  They can't be improved in this respect, because they're already optimal in this respect.

So, if anything, I'd look at increasing the left shift rather than reducing it.  The low bits are already un-improvable in the most important cases.


> So applications using hash(x) % 128 will still see
> all the problems that we are trying to fix.

?  The only "problem" I've seen identified was in mixing positive and negative integers.  Here on a 32-build with the FNV-1a 32-bit multiplier:

>> from itertools import product
>> from collections import Counter
>> cands = list(range(-50, 51))
>> cands.remove(-1)
>> c = Counter()
>> for t in product(cands, repeat=4):
..     c[hash(t) & 0x7f] += 1
>>> len(c)
128

So all 128 lower 7-bit patterns showed up.  And they're quite evenly distributed:

>>> c2 = Counter(c.values())
>>> for k in sorted(c2):
...     print(k, c2[k])
...
781202 1
781207 1
781209 2
781212 1
781213 2
781214 1
781215 4
781221 3
781222 1
781225 3
781226 1
781227 3
781228 2
781229 2
781230 1
781231 1
781232 2
781233 3
781234 1
781235 4
781236 2
781237 1
781238 2
781240 5
781241 6
781242 1
781243 1
781244 1
781245 1
781247 1
781248 2
781251 2
781252 4
781253 3
781254 5
781255 2
781256 2
781257 3
781259 2
781260 1
781261 1
781262 1
781263 2
781264 4
781265 2
781266 1
781267 1
781268 4
781269 1
781270 1
781271 2
781272 1
781274 2
781275 1
781276 1
781278 1
781280 1
781281 2
781282 2
781285 1
781286 2
781288 1
781295 1
781297 2
781301 1
781302 1
781304 1
781307 1

> With the standard FNV multiplier on 64 bits, I did
> get collisions while testing.

When testing what, specifically?  And the standard 32-bit FNV multiplier, or the standard 64-bit FNV multiplier?

> Instead, I chose 3**41 as multiplier. But of course,
> there are still plenty of bikeshedding opportunities
> for the multiplier...

Not for me.  If the universally used 64-bit FNV multiplier can't be used in the context of Python's tuple hash fiddled to use an almost-pure form of FNV-1a, then that approach is dead to me.  Needing to pick multipliers out of thin air instead implies the theory underlying FNV-1a doesn't transfer to this context.

About which I have no current opinion.  It may or may not.  Since we're flying blind, I'm just willing to _assume_ it does until proven otherwise by testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 14:16:19 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 18:16:19 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537812979.96.0.956365154283.issue34789@psf.upfronthosting.co.za>


Andr?s Delfino <adelfino at gmail.com> added the comment:

I think it makes sense for make_parser to accept any iterable too. I'll update the PR when I have the testcase ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 14:44:54 2018
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 24 Sep 2018 18:44:54 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537814694.61.0.545547206417.issue34789@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

It probably makes more sense to keep that PR for the maintenance branches, and create a new branch / PR to land on master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 14:57:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 18:57:32 +0000
Subject: [issue34793] Raise DeprecationWarning for "with (await lock):"
Message-ID: <1537815452.21.0.545547206417.issue34793@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
components: asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Raise DeprecationWarning for "with (await lock):"
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34793>
_______________________________________

From report at bugs.python.org  Mon Sep 24 15:01:51 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 19:01:51 +0000
Subject: [issue34792] Tutorial doesn''t discuss / and * function arguments
In-Reply-To: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>
Message-ID: <1537815711.87.0.545547206417.issue34792@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There is a related issue to document / in signatures though : https://bugs.python.org/issue21314

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34792>
_______________________________________

From report at bugs.python.org  Mon Sep 24 15:02:38 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 19:02:38 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537815758.91.0.545547206417.issue34790@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Mon Sep 24 15:03:31 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 19:03:31 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
Message-ID: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Never mind, we do this already.  The question is then should we just remove the support for this syntax entirely in 3.8, or we should wait until 3.9?

----------
title: Raise DeprecationWarning for "with (await lock):" -> Remove support for "with (await asyncio.lock):"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34793>
_______________________________________

From report at bugs.python.org  Mon Sep 24 15:33:47 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 19:33:47 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537817627.26.0.545547206417.issue34789@psf.upfronthosting.co.za>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Admittedly, my Git-fu is not strong, but since the PR was opened against master, and given that the PR as is won't be merged to master, can it still be "backported" to 3.7, 3.6, and 2.7?

Shouldn't I update the PR so it can be merged to master (that won't be backported), and then open a new PR against 3.7 that will be backported to 3.6 and 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 15:39:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Sep 2018 19:39:30 +0000
Subject: [issue34791] xml package does not obey sys.flags.ignore_environment
In-Reply-To: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>
Message-ID: <1537817970.69.0.545547206417.issue34791@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34791>
_______________________________________

From report at bugs.python.org  Mon Sep 24 15:40:30 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 Sep 2018 19:40:30 +0000
Subject: [issue34792] Tutorial doesn''t discuss / and * function arguments
In-Reply-To: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>
Message-ID: <1537818030.25.0.545547206417.issue34792@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34792>
_______________________________________

From report at bugs.python.org  Mon Sep 24 16:29:52 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 24 Sep 2018 20:29:52 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537820992.11.0.545547206417.issue5950@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Mon Sep 24 16:30:41 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 24 Sep 2018 20:30:41 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537821041.22.0.545547206417.issue5950@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

I've created a PR.

----------
nosy: +ZackerySpytz
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Mon Sep 24 16:51:21 2018
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 24 Sep 2018 20:51:21 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537822281.28.0.545547206417.issue34789@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

The existing PR can be re-targeted to merge to a maintenance branch (I'd be inclined to merge manually, myself, but will have to check the current devguide to make sure that's still allowed).

A new PR can be made for the non-documentation fix for master.

My thought is that a PR is more about the patch than about the workflow; a different patch can be handled in a separate PR, and review & discussion are used to determine which PR should be applied where.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:12:54 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 24 Sep 2018 21:12:54 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537823574.11.0.545547206417.issue34683@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:


New changeset 025eb98dc0c1dc27404df6c544fc2944e0fa9f3a by Guido van Rossum (Ammar Askar) in branch 'master':
bpo-34683: Make SyntaxError column offsets consistently 1-indexed (gh-9338)
https://github.com/python/cpython/commit/025eb98dc0c1dc27404df6c544fc2944e0fa9f3a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:14:00 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 24 Sep 2018 21:14:00 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537823639.99.0.545547206417.issue34683@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Fixed by gh-9338. Thanks Ammar!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:14:40 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 24 Sep 2018 21:14:40 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537823680.86.0.545547206417.issue34683@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hm, should this be backported? I think it's safest not to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:30:12 2018
From: report at bugs.python.org (David Talkin)
Date: Mon, 24 Sep 2018 21:30:12 +0000
Subject: [issue34794] memory leak in TkApp:_createbytearray
Message-ID: <1537824612.19.0.545547206417.issue34794@psf.upfronthosting.co.za>


New submission from David Talkin <dtalkin at gmail.com>:

The Tkinter.PhotoImage class leaks memory with each change of the 'data' Attribute due to Image calling tk._createbytearray, which allocates memory, but never frees it.

The offending method is in the TkApp class, _createbytearray().

----------
components: Tkinter
messages: 326289
nosy: dtalkin
priority: normal
severity: normal
status: open
title: memory leak in TkApp:_createbytearray
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34794>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:37:16 2018
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Sep 2018 21:37:16 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537825036.07.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Jeroen, I understood the part about -2 from your initial report ;-)  That's why the last code I posted didn't use -2 at all (neither -1, which hashes to -2).  None of the very many colliding tuples contained -2 in any form.  For example, these 8 tuples all have the same hash now:

(-4,  -4,  -4,  40)    (-4,  -4,  4, -48)
( 4,   4,  -4,  40)    ( 4,   4,  4, -48)
(-4,  28, -28, -48)    (-4,  28, 28,  40)
( 4, -28, -28, -48)    ( 4, -28, 28,  40)

Your last example (with (3, -2) and (-3, 0)) also implicitly relies on that:

    j is even implies (j ^ -3) == -(j ^ 3)

There are apparently piles of similar identities :-(

I appreciate that

    a*M + C = b*M + C (mod N)

implies

    a = b (mod N)

when M is coprime to N, and also that the theory of linear combinations modulo 2**K is far better known than the well-hidden theory FNV developed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:37:51 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Sep 2018 21:37:51 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537825071.92.0.545547206417.issue34781@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:40:22 2018
From: report at bugs.python.org (Neil Booth)
Date: Mon, 24 Sep 2018 21:40:22 +0000
Subject: [issue34795] loop.sock_recv failure because of delayed callback
 handling
Message-ID: <1537825222.42.0.545547206417.issue34795@psf.upfronthosting.co.za>


New submission from Neil Booth <kyuupichan at gmail.com>:

In certain circumstances the coroutine loop.sock_recv() registers a callback internally, which is called on e.g. task cancellation.  The callback assumes a file descriptor that was open and valid at the time the callback was registered is still open and valid when the callback is called, and this need not be the case.  For example, when client code handling exceptions (in particular, cancellation) closes the socket itself.

I have reports of this error for Python 3.6 and 3.7 by a user of my library which uses asyncio, and that bad things happen on both Windows (the event loop dies) and Linux (a traceback happens but no loop death).
It likely happens in earlier versions of Python too but my library requires >= Python 3.6

I hope the above description in addition to pointing out the problematic lines in asyncio make the bug clear.  I tried to produce a simplified testcase but it doesn't trigger the issue on Linux.  I am told it does trigger it on Windows (I don't have Windows to test on).

Here are the problematic lines in selector_events.py where the FD is registered; the callback above them assumes the DF remains valid (but the socket might have been closed in the meantime):

https://github.com/python/cpython/blob/master/Lib/asyncio/selector_events.py#L378-L380

The same problem is evident in sock_recv_into, and perhaps other calls.

Here is code I am told triggers the problem on Windows; it seems to require something a little more complex to trigger reliably on Unix platforms:


import asyncio
import socket


class MyProtocol(asyncio.Protocol):

    def connection_made(self, transport):
        transport.write(b'123')   # just in case a write is needed


port = 6666


async def connect_and_recv(loop, sock):
    try:
        await loop.sock_connect(sock, ('127.0.0.1', port))
        while True:
            await loop.sock_recv(sock, 20)
    except asyncio.CancelledError:
        print("Cancelled")
        sock.close()


async def main(loop):
    server = await loop.create_server(MyProtocol, '127.0.0.1', port)
    sock = socket.socket()
    sock.setblocking(False)
    task = loop.create_task(connect_and_recv(loop, sock))
    await asyncio.sleep(0.1)
    task.cancel()
    await asyncio.sleep(0.1)


loop = asyncio.get_event_loop()
loop.run_until_complete(main(loop))



Here are backtraces from a client application doing things more complex but similar in spirit to the snippet above:

  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\asyncio\base_events.py", line 455, in run_until_complete
    self.run_forever()
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\asyncio\base_events.py", line 422, in run_forever
    self._run_once()
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\asyncio\base_events.py", line 1398, in _run_once
    event_list = self._selector.select(timeout)
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\selectors.py", line 323, in select
    r, w, _ = self._select(self._readers, self._writers, [], timeout)
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\selectors.py", line 314, in _select
    r, w, x = select.select(r, w, w, timeout)
OSError: [WinError 10038] An operation was attempted on something that is not a socket

and one for Linux:

Exception in callback BaseSelectorEventLoop._sock_recv(<Future cancelled>, True, <socket.socke...2049, proto=0>, 5)
handle: <Handle BaseSelectorEventLoop._sock_recv(<Future cancelled>, True, <socket.socke...2049, proto=0>, 5)>
Traceback (most recent call last):
  File "/usr/lib/python3.6/asyncio/events.py", line 127, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.6/asyncio/selector_events.py", line 378, in _sock_recv
    self.remove_reader(fd)
  File "/usr/lib/python3.6/asyncio/selector_events.py", line 342, in remove_reader
    return self._remove_reader(fd)
  File "/usr/lib/python3.6/asyncio/selector_events.py", line 279, in _remove_reader
    key = self._selector.get_key(fd)
  File "/usr/lib/python3.6/selectors.py", line 189, in get_key
    return mapping[fileobj]
  File "/usr/lib/python3.6/selectors.py", line 70, in __getitem__
    fd = self._selector._fileobj_lookup(fileobj)
  File "/usr/lib/python3.6/selectors.py", line 224, in _fileobj_lookup
    return _fileobj_to_fd(fileobj)
  File "/usr/lib/python3.6/selectors.py", line 41, in _fileobj_to_fd
    raise ValueError("Invalid file descriptor: {}".format(fd))
ValueError: Invalid file descriptor: -1

----------
components: asyncio
messages: 326291
nosy: asvetlov, kyuupichan, yselivanov
priority: normal
severity: normal
status: open
title: loop.sock_recv failure because of delayed callback handling
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34795>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:44:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 21:44:35 +0000
Subject: [issue34795] loop.sock_recv failure because of delayed callback
 handling
In-Reply-To: <1537825222.42.0.545547206417.issue34795@psf.upfronthosting.co.za>
Message-ID: <1537825475.58.0.545547206417.issue34795@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Can you reproduce this with uvloop?

Andrew: I think we need to "lock" sockets from closing in sock_recv and friends the same way we do it in uvloop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34795>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:47:01 2018
From: report at bugs.python.org (Neil Booth)
Date: Mon, 24 Sep 2018 21:47:01 +0000
Subject: [issue34795] loop.sock_recv failure because of delayed callback
 handling
In-Reply-To: <1537825222.42.0.545547206417.issue34795@psf.upfronthosting.co.za>
Message-ID: <1537825621.31.0.545547206417.issue34795@psf.upfronthosting.co.za>


Neil Booth <kyuupichan at gmail.com> added the comment:

This seems related: https://bugs.python.org/issue30064

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34795>
_______________________________________

From report at bugs.python.org  Mon Sep 24 17:57:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 21:57:11 +0000
Subject: [issue30064] BaseSelectorEventLoop.sock_{recv,
 sendall}() don't remove their callbacks when canceled
In-Reply-To: <1492073709.93.0.33740565749.issue30064@psf.upfronthosting.co.za>
Message-ID: <1537826231.42.0.545547206417.issue30064@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

See also https://bugs.python.org/issue34795

----------
nosy: +asvetlov
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30064>
_______________________________________

From report at bugs.python.org  Mon Sep 24 18:01:33 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 24 Sep 2018 22:01:33 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1537826493.06.0.545547206417.issue32892@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I've checked Quixote PTL module support.  I will have to make some changes to support the removal of Str and other node types.  E.g. I have to change visit_Str to visit_Constant.  The fixes are pretty easy though and I think it is reasonable that this kind of AST manipulation is dependent on Python version and may get broken between releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Mon Sep 24 18:22:15 2018
From: report at bugs.python.org (Neil Booth)
Date: Mon, 24 Sep 2018 22:22:15 +0000
Subject: [issue34795] loop.sock_recv failure because of delayed callback
 handling
In-Reply-To: <1537825222.42.0.545547206417.issue34795@psf.upfronthosting.co.za>
Message-ID: <1537827735.56.0.545547206417.issue34795@psf.upfronthosting.co.za>


Neil Booth <kyuupichan at gmail.com> added the comment:

My library user reports:

I can't reproduce the issue with uvloop on linux. (looks like uvloop does not work on windows atm)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34795>
_______________________________________

From report at bugs.python.org  Mon Sep 24 18:58:50 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Sep 2018 22:58:50 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537829930.1.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8952
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 19:15:44 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Sep 2018 23:15:44 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537830944.72.0.545547206417.issue34162@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 5a606674edbf4a94370ee55b0906dd9bec83abb0 by Terry Jan Reedy in branch 'master':
bpo-34162: Add entry for idlelib/NEWS.txt already included for 3.6/3.7 (GH-9549)
https://github.com/python/cpython/commit/5a606674edbf4a94370ee55b0906dd9bec83abb0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 19:28:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Sep 2018 23:28:19 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537831699.07.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8953

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 19:43:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Sep 2018 23:43:57 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537832637.23.0.545547206417.issue34162@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 65fa1264a308a94e24afa76f41a68708a346738f by Terry Jan Reedy in branch '2.7':
[2.7] bpo-34162: Update 2.7 idlelib/NEWS.txt to 2018-9-24 (GH-9550)
https://github.com/python/cpython/commit/65fa1264a308a94e24afa76f41a68708a346738f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 19:45:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Sep 2018 23:45:09 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537832709.82.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8954

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:08:44 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 00:08:44 +0000
Subject: [issue34796] Tkinter scrollbar issues on Mac.
Message-ID: <1537834124.67.0.545547206417.issue34796@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

#34047 was about scrollbar issues on MacOS in 3.7.0 and 3.6.6.  One was due to an IDLE bug, which was fixed on the issue.  Others, which can be demonstrated in the pure tkinter code below, are the subject of this issue.

1. Slider does not move properly when at top or bottom.
2. Clicking trough near slider at top or bottom has no effect.
See #34047 for more discussions and details.

Vlad Tudorache posted the code below as msg323349 of #34047 and attached as tktest.py, along with tkinter_scroll_issues.mov.
---

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
 
def click_trace(event):
    text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x, event.y, vbar.identify(event.x, event.y)))

vbar.bind('<Button-1>', click_trace)

root.mainloop()
---

"Clicking at the top on the slider shows that the Scrollbar considers it as being on "through1" (in Tk the zone between the upper arrow and the "slider") and NOT on the "slider". Please, play with the script (python3 tktest.py) and see the results for yourselves."

----------
components: Tkinter, macOS
messages: 326299
nosy: ned.deily, ronaldoussoren, serhiy.storchaka, terry.reedy, wordtech
priority: normal
severity: normal
stage: needs patch
status: open
title: Tkinter scrollbar issues on Mac.
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34796>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:10:13 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 00:10:13 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1537834213.41.0.545547206417.issue34047@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I opened #34796 for the scrollbar slider issues.

----------
superseder:  -> Tkinter scrollbar issues on Mac.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:11:49 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 00:11:49 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537834309.89.0.545547206417.issue34162@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 16fba6231458cc1ff82db8695ee772b74131cc83 by Terry Jan Reedy in branch 'master':
bpo-34162: Update idlelib/NEWS.txt to 2018-9-24. (GH-9551)
https://github.com/python/cpython/commit/16fba6231458cc1ff82db8695ee772b74131cc83


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:11:56 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 00:11:56 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537834316.81.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8955

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:12:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 00:12:03 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537834323.2.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8956

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:13:22 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Sep 2018 00:13:22 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537834402.61.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

> advantage of my approach is that high-order bits become more
> important:

I don't much care about high-order bits, beyond that we don't systematically _lose_ them.  The dict and set lookup routines have their own strategies for incorporating high-order bits into the probe sequence, and those routines are the primary reason hash() exists in Python.

So there's scant reason to try to let high bits influence low bits (but good reason _not_ to, because - as explained before - the low-order bits are already in great shape for the important tuple component types).

Something else appears to be going on in this specific example, which has a very touchy set of hash codes:

> BEFORE:
> >>> L = [n << 60 for n in range(100)]; T = [(a,b,c) for a in L for b in L for c in L]; len(set(hash(x) for x in T))
> 500000

Which is what I get too on (at least) a 64-bit build.

> AFTER:
> >>> L = [n << 60 for n in range(100)]; T = [(a,b,c) for a in L for b in L for c in L]; len(set(hash(x) for x in T))
> 1000000

Ditto.  However, I get exactly the same from the code I posted before, which has no right shifts at all.

More, if I take the code exactly as it exists today, and merely comment out the

    mult += (Py_hash_t)(82520UL + len + len);

line, I also get a million distinct hash codes.

Half of the hash codes have bit 2**60 set, and apart from those all the hash codes have no bits set higher than 2**6.  Any number of accidents could cause the 2**60 bits to wipe each other out, and merely changing the sequence of multipliers was demonstrably enough to stop that.

Indeed, merely changing 82520 to 82524 in the current code is enough to get a million unique hash codes in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:23:14 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 00:23:14 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537834994.2.0.545547206417.issue34162@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 65cc60b3687d33bfeda60b29a49a0708d4932b7b by Miss Islington (bot) in branch '3.7':
bpo-34162: Update idlelib/NEWS.txt to 2018-9-24. (GH-9551)
https://github.com/python/cpython/commit/65cc60b3687d33bfeda60b29a49a0708d4932b7b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:35:30 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 00:35:30 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537835730.0.0.545547206417.issue34162@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1ab9dfcfbe99d576b41209ca8ddbcacb682e4495 by Miss Islington (bot) in branch '3.6':
bpo-34162: Update idlelib/NEWS.txt to 2018-9-24. (GH-9551)
https://github.com/python/cpython/commit/1ab9dfcfbe99d576b41209ca8ddbcacb682e4495


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:36:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 00:36:21 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537835781.98.0.545547206417.issue34162@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The cutoff for PRs going into 3.7.0 was the rc1 on about 2018 May 15.  The first 3 PRs are for merges after that cutoff but before the 3.6.6/3.7.0 release.  PR9549 adds an entry to master that was somehow omitted even though included in the backports to 3.7 and 3.6.

PR9550 updates 2.7 (rarely needed).  The next update to now.  If I merge anything else for 3.6.7/3.7.1, I might include NEWS in the PR.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Mon Sep 24 20:42:29 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Sep 2018 00:42:29 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537836149.09.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Just noting that this Bernstein-like variant appears to work as well as the FNV-1a version in all the goofy ;-) endcase tests I've accumulated:

    while (--len >= 0) {
        y = PyObject_Hash(*p++);
        if (y == -1)
            return -1;
        Py_uhash_t t = (Py_uhash_t)y;
        t ^= t << 7;
        x = x * mult + t;
    }

They're identical except for the last line.  FNV-1a uses

         x = (x ^ t) * mult;

instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 21:07:46 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 25 Sep 2018 01:07:46 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537837666.04.0.545547206417.issue34776@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Unfortunately, I'm not going to be able to give this the attention it deserves before the 3.7.1 cutoff. The changes are sufficiently tricky that I want to make sure I think through the issue in the appropriate detail.

Ned: I've made it not a release blocker. Please remove yourself as nosy if you don't care about this issue. I don't plan on making it a release blocker again, I just did that because it was so near the deadline.

Yury: Sorry for not being able to get delve in to it sufficiently. Thanks for your work on it.

I should be able to review this in the next few days, so we can get this in to 3.7.2.

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Sep 24 21:23:04 2018
From: report at bugs.python.org (Lisa Roach)
Date: Tue, 25 Sep 2018 01:23:04 +0000
Subject: [issue34659] Inconsistency between functools.reduce &
 itertools.accumulate
In-Reply-To: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>
Message-ID: <1537838584.37.0.545547206417.issue34659@psf.upfronthosting.co.za>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34659>
_______________________________________

From report at bugs.python.org  Mon Sep 24 21:49:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Sep 2018 01:49:35 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537840175.1.0.545547206417.issue34776@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

NP, Eric, take your time. I agree that the PR isn't simple and needs a very careful review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Sep 24 21:51:50 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Sep 2018 01:51:50 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537840310.17.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

And one more:

        x = (x * mult) ^ t;

also appears to work equally well.  So, way back when, it appears we _could_ have wormed around the disaster du jour just by applying a shift-xor permutation to the raw hash results.

Note the implication:  if we believed our tuple hash worked OK before then (& we did), adding a shift-xor step would have changed nothing about it _except_ to permute the input space.  That alone was enough to repair the nested tuple problems.

Note that permutations are a bog standard way to improve algorithms with bad behaviors in some cases.  For example, at the end of the Mersenne Twister they do 4 permutations to improve otherwise-marginal results from "the real" pseudo-random generator:

    y ^= (y >> 11);
    y ^= (y << 7) & 0x9d2c5680U;
    y ^= (y << 15) & 0xefc60000U;
    y ^= (y >> 18);
    return y;

At this point I see no "good reason" to prefer any of

    x = (x * mult) ^ t; // like Bernstein 33X & FNV-1
    x = (x * mult) + t; // like Bernstein 33A
    x = (x ^ t) * mult; // like FNV-1a

to any other.  In their _original_ contexts, they were applied to longish sequences of unsigned bytes.  But tuples used as keys and set elements are typically much shorter than strings, so results about how they worked in their original contexts are largely irrelevant for that reason too.

While lots of non-endcase testing is also needed, at this point I don't have any real fear about any of them.

As a sanity check,

        x = (x * mult) | t;

is disastrous for all the endcase tests.  So I believe I really am compiling and running the code ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Mon Sep 24 22:01:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 02:01:17 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537840877.96.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tal, if you think this is ready, I would like to get this in the upcoming releases.  I believe the deadline is midnight at the international dateline, which is noon UTC tomorrow, just over 9 hours from now. 

I decided that any suggestions I might have for the non-user-visible aspects of squeezer.py and test_squeezer.py can wait for later.  The best review of user-visible aspects will come from using it.

A second use of squeezer should be debugger's global and non-global('local') namespace displays.  The intended format is one name-value pair per line.  But values can be indefinitely large.  For this, we could skip the context menu (there is not one now), use a fixed trigger of n characters, and have double-click display to a popup Squeezer View.

I will come back to this in a couple of hours to see if you have responded.  I would write and merge a separate expanded news entry for idlelib/NEWS.txt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Mon Sep 24 22:12:37 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Tue, 25 Sep 2018 02:12:37 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537841557.86.0.545547206417.issue32956@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

This was so surprising to me that I had to check some other languages that I had handy. It turns out that not one of JavaScript, Ruby, Perl, C++, Java, Go, or Rust agrees with Python. In fact they all agreed with one another that 2.5 should round to 3. Examples below.

I understand from https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259 that "to always round up... can theoretically skew the data" but it's not clear why that's a good enough reason to differ from the "round" function in all these other languages (as opposed to e.g. offering this alternative behavior in some additional "round_unskewed" function).

I assume the rationale for having Python 3's "round" differ from that of so many other languages was written down when this decision was made, but I searched and couldn't find it. Could anyone link to it in a comment here?

And would it be worth including rationale and a larger callout in the https://docs.python.org/3/library/functions.html#round docs? The documentation of this behavior is a bit buried among other things, and the rationale for it is missing entirely.


$ node -e 'console.log(Math.round(2.5))'
3

$ ruby -e 'puts (2.5).round()'
3

$ perl -e 'use Math::Round; print round(2.5)'
3

$ cat test_round.cpp
#include <stdio.h>
#include <math.h>
int main(void) {
  printf("%f\n", round(2.5));
}
$ g++ test_round.cpp && ./a.out
3.000000

$ cat TestRound.java
class TestRound {
  public static void main(String[] args) {
    System.out.println(Math.round(2.5));
  }
}
$ javac TestRound.java && java TestRound
3

$ cat test_round.go
package main
import "fmt"
import "math"
func main() {
	fmt.Println(math.Round(2.5))
}
$ go build test_round.go && ./test_round
3

$ cat test_round.rs
fn main() {
  println!("{}", (2.5_f64).round());
}
$ rustc test_round.rs && ./test_round
3

----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Mon Sep 24 22:34:31 2018
From: report at bugs.python.org (Jeremy McMillan)
Date: Tue, 25 Sep 2018 02:34:31 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1537842871.9.0.545547206417.issue34788@psf.upfronthosting.co.za>


Jeremy McMillan <jeremy.mcmillan at gmail.com> added the comment:

subclass workaround implementation example

https://github.com/isbm/salt/blob/976fe19d73ca6bf5df375eaa15d77ce4a5a54b7a/salt/_compat.py#L125

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34788>
_______________________________________

From report at bugs.python.org  Mon Sep 24 23:08:24 2018
From: report at bugs.python.org (Ben Darnell)
Date: Tue, 25 Sep 2018 03:08:24 +0000
Subject: [issue34700] typing.get_type_hints doesn't know about typeshed
In-Reply-To: <1537042200.54.0.956365154283.issue34700@psf.upfronthosting.co.za>
Message-ID: <1537844904.88.0.545547206417.issue34700@psf.upfronthosting.co.za>


Ben Darnell <ben.darnell at gmail.com> added the comment:

Yeah, I think that would work at least for the sphinx use case. It seems like a strange partially-degraded mode and anything that needs structured access to the annotation would still need typeshed, but just getting the string would probably be enough for a lot of applications. In fact, sphinx *only* wants the string (AFAICT), so a separate method like get_type_hints_as_string() which stringifies everything even if it can be resolved might be a better route than an option to get_type_hints().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34700>
_______________________________________

From report at bugs.python.org  Mon Sep 24 23:33:31 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 03:33:31 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537846411.61.0.545547206417.issue34786@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34786>
_______________________________________

From report at bugs.python.org  Mon Sep 24 23:34:47 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Sep 2018 03:34:47 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537846487.77.0.545547206417.issue32956@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Mon Sep 24 23:38:07 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 25 Sep 2018 03:38:07 +0000
Subject: [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537846687.74.0.545547206417.issue34786@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/issue34786>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:01:50 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 25 Sep 2018 04:01:50 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537848110.34.0.545547206417.issue34776@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:02:43 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 25 Sep 2018 04:02:43 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1537848163.13.0.545547206417.issue34776@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fwiw, agreed that this should wait for 3.7.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:23:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 04:23:50 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>
Message-ID: <1537849430.94.0.545547206417.issue34793@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I can see only around 3 results on GitHub with "with await asyncio.lock"  and just wanted to add it as a data point : https://github.com/search?utf8=%E2%9C%93&q=%22with+await+asyncio.lock%22&type=Code

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34793>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:25:28 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 04:25:28 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537849528.17.0.545547206417.issue34770@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f6c8007a29b95b3ea3ca687a9b4924769a696328 by Miss Islington (bot) (Zackery Spytz) in branch 'master':
bpo-34770: Fix a possible null pointer dereference in pyshellext.cpp (GH-9497)
https://github.com/python/cpython/commit/f6c8007a29b95b3ea3ca687a9b4924769a696328


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:25:36 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 04:25:36 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537849536.83.0.545547206417.issue34770@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:25:44 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 04:25:44 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537849544.52.0.545547206417.issue34770@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8959

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:27:00 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 04:27:00 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>
Message-ID: <1537849620.64.0.545547206417.issue34793@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Another discussion : https://github.com/python/cpython/pull/4753/files#r155656583

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34793>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:44:16 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 04:44:16 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537850656.27.0.545547206417.issue34770@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset db23206367e2bfbbdfb29b7699f25a14ba353ae7 by Miss Islington (bot) in branch '3.7':
bpo-34770: Fix a possible null pointer dereference in pyshellext.cpp (GH-9497)
https://github.com/python/cpython/commit/db23206367e2bfbbdfb29b7699f25a14ba353ae7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:47:14 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 04:47:14 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537850834.76.0.545547206417.issue34770@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 936d740ac0308fdcb87c11cbe87962d4fe06f5ab by Miss Islington (bot) in branch '3.6':
bpo-34770: Fix a possible null pointer dereference in pyshellext.cpp (GH-9497)
https://github.com/python/cpython/commit/936d740ac0308fdcb87c11cbe87962d4fe06f5ab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34770>
_______________________________________

From report at bugs.python.org  Tue Sep 25 00:53:03 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Sep 2018 04:53:03 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537851183.93.0.545547206417.issue34683@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Wait, why did you make offsets 1-indexed? My suggestion was to make everything zero indexed...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Tue Sep 25 01:06:05 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 25 Sep 2018 05:06:05 +0000
Subject: [issue34770] pyshellext.cpp: Possible null pointer dereference
In-Reply-To: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>
Message-ID: <1537851965.52.0.545547206417.issue34770@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/issue34770>
_______________________________________

From report at bugs.python.org  Tue Sep 25 01:20:02 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 05:20:02 +0000
Subject: [issue22079] Ensure in PyType_Ready() that base class of static type
 is static
In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>
Message-ID: <1537852802.68.0.545547206417.issue22079@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> It would be good if PyType_Ready() will check that base class of static type is static.

What's the rationale for this change? It's not explained in this bug report nor in the code.

----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22079>
_______________________________________

From report at bugs.python.org  Tue Sep 25 01:35:14 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 05:35:14 +0000
Subject: [issue31177] unittest mock's reset_mock throws an error when an
 attribute has been deleted
In-Reply-To: <1502374939.75.0.688742031254.issue31177@psf.upfronthosting.co.za>
Message-ID: <1537853714.55.0.545547206417.issue31177@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Adding Michael for thoughts on the fix and desired behavior. Removing 3.5 since only security fixes are accepted and adding 3.8 which is also affected.

Thanks

----------
nosy: +michael.foord
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31177>
_______________________________________

From report at bugs.python.org  Tue Sep 25 01:41:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 25 Sep 2018 05:41:50 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537854110.03.0.545547206417.issue34759@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

This issue can now be closed, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Tue Sep 25 01:43:42 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 25 Sep 2018 05:43:42 +0000
Subject: [issue34759] Possible regression in ssl module in 3.7.1 and master
In-Reply-To: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>
Message-ID: <1537854222.54.0.545547206417.issue34759@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Whoops, yep, I forgot it doesn't auto-close.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34759>
_______________________________________

From report at bugs.python.org  Tue Sep 25 01:49:20 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 25 Sep 2018 05:49:20 +0000
Subject: [issue29988] with statements are not ensuring that __exit__ is called
 if __enter__ succeeds
In-Reply-To: <1491349378.03.0.0671954460373.issue29988@psf.upfronthosting.co.za>
Message-ID: <1537854560.67.0.545547206417.issue29988@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29988>
_______________________________________

From report at bugs.python.org  Tue Sep 25 02:34:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 06:34:50 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537857290.69.0.545547206417.issue32956@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See the discussion on the Python-Dev mailing list: https://mail.python.org/pipermail/python-dev/2008-January/075863.html.

For C look at the rint() function. It is a common knowledge that rounding half-to-even is what users want in most cases, but it is a tiny bit more expensive in C. In Python the additional cost of such rounding is insignificant.

----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Tue Sep 25 02:38:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 06:38:24 +0000
Subject: [issue34777] urllib.request accepts anything as a header parameter
 for some URLs
In-Reply-To: <1537718868.74.0.956365154283.issue34777@psf.upfronthosting.co.za>
Message-ID: <1537857504.82.0.545547206417.issue34777@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. I tried similar requests and it works this way for other tools like curl since Akcept could be a custom header in some use cases though it could be a  typo in this context. There is no predefined set of media types that we need to validate as far as I can see from https://tools.ietf.org/html/rfc2616#section-14.1 and it depends on the server configuration to do validation. It's hard for Python to maintain a list of acceptable MIME types for validation across releases. A list of registered MIME types that is updated periodically : https://www.iana.org/assignments/media-types/media-types.xhtml and RFC for registration : https://tools.ietf.org/html/rfc6838

Some sample requests from curl with invalid headers.

curl -X GET https://httpbin.org/get -H 'Authorization: Token bc23f14356c114a8ffa319773583426878b7b37f' -H 'Cache-Control: no-cache' -H 'Content-Type: application/json' -H 'Akcept: tekst/csv'
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Akcept": "tekst/csv",
    "Authorization": "Token bc23f14356c114a8ffa319773583426878b7b37f",
    "Cache-Control": "no-cache",
    "Connection": "close",
    "Content-Type": "application/json",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.37.1"
  },
  "origin": "182.73.135.26",
  "url": "https://httpbin.org/get"
}

curl -X GET https://httpbin.org/get -H 'Authorization: Token bc23f14356c114a8ffa319773583426878b7b37f' -H 'Cache-Control: no-cache' -H 'Content-Type: application/json' -H 'Accept: tekst'
{
  "args": {},
  "headers": {
    "Accept": "tekst",
    "Authorization": "Token bc23f14356c114a8ffa319773583426878b7b37f",
    "Cache-Control": "no-cache",
    "Connection": "close",
    "Content-Type": "application/json",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.37.1"
  },
  "origin": "182.73.135.26",
  "url": "https://httpbin.org/get"
}

Feel free to add in if I am missing something here but I think it's hard for Python to maintain the updated list and adding warning/error might break someone's code.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

From report at bugs.python.org  Tue Sep 25 02:55:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 06:55:24 +0000
Subject: [issue34794] memory leak in TkApp:_createbytearray
In-Reply-To: <1537824612.19.0.545547206417.issue34794@psf.upfronthosting.co.za>
Message-ID: <1537858524.51.0.545547206417.issue34794@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report David. Feel free to attach reproducible script if any that might trigger this. I am adding Serhiy who might have a better understanding of this. Relevant issue where _createbytearray was added : issue21580 .

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34794>
_______________________________________

From report at bugs.python.org  Tue Sep 25 03:11:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Sep 2018 07:11:00 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537859460.91.0.545547206417.issue33937@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8960
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 03:12:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Sep 2018 07:12:03 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537859523.68.0.545547206417.issue33937@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 9557 to fix the issue. test_socket fails frequently on Travis CI, on the three Python 3.x branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 03:16:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 07:16:24 +0000
Subject: [issue31865] html.unescape does not work as per documentation
In-Reply-To: <1508899606.23.0.213398074469.issue31865@psf.upfronthosting.co.za>
Message-ID: <1537859784.21.0.545547206417.issue31865@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. The relevant regex to is at https://github.com/python/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/html/__init__.py#L118 added with the commit 4a9ee26750aa8cb37b5072b2bb4dd328819febb4 . As far as I can see from the tests I can confirm this is a doc issue. Would you like to propose a PR for this?

The changes have to be done are at below places : 

* https://github.com/python/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/html/__init__.py#L125
* https://github.com/python/cpython/blob/master/Doc/library/html.rst

I am adding @ezio.melotti for a confirmation of the same.

Thanks

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31865>
_______________________________________

From report at bugs.python.org  Tue Sep 25 03:52:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 07:52:17 +0000
Subject: [issue34748] Incorrect HTML link in functools.partial
In-Reply-To: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>
Message-ID: <1537861937.31.0.545547206417.issue34748@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks @xitop for the report. Seems reasonable to me to link to https://docs.python.org/3.8/library/functools.html#partial-objects . Along similar lines I would suggest the below too where "partial objects" could be linked #partial-objects instead of #functools.partial . I will leave it for the reviewers though to decide on this.

"When func is a descriptor (such as a normal Python function, classmethod(), staticmethod(), abstractmethod() or another instance of partialmethod), calls to __get__ are delegated to the underlying descriptor, and an appropriate partial object returned as the result."


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34748>
_______________________________________

From report at bugs.python.org  Tue Sep 25 04:07:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 08:07:04 +0000
Subject: [issue34794] memory leak in TkApp:_createbytearray
In-Reply-To: <1537824612.19.0.545547206417.issue34794@psf.upfronthosting.co.za>
Message-ID: <1537862824.47.0.545547206417.issue34794@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8961
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34794>
_______________________________________

From report at bugs.python.org  Tue Sep 25 04:34:29 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 08:34:29 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537864469.14.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> The low bits are already un-improvable in the most important cases.

Maybe you misunderstood me. Suppose that there is a hash collision, say hash((3, 3)) == hash((-3, -3)) and you change the hashing algorithm to fix this collision. If that change does NOT affect the lower N bits, then you still have a collision hash((3, 3)) % 2**N == hash((-3, -3)) % 2**N. This is relevant because the dict implementation starts by taking the lower bits first. So ideally we want to avoid hash collisions in the lower bits too.

This may also be a reason to avoid the standard FNV multipliers: the 64-bit FNV multiplier was chosen with the full 64-bit hash range in mind. It was never meant to work well when truncated to some lower N bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 04:42:03 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 08:42:03 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537864923.96.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> When testing what, specifically?  And the standard 32-bit FNV multiplier, or the standard 64-bit FNV multiplier?

FNV-1a with the t ^= 2 * t mangling running my new testsuite on either PR 9471 or PR 9534 using the 64-bit FNV multiplier to produce 64-bit hashes. In other words, the code from PR 9534 but just changing the multiplier.

On the full 64-bit range, I got 2 collisions (where statistically 0 would be expected). When truncated to 32-bits, I got about 1700 collisions (where statistically about 15 would be expected).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 04:46:24 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 08:46:24 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537865184.74.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> j is even implies (j ^ -3) == -(j ^ 3)

This follows from what I posted before: if j is even, then j ^ 3 is odd, so we can apply the rule x ^ -2 = -x to x = j ^ 3:

(j ^ 3) ^ -2 = -(j ^ 3)

which implies

j ^ (3 ^ -2) = -(j ^ 3)

or equivalently

j ^ -3 = -(j ^ 3)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 04:51:51 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 08:51:51 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537865511.33.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> And one more:

        x = (x * mult) ^ t;

also appears to work equally well.

The order of operations does not really matter: you can write the loop as

x *= mult   # Appears only in FNV-1
x ^= t[0]
x *= mult
x ^= t[1]
x *= mult
x ^= t[2]
x *= mult
x ^= t[3]
x *= mult  # Appears only in FNV-1a

The initial multiplication is equivalent to changing the initial value and the final multiplication is just a permutation of the outputs. None of those should really affect the quality of the hash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 04:56:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 08:56:17 +0000
Subject: [issue31628] test_emails failure on FreeBSD
In-Reply-To: <1506669614.14.0.213398074469.issue31628@psf.upfronthosting.co.za>
Message-ID: <1537865777.36.0.545547206417.issue31628@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I just searched for the error and a very similar or in fact the same issue that fails with the same test was reported. It was closed as outdated since there were no errors on buildbots I hope. Adding it here the issue here that might be helpful in debugging. 

I would propose closing this and reopening the other issue which might be helpful since it has more context and Serhiy can still reproduce this on FreeBSD with 3.7. Thoughts on closing this?

Relevant issue : https://bugs.python.org/issue15750

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31628>
_______________________________________

From report at bugs.python.org  Tue Sep 25 05:46:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 09:46:06 +0000
Subject: [issue31636] test_locale failure on OpenBSD
In-Reply-To: <1506677973.45.0.213398074469.issue31636@psf.upfronthosting.co.za>
Message-ID: <1537868766.08.0.545547206417.issue31636@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Related issue on OpenBSD that proposes a patch catching the exception and skipping the test : https://bugs.python.org/issue25191 . I propose closing either of these as duplicate. It seems the PR 9178 was added to the issue by mistake and is not related to this issue.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31636>
_______________________________________

From report at bugs.python.org  Tue Sep 25 06:00:12 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 10:00:12 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537869612.35.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I want to leave low-order hash bits alone.  That's deliberate.

Since I didn't understand the rationale for this and since shifting << 1 also seems to work well, I edited PR 9471 to use DJBX33A with t ^= t << 1.

Since you insisted on adding 97531 at the end, I put that back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 06:06:20 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 10:06:20 +0000
Subject: [issue27903] Avoid ResourceWarnings from platform._dist_try_harder
In-Reply-To: <1472591978.31.0.987771003839.issue27903@psf.upfronthosting.co.za>
Message-ID: <1537869980.44.0.545547206417.issue27903@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report and patch Ville. CPython development now uses GitHub PR instead of patches. It seems usages of this function was removed in 8b94b41ab7b12f745dea744e8940631318816935 during removal of platform.linux_distribution. This essentially seems to be unused code on master which I hope can be removed. So this patch is effective only for 3.7 and 3.6. Would you like to make a PR to take this forward?

No usages on master except definition.

?  cpython git:(master) rg _dist_try_harder
Lib/platform.py
230:def _dist_try_harder(distname, version, id):


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27903>
_______________________________________

From report at bugs.python.org  Tue Sep 25 06:14:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 10:14:05 +0000
Subject: [issue34679] asyncio.add_signal_handler call fails if not on main
 thread
In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za>
Message-ID: <1537870445.8.0.545547206417.issue34679@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34679>
_______________________________________

From report at bugs.python.org  Tue Sep 25 06:21:42 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 10:21:42 +0000
Subject: [issue33940] datetime.strptime have no directive to convert date
 values with Era and Time Zone name
In-Reply-To: <1529672249.4.0.56676864532.issue33940@psf.upfronthosting.co.za>
Message-ID: <1537870902.97.0.545547206417.issue33940@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33940>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:06:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:06:30 +0000
Subject: [issue33940] datetime.strptime have no directive to convert date
 values with Era and Time Zone name
In-Reply-To: <1529672249.4.0.56676864532.issue33940@psf.upfronthosting.co.za>
Message-ID: <1537873590.61.0.545547206417.issue33940@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report Raghunath. Regarding timezone detection there is a limitation with %Z supporting only UTC, GMT and `time.tzname` which is not documented and it's an open issue tracked at issue22377 . Regarding a directive to determine Era I think it falls under a feature request and compile error is used for errors during compiling python interpreter itself. So I am changing this from compile error to enhancement.

# Support for GMT, UTC and error on PDT

$ ./python.exe
Python 3.8.0a0 (heads/master:f6c8007a29, Sep 25 2018, 12:30:43)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.strptime("2018-06-14 10:10:11 GMT", "%Y-%m-%d %H:%M:%S %Z")
datetime.datetime(2018, 6, 14, 10, 10, 11)
>>> datetime.datetime.strptime("2018-06-14 10:10:11 UTC", "%Y-%m-%d %H:%M:%S %Z")
datetime.datetime(2018, 6, 14, 10, 10, 11)
>>> datetime.datetime.strptime("2018-06-14 10:10:11 PDT", "%Y-%m-%d %H:%M:%S %Z")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/_strptime.py", line 568, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '2018-06-14 10:10:11 PDT' does not match format '%Y-%m-%d %H:%M:%S %Z'

Hope this helps!

Thanks

----------
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33940>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:10:52 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 25 Sep 2018 11:10:52 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1537873852.17.0.545547206417.issue34763@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/issue34763>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:11:57 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 25 Sep 2018 11:11:57 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537873917.05.0.545547206417.issue34320@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> Perhaps another good test of the same thing would be with a metaclass that returns an OrderedDict from __prepare__():


It is not relating to this issue: there are no conversion happened.
Should I add the test in this PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:12:37 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:12:37 +0000
Subject: [issue33797] json int encoding incorrect for dbus.Byte
In-Reply-To: <1528389161.29.0.592728768989.issue33797@psf.upfronthosting.co.za>
Message-ID: <1537873957.78.0.545547206417.issue33797@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33797>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:15:59 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 25 Sep 2018 11:15:59 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537874159.14.0.545547206417.issue34334@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Hi Vinay,

Thanks for the explanation!  I'm good with changing the PR.  I do have one question though.

You wrote -
> but I forgot that record.exc_text should also be zapped, as it should always reflect the contents of record.exc_info.

Based on the 'always reflect' statement, I'm wondering if there should be a change to `format()` to add an else to the record.exc_info check:
        if record.exc_info:
            if not record.exc_text:
                record.exc_text = self.formatException(record.exc_info)
        else:
            record.exc_text = None
  
Or if should just be in the `prepare()`.

I hope to have the new PR sometime today.  I think the cutoff for 3.7.1 was yesterday, but if you want to try to get this in to that release feel free to make changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:39:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:39:27 +0000
Subject: [issue33643] Mock functions with autospec STILL don't support
 assert_called_once, assert_called, assert_not_called
In-Reply-To: <1527233959.88.0.682650639539.issue33643@psf.upfronthosting.co.za>
Message-ID: <1537875567.8.0.545547206417.issue33643@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Can you please add a sample script that reproduces the error and the version of Python you are using? The fix was not merged to Python 3.5 as per msg278214 and I am little confused that this issue has Python 3.6 as affected version.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33643>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:42:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:42:06 +0000
Subject: [issue33442] Python 3 doc sidebar dosnt follow page scrolling like
 2.7 doc sidebar.
In-Reply-To: <1525698362.62.0.682650639539.issue33442@psf.upfronthosting.co.za>
Message-ID: <1537875726.32.0.545547206417.issue33442@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33442>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:42:25 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 25 Sep 2018 11:42:25 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537875745.46.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Working on getting this in now. Just in time, it seems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:53:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 11:53:31 +0000
Subject: [issue33797] json int encoding incorrect for dbus.Byte
In-Reply-To: <1528389161.29.0.592728768989.issue33797@psf.upfronthosting.co.za>
Message-ID: <1537876411.58.0.545547206417.issue33797@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/issue33797>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:55:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 25 Sep 2018 11:55:41 +0000
Subject: [issue34797] Convert heapq to the argument clinic
Message-ID: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Convert the accelerator module `_heapqmodule.c` to the argument clinic.

----------
components: Argument Clinic
messages: 326344
nosy: larry, pablogsal
priority: normal
severity: normal
status: open
title: Convert heapq to the argument clinic
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34797>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:55:49 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:55:49 +0000
Subject: [issue33442] Python 3 doc sidebar dosnt follow page scrolling like
 2.7 doc sidebar.
In-Reply-To: <1525698362.62.0.682650639539.issue33442@psf.upfronthosting.co.za>
Message-ID: <1537876549.1.0.545547206417.issue33442@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report Pete. The Python documentation theme is maintained at https://github.com/python/python-docs-theme/ and this particular issue is tracked at https://github.com/python/python-docs-theme/issues/20 . Related issues : issue34378, issue28044 . I am closing this as duplicate of issue28044. Feel free to open an issue at GitHub if it's different from the existing issue.

Thanks

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Make the sidebar in the documentation follow the section automatically

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33442>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:57:10 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 25 Sep 2018 11:57:10 +0000
Subject: [issue34797] Convert heapq to the argument clinic
In-Reply-To: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>
Message-ID: <1537876630.73.0.545547206417.issue34797@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8962
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34797>
_______________________________________

From report at bugs.python.org  Tue Sep 25 07:58:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:58:41 +0000
Subject: [issue33563] fileinput input's and Fileinput's bufsize=0 do not remit
 deprecationWarnings
In-Reply-To: <1526593521.99.0.682650639539.issue33563@psf.upfronthosting.co.za>
Message-ID: <1537876721.52.0.545547206417.issue33563@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33563>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:01:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 12:01:06 +0000
Subject: [issue27934] json float encoding incorrect for dbus.Double
In-Reply-To: <1472761223.9.0.580662580928.issue27934@psf.upfronthosting.co.za>
Message-ID: <1537876866.89.0.545547206417.issue27934@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This change broke a trick used for serializing Decimal to JSON without loss (see msg176158). It was good to break it in a new release, but I have doubts about breaking it in a bugfix release of 2.7.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27934>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:03:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 12:03:06 +0000
Subject: [issue34797] Convert heapq to the argument clinic
In-Reply-To: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>
Message-ID: <1537876986.39.0.545547206417.issue34797@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34797>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:05:16 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 25 Sep 2018 12:05:16 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537877116.71.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

This seems like it would need a "What's New" entry.

How does this work with IDLE re. new features being backported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:10:18 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 25 Sep 2018 12:10:18 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537877418.25.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 604e7b9931f9e7881a2941816e538f5f15930db8 by Tal Einat in branch 'master':
bpo-1529353: IDLE: squeeze large output in the shell (GH-7626)
https://github.com/python/cpython/commit/604e7b9931f9e7881a2941816e538f5f15930db8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:10:28 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 12:10:28 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537877428.52.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8963

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:10:35 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 12:10:35 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537877435.18.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8964

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:21:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 12:21:07 +0000
Subject: [issue32750] lib2to3 log_error method behavior is inconsitent with
 documentation
In-Reply-To: <1517596667.28.0.467229070634.issue32750@psf.upfronthosting.co.za>
Message-ID: <1537878067.45.0.545547206417.issue32750@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32750>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:34:43 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 12:34:43 +0000
Subject: [issue31962] test_importlib double free or corruption
In-Reply-To: <1510001792.72.0.213398074469.issue31962@psf.upfronthosting.co.za>
Message-ID: <1537878883.89.0.545547206417.issue31962@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31962>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:36:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 12:36:41 +0000
Subject: [issue31541] Mock called_with does not ensure self/cls argument is
 used
In-Reply-To: <1505986548.45.0.223796234627.issue31541@psf.upfronthosting.co.za>
Message-ID: <1537879001.36.0.545547206417.issue31541@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31541>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:38:50 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 12:38:50 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537879130.09.0.545547206417.issue1529353@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 321f28c5f4b7361fa1b6330697b28481b4565ec8 by Miss Islington (bot) in branch '3.7':
bpo-1529353: IDLE: squeeze large output in the shell (GH-7626)
https://github.com/python/cpython/commit/321f28c5f4b7361fa1b6330697b28481b4565ec8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:39:17 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 12:39:17 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537879157.38.0.545547206417.issue1529353@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0b3e1208033aa1eb5452afe9387f86f299ef24e5 by Miss Islington (bot) in branch '3.6':
bpo-1529353: IDLE: squeeze large output in the shell (GH-7626)
https://github.com/python/cpython/commit/0b3e1208033aa1eb5452afe9387f86f299ef24e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 08:50:04 2018
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 25 Sep 2018 12:50:04 +0000
Subject: [issue34683] Caret positioned wrong for SyntaxError reported by ast.c
In-Reply-To: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>
Message-ID: <1537879804.58.0.545547206417.issue34683@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

There's some context on the github PR but essentially it boiled down to:

- It would make it inconsistent with line offsets which are 1-indexed.
- Breaking change to a public C API (PyErr_SyntaxLocationObject)
- IDLE and other tools that catch syntax errors rely on it being 1-indexed and this would be a breaking change for them. As a quick example of that I found this vim plugin: https://github.com/vim-syntastic/syntastic/commit/6c91e8d802a77005d793d9cdd055c3da29f74a1b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34683>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:15:34 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 25 Sep 2018 13:15:34 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537881334.37.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Regarding t ^= t << 7: I tested PR 9471 with all shift values from 1 to 20. The new testsuite passed for all shifts from 1 to 13, except for 6. It failed for 6 and for 14 to 20. This indicates that smaller shift values are better (even when looking at 32-bit outputs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:33:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 13:33:22 +0000
Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23
 files
In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za>
Message-ID: <1537882402.24.0.545547206417.issue20186@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Convert heapq to the argument clinic

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20186>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:34:16 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 25 Sep 2018 13:34:16 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537882456.03.0.545547206417.issue34334@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I'm wondering if there should be a change to `format()` to add an else

There's no need; the field is initialised to None in the LogRecord constructor and then only set later if there is a traceback to be cached.

> I think the cutoff for 3.7.1 was yesterday, but if you want to try to get this in to that

There's no need to deviate from the normal process to get it into this release, from my point of view.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:35:48 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 25 Sep 2018 13:35:48 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537882548.36.0.545547206417.issue34334@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:43:16 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 25 Sep 2018 13:43:16 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1537882996.64.0.545547206417.issue34736@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +8965
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:55:07 2018
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Tue, 25 Sep 2018 13:55:07 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537883706.98.0.545547206417.issue2771@psf.upfronthosting.co.za>


Change by Ernest W. Durbin III <ernest at python.org>:


----------
nosy: +EWDurbin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Tue Sep 25 09:55:24 2018
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Tue, 25 Sep 2018 13:55:24 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537883724.01.0.545547206417.issue2771@psf.upfronthosting.co.za>


Ernest W. Durbin III <ernest at python.org> added the comment:

test comment

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Tue Sep 25 10:15:08 2018
From: report at bugs.python.org (William Pickard)
Date: Tue, 25 Sep 2018 14:15:08 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1537884908.51.0.545547206417.issue25095@psf.upfronthosting.co.za>


Change by William Pickard <lollol222gg at gmail.com>:


----------
pull_requests: +8966

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Tue Sep 25 10:24:46 2018
From: report at bugs.python.org (David Talkin)
Date: Tue, 25 Sep 2018 14:24:46 +0000
Subject: [issue34794] memory leak in TkApp:_createbytearray
In-Reply-To: <1537858524.51.0.545547206417.issue34794@psf.upfronthosting.co.za>
Message-ID: <CAJ3W24dtgTXr-ObyjPn0aPdS7PA_Q6xgrO-CfTnAy5iH1kPs3Q@mail.gmail.com>


David Talkin <dtalkin at gmail.com> added the comment:

Attached please find a Python script that demonstrates the bug.

David

On Tue, Sep 25, 2018 at 2:55 AM Karthikeyan Singaravelan <
report at bugs.python.org> wrote:

>
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
>
> Thanks for the report David. Feel free to attach reproducible script if
> any that might trigger this. I am adding Serhiy who might have a better
> understanding of this. Relevant issue where _createbytearray was added :
> issue21580 .
>
> ----------
> nosy: +serhiy.storchaka, xtreak
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34794>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file47821/leak_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34794>
_______________________________________
-------------- next part --------------
#!/usr/bin/python

#
#
# Copyright 2018 David Talkin.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

"""This demonstrates that Tkinter.PhotoImage leaks memory with each data update.

To see the leak, run this as a main program and watch memory usage on
the system monitor.  The leak occurs in LeakDemo.ShowImage.

"""
import sys
import math
import Tkinter as tk
import numpy as np

__author__ = 'dtalkin at gmail.com (David Talkin)'


class LeakDemo(object):
    """Demonstrates the memory leak due to calls to TkApp._createbytearray.
    """
    def __init__(self, height=600, width=1000):
        self.height = height
        self.width = width
        self.root = tk.Tk()
        self.frame = tk.Frame(self.root)
        self.frame.pack()
        self.canvas = tk.Canvas(self.frame, height=self.height,
                                width=self.width)
        self.canvas.pack(side=tk.TOP, expand=tk.YES, fill=tk.BOTH)
        self.image = None
        self.photo = None
        self.phase = 0.0

    def MakeSignals(self):
        """Create signals that will modulate the red, blue and green
        intensities in the image.  Return them as a three-element list of
        numpy arrays.
        """
        freqs = [5.0, 7.0, 9.0]
        sigs = []
        amp = 128.0
        for freq in freqs:
            arg = math.pi * 2.0 * freq / self.width
            ara = np.zeros(self.width, dtype=np.float32)
            for i in range(self.width):
                ara[i] = amp * math.sin(self.phase + (arg * i))
            sigs.append(ara)
        self.phase += math.pi / 100.0
        return sigs

    def CreateImage(self, sigs):
        """Accept a list of three arrays that represent the red, blue and
        green intensities across the canvas.  Return a PPN-format image to be
        displayed.
        """
        odata = np.array(sigs).transpose().flatten()
        amax = 128
        if len(odata) > self.width * 3:
            odata = odata[:self.width * 3]
        head = 'P6\n%d %d\n%d\n' % (len(odata)/3, self.height, amax)
        bdata = head + (np.array([min(amax, max(0, (128 + v) / 2))
                                  for v in odata],
                                 dtype=np.uint8).tostring() * (self.height))
        return bdata

    def ShowImage(self, image_data):
        """The leak happens here when PhotoImage is instantiated an after each
        call to configure.
        """
        if not self.photo:
            self.photo = tk.PhotoImage(master=self.root, data=image_data,
                                       format='PPM')
            self.image = self.canvas.create_image((1 + self.width) / 2,
                                                  (1 + self.height) / 2,
                                                  image=self.photo)
        else:
            self.photo.configure(data=image_data)

    def RunDemo(self):
        sigs = self.MakeSignals()
        image = self.CreateImage(sigs)
        self.ShowImage(image)
        self.root.after(33, self.RunDemo)  # About 30 frames/second.


def Main(unused_args):
    demo = LeakDemo()
    demo.RunDemo()
    tk.mainloop()


if __name__ == '__main__':
    Main(sys.argv)

From report at bugs.python.org  Tue Sep 25 10:26:59 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 25 Sep 2018 14:26:59 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537885619.21.0.545547206417.issue34320@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

There is a conversion.  See builtin___build_class__ in Python/bltinmodule.c (and the LOAD_BUILD_CLASS target in Python/ceval.c).  Specifically, the metaclass (e.g. the builtin type) is instantiated using the namespace from the class definition.  The metaclass copies that namespace into a new dict.  So the following two bits of code are equivalent:

  # using a class definition

  ns = OrderedDict()

  class Meta(type):
      def __prepare__(*args, **kwargs):
          return ns

  class Spam(metaclass=Meta):
      a = 1
      b = 2
      ns.move_to_end('a')

  # using the metaclass directly

  ns = OrderedDict()
  ns['a'] = 1
  ns['b'] = 2
  ns.move_to_end('a')
  Spam = Meta('Spam', (object,), ns)

In both cases Spam.__dict__ will be a proxy for a new dict copied from ns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Tue Sep 25 10:44:52 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 25 Sep 2018 14:44:52 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537886692.64.0.545547206417.issue34320@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Conversion is happens when type() (or metaclass()) is called.
And I added test for it already.
https://github.com/python/cpython/pull/8624/files#diff-7ba610fbe5686a1d67c5504312be4817R1977

Why regression test for this bugfix need to use __prepare__?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Tue Sep 25 10:45:41 2018
From: report at bugs.python.org (Nicolas Hug)
Date: Tue, 25 Sep 2018 14:45:41 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
Message-ID: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>


New submission from Nicolas Hug <niourf at gmail.com>:

Dict representations that exceed the line width are printed with one line per key-value pair, ignoring the compact=True parameter:

>>> pprint.pprint({i: 0 for i in range(15)}, compact=True)
{0: 0,
 1: 0,
 2: 0,
 3: 0,
 4: 0,
 5: 0,
 6: 0,
 7: 0,
 8: 0,
 9: 0,
 10: 0,
 11: 0,
 12: 0,
 13: 0,
 14: 0}

Expected behavior:

>>> pprint.pprint({i: 0 for i in range(15)}, compact=True)
{0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0, 8: 0, 9: 0, 10: 0, 11: 0,
 12: 0, 13: 0, 14: 0}

Note that lists are correctly compacted, and that dicts that don't exceed line width are printed on a single line, regardless on the compact parameter.

I could try to work on that if needed?

----------
messages: 326358
nosy: Nicolas Hug
priority: normal
severity: normal
status: open
title: pprint ignores the compact parameter for dicts
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 10:54:10 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 14:54:10 +0000
Subject: [issue27526] test_venv.TestEnsurePip fails mysteriously when /tmp is
 too small
In-Reply-To: <1468634945.4.0.415897452337.issue27526@psf.upfronthosting.co.za>
Message-ID: <1537887250.8.0.545547206417.issue27526@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27526>
_______________________________________

From report at bugs.python.org  Tue Sep 25 10:57:42 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 14:57:42 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537887462.62.0.545547206417.issue32557@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c8c0249c9e8f61ab7670119a5a5278354df27bbb by Miss Islington (bot) (Joe Pamer) in branch 'master':
bpo-32557: allow shutil.disk_usage to take a file path on Windows also (GH-9372)
https://github.com/python/cpython/commit/c8c0249c9e8f61ab7670119a5a5278354df27bbb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:06:20 2018
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 25 Sep 2018 15:06:20 +0000
Subject: [issue34799] When function in tracing returns None, tracing continues.
Message-ID: <1537887980.13.0.545547206417.issue34799@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

https://docs.python.org/3/library/sys.html#sys.settrace explicitly states:

The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope.

Yet, it seems this happens only on the return of a 'call'. If None is returned in a 'line' event, apparently the previous tracing function is reused (but if a new function is returned, the new function is used properly).

I'm attaching a test case which shows the issue. I've tested on 2.7, 3.6 and 3.7 and this issue is present on all.

If I set frame.f_trace = None before returning it seems to work though (so, I think that either this behavior should be fixed or the docs should be updated to reflect that).

----------
files: issue_in_tracing_func.py
messages: 326360
nosy: fabioz
priority: normal
severity: normal
status: open
title: When function in tracing returns None, tracing continues.
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47822/issue_in_tracing_func.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34799>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:25:35 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Sep 2018 15:25:35 +0000
Subject: [issue32557] allow shutil.disk_usage to take a file path on Windows
 also
In-Reply-To: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>
Message-ID: <1537889135.57.0.545547206417.issue32557@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:27:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Sep 2018 15:27:21 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1537889241.26.0.545547206417.issue34687@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 6ea29c5e90dde6c240bd8e0815614b52ac307ea1 by Yury Selivanov (Victor Stinner) in branch 'master':
bpo-34687: Make asynico use ProactorEventLoop by default (GH-9538)
https://github.com/python/cpython/commit/6ea29c5e90dde6c240bd8e0815614b52ac307ea1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:30:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Sep 2018 15:30:21 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537889421.37.0.545547206417.issue33937@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 46f40be8b907854deb81c6132b7cb038e9e5202a by Victor Stinner in branch 'master':
bpo-33937: Catch ENOMEM error in test_socket (#9557)
https://github.com/python/cpython/commit/46f40be8b907854deb81c6132b7cb038e9e5202a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:30:32 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 15:30:32 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537889432.84.0.545547206417.issue33937@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8967

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:30:39 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 15:30:39 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537889439.27.0.545547206417.issue33937@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8968

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:31:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Sep 2018 15:31:18 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1537889478.26.0.545547206417.issue34687@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thank you for the review Yury ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:36:08 2018
From: report at bugs.python.org (silane)
Date: Tue, 25 Sep 2018 15:36:08 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
Message-ID: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>


New submission from silane <michiwatsuki at gmail.com>:

The document of the email.policy.Policy says max_line_length=0 or None indicates that no line wrapping should be done at all.
But email.contentmanager doesn't handle this properly and raises error when calling set_content() with bytes or non-ascii str.


---Code to reproduce the bug---

from email.message import EmailMessage
from email.policy import default
msg=EmailMessage(default.clone(max_line_length=None)) # or max_line_length=0

msg.set_content('?') # raise error
# or
msg.set_content(b'a',maintype='application',subtype='octet-stream') # raise error

---


This bug is caused by contentmanager._encode_text() and contentmanager.set_bytes_content().
These don't assume policy.max_line_length to be None or 0.

I tested this on python3.7 3.6 3.5, but probably 3.4 has the same bug.

----------
components: email
messages: 326364
nosy: barry, r.david.murray, silane
priority: normal
severity: normal
status: open
title: email.contentmanager raises error when policy.max_line_length==None or 0
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:38:08 2018
From: report at bugs.python.org (silane)
Date: Tue, 25 Sep 2018 15:38:08 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
In-Reply-To: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>
Message-ID: <1537889888.84.0.545547206417.issue34800@psf.upfronthosting.co.za>


Change by silane <michiwatsuki at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:46:22 2018
From: report at bugs.python.org (Eric Snow)
Date: Tue, 25 Sep 2018 15:46:22 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537890382.67.0.545547206417.issue34320@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Conversion is happens when type() (or metaclass()) is called.

Right.  So an extra test to cover the __prepare__ case is somewhat redundant.  I only suggested it because type() is called implicitly and the test would make the conversion case clear.  However, it was only a suggestion for you to consider, not something I considered necessary. :)  I'm fine with not adding a test that uses __prepare__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:49:37 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 15:49:37 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537890577.0.0.545547206417.issue33937@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ef1173ab141ba5387598f8859ba96f98d20d743e by Miss Islington (bot) in branch '3.7':
bpo-33937: Catch ENOMEM error in test_socket (GH-9557)
https://github.com/python/cpython/commit/ef1173ab141ba5387598f8859ba96f98d20d743e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 11:56:27 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 15:56:27 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537890987.08.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:00:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:00:19 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537891219.44.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:00:55 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:00:55 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537891255.43.0.545547206417.issue33937@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 857b0028c0832c3159927489bc55f802bc5146cb by Miss Islington (bot) in branch '3.6':
bpo-33937: Catch ENOMEM error in test_socket (GH-9557)
https://github.com/python/cpython/commit/857b0028c0832c3159927489bc55f802bc5146cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:09:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:09:00 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537891740.54.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset dac712d51667227ce3862fc61be6a8094b1066fa by Terry Jan Reedy in branch 'master':
bpo-1529353: IDLE: Squeezer What's New for 3.6.7 (#9567)
https://github.com/python/cpython/commit/dac712d51667227ce3862fc61be6a8094b1066fa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:09:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:09:09 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537891749.05.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8971

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:09:18 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:09:18 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537891758.86.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:09:55 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:09:55 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537891795.38.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ea718d377db3941ecfc86288a3465fce653cc682 by Terry Jan Reedy in branch 'master':
bpo-1529353: IDLE - Squeezer What's New for 3.7.1 (#9568)
https://github.com/python/cpython/commit/ea718d377db3941ecfc86288a3465fce653cc682


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:10:05 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:10:05 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537891805.89.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:15:07 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:15:07 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537892107.54.0.545547206417.issue1529353@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 98c8236cc75529407e305f26de95d9e72a72a0eb by Miss Islington (bot) in branch '3.6':
bpo-1529353: IDLE: Squeezer What's New for 3.6.7 (GH-9567)
https://github.com/python/cpython/commit/98c8236cc75529407e305f26de95d9e72a72a0eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:15:18 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:15:18 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537892118.08.0.545547206417.issue1529353@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 92ad2612bef198f2e3f8f09bf552189e27afcc4e by Miss Islington (bot) in branch '3.7':
bpo-1529353: IDLE: Squeezer What's New for 3.6.7 (GH-9567)
https://github.com/python/cpython/commit/92ad2612bef198f2e3f8f09bf552189e27afcc4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:18:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 16:18:03 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537892283.08.0.545547206417.issue1529353@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3637e68d7c92eda0b80e6ab3f58610e1cfb4f1d8 by Miss Islington (bot) in branch '3.7':
bpo-1529353: IDLE - Squeezer What's New for 3.7.1 (GH-9568)
https://github.com/python/cpython/commit/3637e68d7c92eda0b80e6ab3f58610e1cfb4f1d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:20:32 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:20:32 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537892432.49.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8974

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:29:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:29:00 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537892940.05.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8975
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:39:35 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 16:39:35 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537893575.63.0.545547206417.issue34798@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:44:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:44:21 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537893861.41.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

See my 3.6/3.7 patches for how I now handle new-in-maintenance-release user-visible features in What's New.  Note that there are similar entries for Python at the bottom of the file.

If I were not rushing, I would have mentioned user colors in text view.  But that is minor and I will add one entry for colors and font sizes in both text and help views when done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:45:34 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 16:45:34 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537893934.22.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset fdcb5ae25c0b5c82a32955617d253810ef110cac by Terry Jan Reedy in branch 'master':
bpo-1529353: IDLE - Squeezer What's New for 3.8 (#9572)
https://github.com/python/cpython/commit/fdcb5ae25c0b5c82a32955617d253810ef110cac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Sep 25 12:54:28 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Sep 2018 16:54:28 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537894468.79.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

> Suppose that there is a hash collision, say hash((3, 3)) ==
> hash((-3, -3)) and you change the hashing algorithm to fix
> this collision.

There are _two_ hash functions at play in that collision:  the tuple hash function, and the integer hash function.  Regardless of whether the _tuple_ hash function does

    t ^= t << shift;
or
    t += t >> shift;

or anything else involving just `t`, that only directly affects the result of the _int_ hash function.  Whose low order bits cannot be improved in general - they're already optimally spread out in the most important cases.

> If that change does NOT affect the lower N bits,
> then you still have a collision hash((3, 3)) % 2**N ==
> hash((-3, -3)) % 2**N. This is relevant because the dict
> implementation starts by taking the lower bits first. So
> ideally we want to avoid hash collisions in the lower
> bits too.

Which the int hash on its own already does a superb job of doing in the most important cases.  If you feel you just have to mess with low-order bits, do it instead on the _tuple_ hash intermediate results, not on its inputs.  Like

    x += x >> 16;

after t is folded in to x.  It's x you care about directly, not t.  Damaging desirable properties in t to _indirectly_ gain something in x is too clever by half.

Mucking with t to avoid the nested-tuple catastrophes is worth it, but I prefer to do that with as little damage to t's desirable properties as reasonably possible.

> This may also be a reason to avoid the standard FNV
> multipliers: the 64-bit FNV multiplier was chosen with
> the full 64-bit hash range in mind. It was never meant
> to work well when truncated to some lower N bits.

Do you believe any other multiplier would work better toward that end?  For any odd multiplier M, the last k bits of i*M are determined solely by the last k bits of i, and

    [(last k bits of i*M) for i in range(anything, anything + 2**k)]

is a permutation of range(2**k).  The high order bits of i have nothing to do with it, and any odd multiplier permutes the lower k bits over any stretch of 2**k consecutive multiplicands.

Extracting low-order bits is intended to be done by "xor folding" in FNV, and I _expect_ the same would be prudent for any other multiplier:

https://tools.ietf.org/html/draft-eastlake-fnv-15#page-7

The dict and set lookup functions already do something stronger than xor folding to bring high bits into play, but do so incrementally as the probe sequence unfolds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:00:56 2018
From: report at bugs.python.org (Perette Barella)
Date: Tue, 25 Sep 2018 17:00:56 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1537894856.54.0.545547206417.issue12806@psf.upfronthosting.co.za>


Perette Barella <perette at barella.org> added the comment:

I would find this a useful feature.

----------
nosy: +perette

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:23:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Sep 2018 17:23:40 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537896220.52.0.545547206417.issue33937@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The issue should now be fixed. Reopen it if it is not the case.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:24:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Sep 2018 17:24:01 +0000
Subject: [issue33937] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout()
 failed on Travis CI with: [Errno 12] Cannot allocate memory
In-Reply-To: <1529652776.13.0.56676864532.issue33937@psf.upfronthosting.co.za>
Message-ID: <1537896241.95.0.545547206417.issue33937@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks for the review Pablo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33937>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:38:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 17:38:30 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537897110.45.0.545547206417.issue34798@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report Nicolas. I looked into the code and it seems that pprint for a dictionary now doesn't really take compact into account. List, sets, tuple and dequeue use _format_items [0] that honors value of compact but dictionary formatting uses _format_dict_items [1] that doesn't without using compact value. Unfortunately, I don't have any links over why dictionary doesn't take compact into account. I would suggest python-ideas [3] to get more feedback about formatting and implementation along with backwards compatibility so that you can proceed further. Your suggestion seems reasonable to me but I don't know if some program is using compact=True for a dictionary without knowing the internals in mind that might break for them. I would wait for others thoughts on this and I think this can be done only on 3.8 and not 3.7 which is in bug fix mode.

[0] https://github.com/python/cpython/blob/fdcb5ae25c0b5c82a32955617d253810ef110cac/Lib/pprint.py#L350
[1] https://github.com/python/cpython/blob/fdcb5ae25c0b5c82a32955617d253810ef110cac/Lib/pprint.py#L333
[2] https://mail.python.org/pipermail/python-ideas/

Hope this helps!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:41:32 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 17:41:32 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537897292.34.0.545547206417.issue34162@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 22ef31d0b4b497eda5e356528c3e1d29584d6757 by Terry Jan Reedy in branch 'master':
bpo-34162: idlelib/NEWS.txt entry for squeezer (GH-9573)
https://github.com/python/cpython/commit/22ef31d0b4b497eda5e356528c3e1d29584d6757


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:41:46 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 17:41:46 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537897306.03.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8976

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:41:49 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 17:41:49 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537897309.8.0.545547206417.issue34162@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8977

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Tue Sep 25 13:45:20 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 17:45:20 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
In-Reply-To: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>
Message-ID: <1537897520.23.0.545547206417.issue34800@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:02:10 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 18:02:10 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537898530.76.0.545547206417.issue34162@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b2ae5502981ae7e8fc080f5155060235696afe22 by Miss Islington (bot) in branch '3.7':
bpo-34162: idlelib/NEWS.txt entry for squeezer (GH-9573)
https://github.com/python/cpython/commit/b2ae5502981ae7e8fc080f5155060235696afe22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:05:24 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 25 Sep 2018 18:05:24 +0000
Subject: [issue34801] codecs.getreader() splits lines containing control
 characters
Message-ID: <1537898724.68.0.545547206417.issue34801@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

This seems to be a bug in codecs.getreader().  io.TextIOWrapper(fp, encoding) works correctly.

----------
files: codecs_bug.py
messages: 326382
nosy: nascheme
priority: low
severity: normal
status: open
title: codecs.getreader() splits lines containing control characters
type: behavior
Added file: https://bugs.python.org/file47823/codecs_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34801>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:06:59 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 18:06:59 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1537898819.44.0.545547206417.issue34162@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dc335ae77dfc1fb6a500eb1cd0baf23fcda45434 by Miss Islington (bot) in branch '3.6':
bpo-34162: idlelib/NEWS.txt entry for squeezer (GH-9573)
https://github.com/python/cpython/commit/dc335ae77dfc1fb6a500eb1cd0baf23fcda45434


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:14:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 18:14:18 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
In-Reply-To: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>
Message-ID: <1537899258.85.0.545547206417.issue34800@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks silane for the report and script. The case where max_line_length=0 causing ValueError was introduced with b938c8c25316b69f1d5df2c7880a9f6b87e7c2fa and the code at [0] has some comments regarding the minimum value to be 4 characters. There was another case where policy can have max_line_length=0 but it's with respect to folding issue33524. Maybe this behavior can be documented better for set_content method with respect to the minimum value ? 

[0] https://github.com/tirkarthi/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/email/quoprimime.py#L171


"""
    Each line will be wrapped at, at most, maxlinelen characters before the
    eol string (maxlinelen defaults to 76 characters, the maximum value
    permitted by RFC 2045).  Long lines will have the 'soft line break'
    quoted-printable character "=" appended to them, so the decoded text will
    be identical to the original text.

    The minimum maxlinelen is 4 to have room for a quoted character ("=XX")
    followed by a soft line break.  Smaller values will generate a
    ValueError.
"""

Hope this helps!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:20:56 2018
From: report at bugs.python.org (Nicolas Hug)
Date: Tue, 25 Sep 2018 18:20:56 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537899656.23.0.545547206417.issue34798@psf.upfronthosting.co.za>


Change by Nicolas Hug <niourf at gmail.com>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:27:54 2018
From: report at bugs.python.org (Nicolas Hug)
Date: Tue, 25 Sep 2018 18:27:54 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537900074.91.0.545547206417.issue34798@psf.upfronthosting.co.za>


Nicolas Hug <niourf at gmail.com> added the comment:

Thank you for the feedback!

I'll try the python-ideas mail list. I posted a message on Python-list [1] a few weeks ago but it didn't get much traction.

I'm not sure about what the final solution could be (if any), but I had to hack pprint myself [2] for the scikit-learn project, and what I did was simply copy pasting _format_items into _format_dict_items, with some minimal changes.


[1] https://mail.python.org/pipermail/python-list/2018-September/737082.html
[2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:29:21 2018
From: report at bugs.python.org (Nicolas Hug)
Date: Tue, 25 Sep 2018 18:29:21 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537900161.04.0.545547206417.issue34798@psf.upfronthosting.co.za>


Nicolas Hug <niourf at gmail.com> added the comment:

Sorry:

[2] https://github.com/scikit-learn/scikit-learn/pull/11705/files#diff-f83e8d9362766b385472f1be7fed9482R96

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:39:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 18:39:45 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537900785.61.0.545547206417.issue34798@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is on purpose. See issue19132.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:40:43 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 25 Sep 2018 18:40:43 +0000
Subject: [issue34789] doc xml.sax.make_parser expects a list not just any
 sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537900843.64.0.545547206417.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
pull_requests: +8978

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:41:36 2018
From: report at bugs.python.org (Yongnan Wu)
Date: Tue, 25 Sep 2018 18:41:36 +0000
Subject: [issue34766] BaseProxy cache should be cleaned when Manager client is
 reconnected
Message-ID: <1537900896.87.0.545547206417.issue34766@psf.upfronthosting.co.za>


New submission from Yongnan Wu <wynfred at yeah.net>:

BaseProxy class in multiprocessing has an internal cache _address_to_local that is only cleaned when Manager server gets shutdown. If a Manager is used as client, the cache should to be cleaned when a new connection is created by Manager.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34766>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:47:37 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 18:47:37 +0000
Subject: [issue32750] lib2to3 log_error method behavior is inconsitent with
 documentation
In-Reply-To: <1517596667.28.0.467229070634.issue32750@psf.upfronthosting.co.za>
Message-ID: <1537901257.22.0.545547206417.issue32750@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Nick for the details. I think 2to3 uses StdoutRefactoringTool [1] which inherits from RefactoringTool in the chain and implements log_error [2] that logs the error. 

StdoutRefactoringTool inherits from MultiprocessRefactoringTool [3] which in turn inherits from RefactoringTool [4] that raises the exception on log_error. But StdoutRefactoringTool re-implemented it to log and not to raise. I couldn't see any errors on scripts that have parsing errors. I think the docstring is right from the context of StdoutRefactoringTool but they were essentially present in RefactoringTool adding to the confusion I hope. Suggestions welcome on improving this. Feel free to correct me if I am misunderstanding the issue.

Example I have used to verify : 

$ cat ../backups/bpo32750.py # parse error file should be logged and skipped
foo +- # Invalid file
$ cat ../backups/bpo32750.py # valid file
print "hello"
$ 2to3 ../backups/bpo32750.py ../backups/bpo32750_valid.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Can't parse ../backups/bpo32750.py: ParseError: bad input: type=4, value='\n', context=('', (1, 6))
RefactoringTool: Refactored ../backups/bpo32750_valid.py
--- ../backups/bpo32750_valid.py	(original)
+++ ../backups/bpo32750_valid.py	(refactored)
@@ -1 +1 @@
-print "hello"
+print("hello")
RefactoringTool: Files that need to be modified:
RefactoringTool: ../backups/bpo32750_valid.py
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse ../backups/bpo32750.py: ParseError: bad input: type=4, value='\n', context=('', (1, 6))

Hope this helps.

Thanks again

[1] StdoutRefactoringTool - https://github.com/tirkarthi/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/lib2to3/main.py#L245

[2] StdoutRefactoringTool.log_error - https://github.com/tirkarthi/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/lib2to3/main.py#L65

[3] MultiprocessRefactoringTool - https://github.com/tirkarthi/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/lib2to3/refactor.py#L676

[4] RefactoringTool - https://github.com/tirkarthi/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/lib2to3/refactor.py#L155

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32750>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:51:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Sep 2018 18:51:25 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537901484.99.0.545547206417.issue34790@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 996859a90df51f84eab47351702cb59c6db4428a by Yury Selivanov in branch 'master':
bpo-34790: [docs] Passing coroutines to asyncio.wait() can be confusing. (GH-9543)
https://github.com/python/cpython/commit/996859a90df51f84eab47351702cb59c6db4428a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:51:35 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 18:51:35 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537901495.02.0.545547206417.issue34798@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks much Serhiy for the details!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:51:36 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 18:51:36 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537901496.86.0.545547206417.issue34790@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8979

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:53:46 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Sep 2018 18:53:46 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537901626.74.0.545547206417.issue34790@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/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:54:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Sep 2018 18:54:37 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537901677.12.0.545547206417.issue34790@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Actually, since Andrew also agrees that we need to deprecate passing coroutines to wait(), I'll keep this issue open until we add an actual DeprecationWarning in 3.8.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:55:51 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 25 Sep 2018 18:55:51 +0000
Subject: [issue34789] Make xml.sax.make_parser accept iterables
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537901751.56.0.545547206417.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
components: +Library (Lib) -Documentation
title: doc xml.sax.make_parser expects a list not just any sequence -> Make xml.sax.make_parser accept iterables

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:56:52 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 25 Sep 2018 18:56:52 +0000
Subject: [issue34789] Make xml.sax.make_parser accept iterables
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537901812.25.0.545547206417.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
components: +XML -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34789>
_______________________________________

From report at bugs.python.org  Tue Sep 25 14:57:54 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 18:57:54 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537901874.49.0.545547206417.issue34790@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3cc9557d9f03086fa3b0ea166f8506087e6950e3 by Miss Islington (bot) in branch '3.7':
bpo-34790: [docs] Passing coroutines to asyncio.wait() can be confusing. (GH-9543)
https://github.com/python/cpython/commit/3cc9557d9f03086fa3b0ea166f8506087e6950e3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:01:11 2018
From: report at bugs.python.org (Nicolas Hug)
Date: Tue, 25 Sep 2018 19:01:11 +0000
Subject: [issue34798] pprint ignores the compact parameter for dicts
In-Reply-To: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>
Message-ID: <1537902071.38.0.545547206417.issue34798@psf.upfronthosting.co.za>


Nicolas Hug <niourf at gmail.com> added the comment:

Thanks for the link,

But I don't see any justification for this behavior*? Why should lists be compacted but not dicts (even when explicitly asked)?

At the very least it should be made clear in the documentation that dicts are not compacted.

* Maybe there's more content in the patch reviews but I am unable to see them

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34798>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:05:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Sep 2018 19:05:23 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537902323.32.0.545547206417.issue34790@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

PendingDeprecationWarning

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:15:15 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Sep 2018 19:15:15 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537902915.51.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

>> j is even implies (j ^ -3) == -(j ^ 3)

> This follows from what I posted before: if j is even, then
> j ^ 3 is odd, so we can apply the rule x ^ -2 = -x to x = j ^ 3
> ...

Thanks!  That helps a lot.  I had a blind spot there.  This kind of thing would have been best spelled out at the start:  it's not just that -2 has some bad effects, but that there's a whole universe of potentially damaging identities:

j odd  implies   j      = -(j ^ -2)
j even implies  (j ^ 1) = -(j ^ -1)
j odd  implies  (j ^ 2) = -(j ^ -4)
j even implies  (j ^ 3) = -(j ^ -3)
j odd  implies  (j ^ 4) = -(j ^ -6)
j even implies  (j ^ 5) = -(j ^ -5)
j odd  implies  (j ^ 6) = -(j ^ -8)
j even implies  (j ^ 7) = -(j ^ -7)
j odd  implies  (j ^ 8) = -(j ^ -10)
j even implies  (j ^ 9) = -(j ^ -9)
j odd  implies  (j ^ 10) = -(j ^ -12)
j even implies  (j ^ 11) = -(j ^ -11)
j odd  implies  (j ^ 12) = -(j ^ -14)
j even implies  (j ^ 13) = -(j ^ -13)
j odd  implies  (j ^ 14) = -(j ^ -16)
j even implies  (j ^ 15) = -(j ^ -15)
...

Every integer pairs up with another of the opposite sign in one of these - but with only one.  That goes a long way toward explaining why collisions are frequent when mixing signs on ints of similar magnitude, but also why they don't "pile up" catastrophically.

But it also suggests a way to construct cases that _are_ catastrophic.  For example:

>>> len(set(map(hash, product([-3, 3], repeat=20))))
1024

Ouch!

>>> c = Counter(map(hash, product([-3, 3], repeat=20)))
>>> len(c)
1024
>>> max(c.values())
1024
>>> min(c.values())
1024

So each of the 1024 hash codes showed up 1024 times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:15:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 19:15:47 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1537902947.93.0.545547206417.issue34790@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

AFAIK there is no a plan for 4.0. But seems many core developers (including me) think that changing the major number should reflect some major changes like removing GIL. And Guido preferred 3.10 after 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:15:51 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 25 Sep 2018 19:15:51 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537902951.88.0.545547206417.issue5950@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 5a5ce064b3baadcb79605c5a42ee3d0aee57cdfc by Barry Warsaw (Zackery Spytz) in branch 'master':
bpo-5950: Support reading zips with comments in zipimport (#9548)
https://github.com/python/cpython/commit/5a5ce064b3baadcb79605c5a42ee3d0aee57cdfc


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:16:49 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 25 Sep 2018 19:16:49 +0000
Subject: [issue5950] Make zipimport work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1537903009.65.0.545547206417.issue5950@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
components: +Library (Lib) -Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5950>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:23:53 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Sep 2018 19:23:53 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
In-Reply-To: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>
Message-ID: <1537903433.54.0.545547206417.issue34800@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

An unlimited line length would certainly satisfy the required minimum.  As silane indicates, if max_line_length is 0 or None, the serializer is not supposed to wrap lines.  (In fact one would like to have the option to control this separately for the headers and the body, but currently the policy does not have knobs for that.)

So, this is a bug.

----------
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 15:33:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 19:33:43 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1537904023.61.0.545547206417.issue10694@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This change significantly increased the probability of false positive detection in is_zipfile(). It was around 1/2**32, now it is around 1/2**16. It looks small, but not enough small if you test hundreds of thousands files. See issue28494.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:05:08 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Sep 2018 20:05:08 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537905908.91.0.545547206417.issue34781@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I couldn't reproduce with Python 3.6.5 on Ubuntu 18.04.

Does it happen if you reduce logging?  Or if you replace f() with:

def f(i):
    os.write(1, "{}\n".format(i).encode())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:08:02 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Sep 2018 20:08:02 +0000
Subject: [issue30964] Mention ensurepip in package installation docs
In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za>
Message-ID: <1537906082.15.0.545547206417.issue30964@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30964>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:11:51 2018
From: report at bugs.python.org (silane)
Date: Tue, 25 Sep 2018 20:11:51 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
In-Reply-To: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>
Message-ID: <1537906311.94.0.545547206417.issue34800@psf.upfronthosting.co.za>


Change by silane <michiwatsuki at gmail.com>:


----------
keywords: +patch
pull_requests: +8980
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:24:05 2018
From: report at bugs.python.org (silane)
Date: Tue, 25 Sep 2018 20:24:05 +0000
Subject: [issue34800] email.contentmanager raises error when
 policy.max_line_length==None or 0
In-Reply-To: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>
Message-ID: <1537907045.91.0.545547206417.issue34800@psf.upfronthosting.co.za>


silane <michiwatsuki at gmail.com> added the comment:

I've made a pull request.
Please look at it.
And this is my first pull request, so please let me know if something wrong.

https://github.com/python/cpython/pull/9578

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34800>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:32:06 2018
From: report at bugs.python.org (Gefn)
Date: Tue, 25 Sep 2018 20:32:06 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
Message-ID: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>


New submission from Gefn <insomgla at gmail.com>:

The documentation states that "This method is different from inspect.iscoroutine() because it returns True for generator-based coroutines decorated with @coroutine."

It seems to be wrong, a method written as follow:

def test(): yield 1

will be evaluated as a coroutine by asyncio.iscoroutine(), even if not decorated. The old doc stated "Return True if obj is a coroutine object, which may be based on a generator or an async def coroutine.", which seems more correct.

----------
messages: 326404
nosy: Gefn
priority: normal
severity: normal
status: open
title: asyncio.iscoroutine() documentation is wrong
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:39:40 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Sep 2018 20:39:40 +0000
Subject: [issue27934] json float encoding incorrect for dbus.Double
In-Reply-To: <1472761223.9.0.580662580928.issue27934@psf.upfronthosting.co.za>
Message-ID: <1537907980.94.0.545547206417.issue27934@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Serhiy]

> I have doubts about breaking it in a bugfix release of 2.7.

Yes, possibly we shouldn't have changed this (though it's a fairly horrible trick, IMO). I don't think it would be a good idea to revert the change at this point, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27934>
_______________________________________

From report at bugs.python.org  Tue Sep 25 16:41:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Sep 2018 20:41:08 +0000
Subject: [issue27934] json float encoding incorrect for dbus.Double
In-Reply-To: <1472761223.9.0.580662580928.issue27934@psf.upfronthosting.co.za>
Message-ID: <1537908068.06.0.545547206417.issue27934@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Agreed. It is too late.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27934>
_______________________________________

From report at bugs.python.org  Tue Sep 25 17:40:13 2018
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBCb3VkYQ==?=)
Date: Tue, 25 Sep 2018 21:40:13 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537911613.52.0.545547206417.issue34781@psf.upfronthosting.co.za>


Tom?? Bouda <tomas.bouda at gmail.com> added the comment:

It's very difficult to reproduce.

In this example to get stuck on 3.6/OSX I need to attach debugger. However, the freeze happens regardless of print/logging, even def f(): pass can get stuck. os.write() made no difference and frozen, as well, as I've just tried.

It might be even possible that there's another problem in debugger itself, however on 2.7/RHEL the actual (production) code is embedded in unittest with "discover" mode, run from shell, no debugger attached. 

I couldn't reproduce it today morning. Later on afternoon in another script it occured 2 times in a row. In the past months, I have seen the problem under various conditions. Originally, I used ProcessPoolExecutor before, where it happened rather often, so I rewrote the code to use Pool directly, the problem is rare, now, but still occurs.

The production code has many variants including logging/custom prints/no prints at all, from time to time it happens regardless of anything else. However, there's also a heavy load and high OS resource demand (tens of workers, tens of GBs read/allocated, many/explicit calls to GC, etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Tue Sep 25 17:44:42 2018
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBCb3VkYQ==?=)
Date: Tue, 25 Sep 2018 21:44:42 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537911882.43.0.545547206417.issue34781@psf.upfronthosting.co.za>


Tom?? Bouda <tomas.bouda at gmail.com> added the comment:

Oh, I should add that by decreasing number of workers to 4 or 8 the problem disappeared, at least to the extent when I wasn't able to reproduce it on any environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Tue Sep 25 18:31:02 2018
From: report at bugs.python.org (Jesse Hostetler)
Date: Tue, 25 Sep 2018 22:31:02 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
Message-ID: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>


New submission from Jesse Hostetler <jessehostetler at gmail.com>:

The 'argparse' module gives a parse error for integer arguments written in scientific notation. I would expect this to work, since integers can be constructed from literals in scientific notation.

Example (also attached):

import argparse
foo = int(1e3) # Works: foo = 1000
parser = argparse.ArgumentParser()
parser.add_argument( "--foo", type=int )
parser.parse_args( ["--foo=1e3"] )
# error: argument --foo: invalid int value: '1e3'

----------
components: Library (Lib)
files: argparse-int-scientific.py
messages: 326409
nosy: jessehostetler
priority: normal
severity: normal
status: open
title: argparse int type does not accept scientific notation
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47824/argparse-int-scientific.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Tue Sep 25 18:37:22 2018
From: report at bugs.python.org (Jesse Hostetler)
Date: Tue, 25 Sep 2018 22:37:22 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
In-Reply-To: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>
Message-ID: <1537915042.81.0.545547206417.issue34803@psf.upfronthosting.co.za>


Jesse Hostetler <jessehostetler at gmail.com> added the comment:

I suppose desired behavior would be to accept the argument only if it can be converted to int without loss of information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Tue Sep 25 18:53:36 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 25 Sep 2018 22:53:36 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537916016.71.0.545547206417.issue34334@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Great, thanks.  I've made the other changes to the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 19:00:19 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 25 Sep 2018 23:00:19 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537916419.17.0.545547206417.issue34334@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset d345bb4d9b6e16c681cd8a4e1fff94ecd6b0bb09 by Vinay Sajip (Cheryl Sabella) in branch 'master':
bpo-34334: Don't log traceback twice in QueueHandler (GH-9537)
https://github.com/python/cpython/commit/d345bb4d9b6e16c681cd8a4e1fff94ecd6b0bb09


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 19:00:37 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 23:00:37 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1537916437.75.0.545547206417.issue34334@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8982

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 19:34:25 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 25 Sep 2018 23:34:25 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
In-Reply-To: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>
Message-ID: <1537918465.68.0.545547206417.issue34803@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The conversion fails because is trying to convert a string, not a float:

>>> int("1e3")
*** ValueError: invalid literal for int() with base 10: '1e3'

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Tue Sep 25 19:36:05 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 25 Sep 2018 23:36:05 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
In-Reply-To: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>
Message-ID: <1537918565.77.0.545547206417.issue34803@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

You can always do:

import argparse
foo = int(1e3) # Works: foo = 1000
parser = argparse.ArgumentParser()
parser.add_argument( "--foo", type=lambda x: int(float(x)))
parser.parse_args( ["--foo=1e3"] )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Tue Sep 25 21:44:51 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 01:44:51 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1537926291.23.0.545547206417.issue34802@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. I believe this was done as part asyncio docs overhaul and I am adding Yury here. The current docs link to #coroutine from asyncio.iscoroutine whereas the previous docs had the definition inline. I think this is clarified in #awaitables section but takes a round-trip and it's not in #coroutines section which is linked in asyncio.iscoroutine. The below is present in important note in #awaitables and may be this can be added to #coroutine too so that it's not last? Suggestions welcome 

> asyncio also supports legacy generator-based coroutines

I would suggest below for #coroutines :  

> Coroutines declared with async/await syntax is the preferred way of writing asyncio applications but asyncio also supports legacy generator-based coroutines.

Thanks

----------
nosy: +xtreak, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Tue Sep 25 21:48:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 01:48:33 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1537926513.91.0.545547206417.issue9334@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Tue Sep 25 21:54:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 01:54:34 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
In-Reply-To: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>
Message-ID: <1537926874.96.0.545547206417.issue34803@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Tue Sep 25 23:59:05 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 03:59:05 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537934345.12.0.545547206417.issue34320@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2aaf98c16ae3070378de523a173e29644037d8bd by Miss Islington (bot) (INADA Naoki) in branch 'master':
bpo-34320: Fix dict(o) didn't copy order of dict subclass (GH-8624)
https://github.com/python/cpython/commit/2aaf98c16ae3070378de523a173e29644037d8bd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Tue Sep 25 23:59:13 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 03:59:13 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537934353.73.0.545547206417.issue34320@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8983

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Tue Sep 25 23:59:19 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 03:59:19 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537934359.78.0.545547206417.issue34320@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8984

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Wed Sep 26 00:17:55 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 04:17:55 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537935475.98.0.545547206417.issue34320@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 12e3e80241e91df79811f53ff372e28e9371bf9b by Miss Islington (bot) in branch '3.7':
bpo-34320: Fix dict(o) didn't copy order of dict subclass (GH-8624)
https://github.com/python/cpython/commit/12e3e80241e91df79811f53ff372e28e9371bf9b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Wed Sep 26 01:23:08 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 05:23:08 +0000
Subject: [issue34804] Repetition of 'for example' in documentation
Message-ID: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>


New submission from Aydin <bagiyevaydin at gmail.com>:

In the documentation of Python 3.7.0 there is an error in the usage of the world 'for example'.

----------
assignee: docs at python
components: Documentation
files: Functional Programming HOWTO ? Python 3.7.0 documentation.png
messages: 326418
nosy: docs at python, rarblack
priority: normal
severity: normal
status: open
title: Repetition of 'for example' in documentation
versions: Python 3.7
Added file: https://bugs.python.org/file47825/Functional Programming HOWTO ? Python 3.7.0 documentation.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34804>
_______________________________________

From report at bugs.python.org  Wed Sep 26 01:56:33 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 26 Sep 2018 05:56:33 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537941393.66.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

ISTM that this issue can finally be closed!

Followup on some remaining minor points brought up here, such as colors and squeezing of multiple output lines printed separately, could be done in separate issues or discussed on idle-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Wed Sep 26 02:18:03 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 26 Sep 2018 06:18:03 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
Message-ID: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck <pekka.klarck at gmail.com>:

I had a use case where `MyClass.__subclasses__()` returning classes in the definition order would have made the code simpler. They seemed to be returned in that order, but because the docs didn't say anything about it [1] I did some searching to find out can I trust the order to stay the same also in the future.

Based on my searches it seems that prior to Python 3.5 the information was stored in a list and that preserved the order. In Python 3.5 the information was stored into a dict for performance reasons as part of issue 17936 [2]. Back then dicts weren't ordered, so the order is undefined in Python 3.5, but in Python 3.6+ the order is again preserved. In practice Python 3.5 is the only current version where the order of `__subclasses__()` is not defined.

My proposal is to make the current, and old, behavior of returning classes from `__subclassses__()` in definition order explicit. If nobody has anything against that, I'd be willing to provide a pull request updating docs and adding unit tests making sure the order is not messed up in the future. Let me also know if even this kind of simple changes would need to go through python-ideas or python-dev. The PEP process feels overkill when there are no code changes required.


PS: I know both Antoine and Guido commented issue 17936 [3] that they don't know any use cases for the order. I can explain my use case if someone is interested.

[1] https://docs.python.org/3/library/stdtypes.html?highlight=__subclasses__#class.__subclasses__
[2] https://bugs.python.org/issue17936
[3] https://bugs.python.org/issue17936#msg189959

----------
messages: 326420
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Explicitly specify `MyClass.__subclasses__()` returns classes in definition order

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34805>
_______________________________________

From report at bugs.python.org  Wed Sep 26 02:38:40 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 06:38:40 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537943920.4.0.545547206417.issue34320@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d45a9613402b686f8afd3dd5b6acf8141f14d711 by Miss Islington (bot) in branch '3.6':
[3.6] bpo-34320: Fix dict(o) didn't copy order of dict subclass (GH-8624) (GH-9583)
https://github.com/python/cpython/commit/d45a9613402b686f8afd3dd5b6acf8141f14d711


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Wed Sep 26 02:40:18 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 26 Sep 2018 06:40:18 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1537944018.6.0.545547206417.issue34320@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
dependencies:  -Add tests for PEP 468 and PEP 520
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Wed Sep 26 03:15:50 2018
From: report at bugs.python.org (Philippe Wagnieres)
Date: Wed, 26 Sep 2018 07:15:50 +0000
Subject: [issue31535] configparser unable to write comment with a upper cas
 letter
In-Reply-To: <1537803746.73.0.956365154283.issue31535@psf.upfronthosting.co.za>
Message-ID: <9f28e209-4116-3214-7dd1-bc79a4d1b059@hispeed.ch>


Philippe Wagnieres <philippewagnieres at hispeed.ch> added the comment:

Thank for your support.

Sorry I have no time to give you an answer and work on with Python, but 
I have understand the solution.

Best Regards

Philippe Wagni?res
Chalamont 6
1400 Yverdon-les-Bains
Suisse
tel.: +41 76 367 27 43

Le 24.09.2018 ? 17:42, Karthikeyan Singaravelan a ?crit?:
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
>
> All config options including comment are converted to lowercase when they are stored. You can customize this behavior using https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform . You can also refer to https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour for more customization. I am closing this as not a bug as part of triaging. Feel free to reopen this if needed.
>
> Thanks for the report Philippe!
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31535>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31535>
_______________________________________

From report at bugs.python.org  Wed Sep 26 03:18:08 2018
From: report at bugs.python.org (shashank)
Date: Wed, 26 Sep 2018 07:18:08 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1537946288.47.0.545547206417.issue21109@psf.upfronthosting.co.za>


shashank <shanx.shashank at gmail.com> added the comment:

Added tests.
Patch file: safetarfile-4.diff

Following works with 456 tests passed, after doing `make clean && make`
# ./python -m unittest -v test.test_tarfile

Attached patch is on top of master's commit:
commit 2aaf98c16ae3070378de523a173e29644037d8bd (HEAD -> master, origin/master, origin/HEAD)
Author: INADA Naoki <methane at users.noreply.github.com>
Date:   Wed Sep 26 12:59:00 2018 +0900

----------
Added file: https://bugs.python.org/file47826/safetarfile-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Wed Sep 26 03:40:56 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Sep 2018 07:40:56 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1537947656.05.0.545547206417.issue34687@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I think the only way to make sure that proactor event loop is stable -- starting to use it everywhere on Windows.

Let's do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Wed Sep 26 03:46:47 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Sep 2018 07:46:47 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>
Message-ID: <1537948007.27.0.545547206417.issue34793@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I don't care too much.
Maybe removal is just fine.
`with await ...` looks awkward anyway

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34793>
_______________________________________

From report at bugs.python.org  Wed Sep 26 03:59:58 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Wed, 26 Sep 2018 07:59:58 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537948798.11.0.545547206417.issue34694@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/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:01:41 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Sep 2018 08:01:41 +0000
Subject: [issue34679] asyncio.add_signal_handler call fails if not on main
 thread
In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za>
Message-ID: <1537948901.6.0.545547206417.issue34679@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

In my opinion, we should don't change the behavior.
Signal handlers should be processed in main thread at the end, that's how Python works for regular synchronous API.

Mentioning it in the doc makes sense.

Would you make a pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34679>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:01:58 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Sep 2018 08:01:58 +0000
Subject: [issue34679] asyncio.add_signal_handler call fails if not on main
 thread
In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za>
Message-ID: <1537948918.68.0.545547206417.issue34679@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34679>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:05:25 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 26 Sep 2018 08:05:25 +0000
Subject: [issue34271] Please support logging of SSL master secret by env
 variable SSLKEYLOGFILE
In-Reply-To: <1532867889.16.0.56676864532.issue34271@psf.upfronthosting.co.za>
Message-ID: <1537949125.49.0.545547206417.issue34271@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

I didn't know this, but apparently the SSLKEYLOGFILE envvar is a de-facto standard: chrome, firefox, and libcurl all check for this envvar, and if found they log TLS secrets to the file in a specific format.

Reports of projects supporting this:

- https://www.imperialviolet.org/2012/06/25/wireshark.html
- https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/
- https://ec.haxx.se/tls-sslkeylogfile.html

Also, people are using gross ctypes hacks to convince Python to do this too: https://github.com/joernheissler/SslMasterKey

Also, now that I know this exists I kind of wish it was supported because I've been frustrated by this problem before myself :-).

My first thought was that the ssl module should provide methods to extract the various secret values (e.g., wrappers for SSL_SESSION_get_master_key and SSL_get_client_random), and leave the environment variable checking to user code. But... looking at the file format docs:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

...it appears that TLS 1.3 has more and different secrets than previous versions, and trying to expose all these different pieces seems pretty messy. If we simply implement SSLKEYLOGFILE, that would give people what they want, and since we would be writing it out ourselves we could make it handle different TLS versions internally without exposing that complexity as part of the API.

We would of course have to disable this if -E was passed on the command line.

As an FYI to anyone looking at this bug, Christian (the main ssl module maintainer) is generally *very* overloaded, so I would say that the chances of this actually being implemented go *way* up if someone puts together a PR.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34271>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:06:20 2018
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 Sep 2018 08:06:20 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
Message-ID: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

two distutils tests fail when running the tests from an installed location. 3.7 branch 20180925, succeeded with a 20180911 snapshot. Is there any locale setting required?

======================================================================
ERROR: test_non_ascii (distutils.tests.test_log.TestLog) (errors='surrogateescape')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.7/distutils/tests/test_log.py", line 26, in test_non_ascii
    log.debug('D?bug\tM?ss?ge')
  File "/usr/lib/python3.7/distutils/log.py", line 41, in debug
    self._log(DEBUG, msg, args)
  File "/usr/lib/python3.7/distutils/log.py", line 34, in _log
    stream.write('%s\n' % msg)
  File "/usr/lib/python3.7/encodings/cp437.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0117' in position 7: character maps to <undefined>

======================================================================
ERROR: test_find_executable (distutils.tests.test_spawn.SpawnTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.7/distutils/tests/test_spawn.py", line 95, in test_find_executable
    rv = find_executable(program)
  File "/usr/lib/python3.7/distutils/spawn.py", line 176, in find_executable
    path = os.environ['PATH']
  File "/usr/lib/python3.7/os.py", line 678, in __getitem__
    raise KeyError(key) from None
KeyError: 'PATH'

----------------------------------------------------------------------

----------
components: Distutils
keywords: 3.7regression
messages: 326428
nosy: doko, dstufft, eric.araujo, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: distutils tests fail with recent 3.7 branch
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:10:46 2018
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 Sep 2018 08:10:46 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537949446.9.0.545547206417.issue34806@psf.upfronthosting.co.za>


Change by Matthias Klose <doko at debian.org>:


----------
nosy: +serhiy.storchaka, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:17:25 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 26 Sep 2018 08:17:25 +0000
Subject: [issue34271] Please support logging of SSL master secret by env
 variable SSLKEYLOGFILE
In-Reply-To: <1532867889.16.0.56676864532.issue34271@psf.upfronthosting.co.za>
Message-ID: <1537949845.6.0.545547206417.issue34271@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Cory contributed a high level API for OpenSSL 1.1.1,  https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_keylog_callback.html I already have a patch somewhere on my disk. The patch is trivial if we ignore OpenSSL < 1.1.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34271>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:25:56 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 26 Sep 2018 08:25:56 +0000
Subject: [issue34271] Please support logging of SSL master secret by env
 variable SSLKEYLOGFILE
In-Reply-To: <1532867889.16.0.56676864532.issue34271@psf.upfronthosting.co.za>
Message-ID: <1537950356.44.0.545547206417.issue34271@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Here is a horribly hacky and simple implementation. I have a more elaborate implementation that does correct locking and has no global state.

static BIO *bio_keylog = NULL;

static void keylog_callback(const SSL *ssl, const char *line)
{
    BIO_printf(bio_keylog, "%s\n", line);
    (void)BIO_flush(bio_keylog);
}

int PySSL_set_keylog_file(SSL_CTX *ctx, const char *keylog_file)
{
    /* Close any open files */
    BIO_free_all(bio_keylog);
    bio_keylog = NULL;

    if (ctx == NULL || keylog_file == NULL) {
        /* Keylogging is disabled, OK. */
        return 0;
    }

    /*
     * Append rather than write in order to allow concurrent modification.
     * Furthermore, this preserves existing keylog files which is useful when
     * the tool is run multiple times.
     */
    bio_keylog = BIO_new_file(keylog_file, "a");
    if (bio_keylog == NULL) {
        BIO *b = BIO_new_fp(stderr, BIO_NOCLOSE | BIO_FP_TEXT);
        BIO_printf(b, "Error writing keylog file %s\n", keylog_file);
        BIO_free_all(b);
        return 1;
    }

    /* Write a header for seekable, empty files (this excludes pipes). */
    if (BIO_tell(bio_keylog) == 0) {
        BIO_puts(bio_keylog,
                 "# SSL/TLS secrets log file, generated by OpenSSL\n");
        (void)BIO_flush(bio_keylog);
    }
    SSL_CTX_set_keylog_callback(ctx, keylog_callback);
    return 0;
}

----------
stage:  -> needs patch
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34271>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:35:45 2018
From: report at bugs.python.org (Johannes Frank)
Date: Wed, 26 Sep 2018 08:35:45 +0000
Subject: [issue34271] Please support logging of SSL master secret by env
 variable SSLKEYLOGFILE
In-Reply-To: <1537950356.44.0.545547206417.issue34271@psf.upfronthosting.co.za>
Message-ID: <CAMgHmh9f-XNwTSdheDHqorceQaC9ETPfQCnNtoZD=9LJwS_t5w@mail.gmail.com>


Johannes Frank <jmfrank63 at gmail.com> added the comment:

Hi Christian
I would be willing to give this a try, could you publish or send me that
more elaborate code?
Thanks Johannes

On Wed, 26 Sep 2018 at 09:25, Christian Heimes <report at bugs.python.org>
wrote:

>
> Christian Heimes <lists at cheimes.de> added the comment:
>
> Here is a horribly hacky and simple implementation. I have a more
> elaborate implementation that does correct locking and has no global state.
>
> static BIO *bio_keylog = NULL;
>
> static void keylog_callback(const SSL *ssl, const char *line)
> {
>     BIO_printf(bio_keylog, "%s\n", line);
>     (void)BIO_flush(bio_keylog);
> }
>
> int PySSL_set_keylog_file(SSL_CTX *ctx, const char *keylog_file)
> {
>     /* Close any open files */
>     BIO_free_all(bio_keylog);
>     bio_keylog = NULL;
>
>     if (ctx == NULL || keylog_file == NULL) {
>         /* Keylogging is disabled, OK. */
>         return 0;
>     }
>
>     /*
>      * Append rather than write in order to allow concurrent modification.
>      * Furthermore, this preserves existing keylog files which is useful
> when
>      * the tool is run multiple times.
>      */
>     bio_keylog = BIO_new_file(keylog_file, "a");
>     if (bio_keylog == NULL) {
>         BIO *b = BIO_new_fp(stderr, BIO_NOCLOSE | BIO_FP_TEXT);
>         BIO_printf(b, "Error writing keylog file %s\n", keylog_file);
>         BIO_free_all(b);
>         return 1;
>     }
>
>     /* Write a header for seekable, empty files (this excludes pipes). */
>     if (BIO_tell(bio_keylog) == 0) {
>         BIO_puts(bio_keylog,
>                  "# SSL/TLS secrets log file, generated by OpenSSL\n");
>         (void)BIO_flush(bio_keylog);
>     }
>     SSL_CTX_set_keylog_callback(ctx, keylog_callback);
>     return 0;
> }
>
> ----------
> stage:  -> needs patch
> versions: +Python 3.8 -Python 3.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34271>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34271>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:36:33 2018
From: report at bugs.python.org (Antony Lee)
Date: Wed, 26 Sep 2018 08:36:33 +0000
Subject: [issue34807] pathlib.[r]glob fails when the toplevel directory is not
 readable, whereas glob.glob "succeeds"
Message-ID: <1537950993.74.0.545547206417.issue34807@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

After

    $ mkdir -p foo/bar && chmod 000 foo

one gets

    In [1]: glob.glob("foo/bar")
    Out[1]: []

but

    In  [2]: list(Path("foo/bar").glob("*"))

gives a PermissionError.

I'm not arguing that pathlib should reproduce glob's behavior (in fact I think raising an exception is better in this case), but this could be better documented (os.walk does indicate that "By default, errors from the scandir() call are ignored." whereas I don't think either glob or pathlib docs mention this point at all).

Compare with https://bugs.python.org/issue24120, which relates to unreadable directories found *inside* the toplevel directory.

----------
components: Library (Lib)
messages: 326432
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: pathlib.[r]glob fails when the toplevel directory is not readable, whereas glob.glob "succeeds"
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34807>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:46:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 08:46:08 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537951568.7.0.545547206417.issue34806@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The test in distutils/tests/test_log.py matches the current code (with changes added in issue34421), but the code in distutils/log.py doesn't match the current code. Looks like the stdlib and tests are unsynchronized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 04:57:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 08:57:26 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537952246.45.0.545547206417.issue34806@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have reproduced this error by checking out the revision before issue34421 changes.

git checkout 77b92b15a5e5c84b91d3fd9d02f63db432fa8903~ Lib/distutils/log.py
./python -m test -v -m test_log test_distutils

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 05:06:52 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 26 Sep 2018 09:06:52 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537952812.84.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> There are _two_ hash functions at play in that collision:  the tuple hash function, and the integer hash function.  Regardless of whether the _tuple_ hash function does [anything involving just `t`], that only directly affects the result of the _int_ hash function

...which is what you want here. The collision hash((3,3)) == hash((-3,-3)) is due a specific structure in the input to the FNV algorithm. The operation t ^= t << 7 that you suggested (and which I approve, except for the shift amount) is meant precisely to destroy that structure.

> If you feel you just have to mess with low-order bits, do it instead on the _tuple_ hash intermediate results, not on its inputs. It's x you care about directly, not t.

That would not be a good solution, because that destroys the structure of the has algorithm. For Bernstein for example, each loop iteration should do something like

    x = (x * m) + t

for *some* value t depending on the input. If you mess with x, then it really becomes a different hash algorithm. That is far more dangerous than simply applying a permutation on t.

> Mucking with t to avoid the nested-tuple catastrophes is worth it, but I prefer to do that with as little damage to t's desirable properties as reasonably possible.

Which "desirable properties" of t does the operation t ^= (t << 1) damage?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Wed Sep 26 05:11:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 09:11:00 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1537953060.79.0.545547206417.issue30156@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Note: I reported a similar issue which has then been marked as a duplicate of this one: bpo-34223. Copy of my first message:
---
It seems like Python has an invalid object somewhere. PYTHONDUMPREFS=1 makes Python crash at exit.

$ PYTHONDUMPREFS=1 ./python -c pass
(...)
0x7f1992292448 [1] (<class '_thread._localdummy'>, <class 'object'>)
0x7f1992241aa8 [1] {'__doc__': 'Thread-local dummy'}
0x7f199222c740 [1] (<class 'object'>,)
0x9c98a0 [2] <class '_thread._localdummy'>
0x7f1992217dc0 [1] 
Segmentation fault (core dumped)
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Wed Sep 26 05:15:41 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 26 Sep 2018 09:15:41 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1537953341.17.0.545547206417.issue21109@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

shashank, you're making good progress on this!

The tests should also put SafeTarFile through all of the tests for TarFile, considering that it is being described as a drop-in replacement. You should look through the existing tests for other modules which do similar things for methods to implement this cleanly, e.g. Lib/tests/test_binascii.py and Lib/tests/datetimetester.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Wed Sep 26 05:24:01 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Sep 2018 09:24:01 +0000
Subject: [issue28556] typing.py upgrades
In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za>
Message-ID: <1537953841.62.0.545547206417.issue28556@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +8985

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28556>
_______________________________________

From report at bugs.python.org  Wed Sep 26 06:06:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 10:06:34 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537956394.02.0.545547206417.issue34806@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 06:08:43 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 10:08:43 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
In-Reply-To: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>
Message-ID: <1537956523.17.0.545547206417.issue34805@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34805>
_______________________________________

From report at bugs.python.org  Wed Sep 26 06:13:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 10:13:24 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537956804.8.0.545547206417.issue34806@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Test case failure regarding test_find_executable was fixed with issue34530 on master and backported.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 06:24:44 2018
From: report at bugs.python.org (ekul)
Date: Wed, 26 Sep 2018 10:24:44 +0000
Subject: [issue28117] warning: dereferencing type-punned pointer will break
 strict-aliasing rules
In-Reply-To: <1473750714.22.0.188258678348.issue28117@psf.upfronthosting.co.za>
Message-ID: <1537957484.14.0.545547206417.issue28117@psf.upfronthosting.co.za>


ekul <tech at ekul.org> added the comment:

I just got this set of warnings while building 3.6.6 on RasPi Debian9/ARM. Good to know the warning is spurious. 

Just finding my way here - is Serhiy's patch above a working 2016 fix for this that got stuck in review? I couldn't find a PR for it. If the warning _is_ spurious it would be great to patch it.

----------
nosy: +ekul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28117>
_______________________________________

From report at bugs.python.org  Wed Sep 26 06:57:11 2018
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 Sep 2018 10:57:11 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537959431.08.0.545547206417.issue34806@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

issue34530 was already fixed on 20180904, so there's something else...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:09:30 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 26 Sep 2018 11:09:30 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537960170.25.0.545547206417.issue32956@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

Thanks Serhiy, I read the Python-Dev thread you linked to, but that doesn't resolve the issues:

- Its topic is Python 2.6 (where this behavior does not occur) rather than Python 3 (where it does).

- A few messages into the thread Guido does address Python 3, but in fact says "I think the consensus is against round-to-even in 3.0" (see https://mail.python.org/pipermail/python-dev/2008-January/075897.html).

- There is no discussion of the fact that this behavior differs from the function named "round" in all the other programming languages I mentioned, and whether it would therefore be better exposed as an additional function (e.g. "round_to_even" or "round_unbiased", and in the math or statistics package rather than builtins). Surprisingly, Excel is the only other programming environment I saw discussed in the thread. (And round(2.5) == 3 there.)

So that all suggests there must be some other thread or issue where this change for Python 3 have been discussed, but I looked again and could not find it. 

The C "rint" example you gave just seems to prove the point that this behavior should have a distinct name from "round".

Regarding:
> It is a common knowledge that rounding half-to-even is what users want in most cases

I don't think that's common knowledge; seems like citation needed? Based on all the other languages where this differs (not to mention Python 2), it's not clear users would want Python 3 to be the only different one. And this is definitely a surprise for the majority of programmers, whose experience with "round" is how it works everywhere else. (This is making it into pywat after all: https://github.com/cosmologicon/pywat/pull/40)

I can submit a PR for at least updating the docs about this (as per my previous comment) if that would be welcomed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:18:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 11:18:54 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537960734.72.0.545547206417.issue34806@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't understand this bug report.

"./python -m test test_distutils -v -m test_non_ascii" pass in 3.6, 3.7 and master branches.

> two distutils tests fail when running the tests from an installed location. 3.7 branch 20180925, succeeded with a 20180911 snapshot.

I don't know what are these branches.

I tested the v3.7.0 test: "./python -m test test_distutils -v -m test_non_ascii" pass as well. It seems like you tested something between 3.7.0 and the current 3.7 branch.

I suggest you to wait for the 3.7.1 release which should be release next weeks.

--

distutils/log.py evolved a lot. The code now uses:

            try:
                stream.write('%s\n' % msg)
            except UnicodeEncodeError:
                # emulate backslashreplace error handler
                encoding = stream.encoding
                msg = msg.encode(encoding, "backslashreplace").decode(encoding)
                stream.write('%s\n' % msg)

Your traceback shows a stream.write() call on line 34, which isn't the case on the current 3.7 branch. So you are testing an outdated 3.7 commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:19:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 11:19:55 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537960795.05.0.545547206417.issue34806@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum, to be clear, I suggest to close the issue (FIXED), since both failures have been fixed in development branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:22:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 11:22:47 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537960967.37.0.545547206417.issue32956@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Rounding floating point numbers is a complex topic :-) Here are my notes on that topic: https://vstinner.readthedocs.io/misc.html#rounding It took me years to fix how Python rounds timestamps :-)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:40:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Sep 2018 11:40:18 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1537962017.99.0.545547206417.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes. Congratulations on your persistence.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:43:35 2018
From: report at bugs.python.org (ucyo)
Date: Wed, 26 Sep 2018 11:43:35 +0000
Subject: [issue34808] bytes[0] != bytes[0:1]
Message-ID: <1537962215.0.0.545547206417.issue34808@psf.upfronthosting.co.za>


New submission from ucyo <urcyglu at gmail.com>:

bytes('sdf', 'UTF8')[0] != bytes('sdf', 'UTF8')[0:1]  # FALSE
'sdf'[0] != 'sdf'[0:1]  # TRUE

Is this a feature or bug. I would have expected the same behaviour.

----------
components: Library (Lib)
messages: 326446
nosy: ucyo
priority: normal
severity: normal
status: open
title: bytes[0] != bytes[0:1]
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34808>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:46:40 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 Sep 2018 11:46:40 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537962400.73.0.545547206417.issue32956@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@jab: Did you see this message from the thread that Serhiy pointed to? https://mail.python.org/pipermail/python-dev/2008-January/075910.html

Here's the sound bite version, but see the message for context:

[Guido]
> Wow. Do you have an opinion as to whether we should adopt
> round-to-even at all (as a default)?

[Tim]
Yes:  yes :-)  [...]

Note that Python is not alone here: .NET also uses round-ties-to-even as the default rounding mode. Note also that the languages you mention don't all agree with one another either: try rounding -2.5 to the nearest integer in JavaScript and see what result you get.

[Joshua]
> and whether it would therefore be better exposed as an additional function (e.g. "round_to_even" or "round_unbiased"

Changing the default behaviour of `round` again seems highly undesirable to me; I'd be strongly opposed to such a change. Proposals for backwards-compatible changes that make the round-ties-away-from-zero function available again under a different name (or via a keyword argument to `round`) could be worth discussing. And suggestions/PRs for documentation clarification are welcome, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:47:33 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 11:47:33 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537962453.03.0.545547206417.issue34781@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If I understand correctly you have two cases:
- the standalone script hangs with 3.6 on OS X
- a much more involved use case hangs with 2.7 on RedHat

It's possible you are hitting two different bugs.  The 2.7 issue may be due to third-party packages or other issues.

It would be nice if another OS X user could try your reproducer script on 3.6+ and find out whether they can reproduce/diagnose the issue at all.

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:47:50 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 Sep 2018 11:47:50 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537962470.72.0.545547206417.issue32956@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Adding Tim Peters to the nosy list, so that he can tell me that I'm misrepresenting him ...

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Wed Sep 26 07:58:00 2018
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 Sep 2018 11:58:00 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537963080.27.0.545547206417.issue34806@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

well, it was top of the branch yesterday

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:02:56 2018
From: report at bugs.python.org (Ruslan Kharitonov)
Date: Wed, 26 Sep 2018 12:02:56 +0000
Subject: [issue34809] On MacOSX with 3.7 python getting "Symbol not found:
 _PyString_AsString"
Message-ID: <1537963376.97.0.545547206417.issue34809@psf.upfronthosting.co.za>


New submission from Ruslan Kharitonov <therk at me.com>:

Getting the following error on MacOSX after installing Python 3.7.0 from the Python download. Also, tried installing from brew.

?  ~ python3
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from bin.test import *
>>> help(fetch_words)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_sitebuiltins.py", line 102, in __call__
    import pydoc
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 66, in <module>
    import platform
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/platform.py", line 116, in <module>
    import sys, os, re, subprocess
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/subprocess.py", line 139, in <module>
    import _posixsubprocess
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_posixsubprocess.so, 2): Symbol not found: _PyString_AsString
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_posixsubprocess.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_posixsubprocess.so

----------
components: macOS
messages: 326451
nosy: ned.deily, ronaldoussoren, therk
priority: normal
severity: normal
status: open
title: On MacOSX with 3.7 python getting "Symbol not found: _PyString_AsString"
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34809>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:03:25 2018
From: report at bugs.python.org (Ruslan Kharitonov)
Date: Wed, 26 Sep 2018 12:03:25 +0000
Subject: [issue34809] On MacOSX with 3.7 python getting "Symbol not found:
 _PyString_AsString"
In-Reply-To: <1537963376.97.0.545547206417.issue34809@psf.upfronthosting.co.za>
Message-ID: <1537963405.23.0.545547206417.issue34809@psf.upfronthosting.co.za>


Change by Ruslan Kharitonov <therk at me.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34809>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:05:15 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 26 Sep 2018 12:05:15 +0000
Subject: [issue34809] On MacOSX with 3.7 python getting "Symbol not found:
 _PyString_AsString"
In-Reply-To: <1537963376.97.0.545547206417.issue34809@psf.upfronthosting.co.za>
Message-ID: <1537963515.87.0.545547206417.issue34809@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Do you have a $PYTHONPATH in your environment?

For some reason the 3.7 install is looking in the site-packages directory for the 2.7 install. This is probably configuration on your system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34809>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:10:03 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 26 Sep 2018 12:10:03 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537963803.9.0.545547206417.issue32956@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

Thanks, Mark. Yes, I saw where Tim said round-half-even should be the default, but I didn't see any proposal to expose it as e.g. math.round_half_even() instead, nor a more complete look at what other languages do. That, along with the subject being 2.6 and not 3, made me think this change in Python 3 must have been discussed more fully elsewhere. Was it not?

And I agree -- nowhere have I been proposing changing "round" again. My proposals have been:

1. Update the round() docs to make the documentation of this behavior less buried,
2. include a (brief) justification (possibly even just a link to http://wiki.c2.com/?BankersRounding or some more-authoritative document), and
3. link to where else this change in Python 3 was discussed more, if anywhere, or else confirm this change was made based on no additional analysis that we can find written down.

It'd also be interesting to hear if this is something we wish we'd done differently now, but that shouldn't distract from 1, 2, and 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:10:39 2018
From: report at bugs.python.org (Ruslan Kharitonov)
Date: Wed, 26 Sep 2018 12:10:39 +0000
Subject: [issue34809] On MacOSX with 3.7 python getting "Symbol not found:
 _PyString_AsString"
In-Reply-To: <1537963515.87.0.545547206417.issue34809@psf.upfronthosting.co.za>
Message-ID: <F079BDA0-3CF8-46E2-904D-BFA56B4E50E6@me.com>


Ruslan Kharitonov <therk at me.com> added the comment:

Yes, this was the issue. Thank you.

> On Sep 26, 2018, at 8:05 AM, Ronald Oussoren <report at bugs.python.org> wrote:
> 
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> Do you have a $PYTHONPATH in your environment?
> 
> For some reason the 3.7 install is looking in the site-packages directory for the 2.7 install. This is probably configuration on your system.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34809>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34809>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:11:00 2018
From: report at bugs.python.org (Geoffrey Spear)
Date: Wed, 26 Sep 2018 12:11:00 +0000
Subject: [issue34808] bytes[0] != bytes[0:1]
In-Reply-To: <1537962215.0.0.545547206417.issue34808@psf.upfronthosting.co.za>
Message-ID: <1537963860.56.0.545547206417.issue34808@psf.upfronthosting.co.za>


Geoffrey Spear <geoffspear at gmail.com> added the comment:

Indexing bytes giving an int is a feature. Some might argue it's a bad feature, but it was done on purpose.

----------
nosy: +geoffreyspear

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34808>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:15:13 2018
From: report at bugs.python.org (ucyo)
Date: Wed, 26 Sep 2018 12:15:13 +0000
Subject: [issue34808] bytes[0] != bytes[0:1]
In-Reply-To: <1537962215.0.0.545547206417.issue34808@psf.upfronthosting.co.za>
Message-ID: <1537964113.73.0.545547206417.issue34808@psf.upfronthosting.co.za>


ucyo <urcyglu at gmail.com> added the comment:

Thank you for the answer.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34808>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:16:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 12:16:18 +0000
Subject: [issue31837] ParseError in test_all_project_files()
In-Reply-To: <1508605682.35.0.213398074469.issue31837@psf.upfronthosting.co.za>
Message-ID: <1537964178.11.0.545547206417.issue31837@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The warnings were introduced with issue13125 and this was fixed with issue30117 . I verified it as below : 

?  cpython git:(master) git checkout 14e976e00e65bf343ba0fca016c3c9132a843daf~1
?  cpython git:(ce0f33d045) git clean -xdf && ./configure --with-pydebug && make -s -j4
?  cpython git:(ce0f33d045) time ./python.exe -I -S -m test.regrtest -vv test_import test_lib2to3 >/dev/null
Warning -- files was modified by test_import
  Before: []
  After:  ['@test_41673_tmp.pyc']
/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/lib2to3/tests/test_parser.py:430: UserWarning: ParseError on file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/lib2to3/main.py (bad input: type=22, value='=', context=('', (130, 38)))
  warnings.warn('ParseError on file %s (%s)' % (filepath, err))
/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/lib2to3/tests/test_parser.py:430: UserWarning: ParseError on file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/lib2to3/tests/pytree_idempotency.py (bad input: type=22, value='=', context=('', (49, 33)))
  warnings.warn('ParseError on file %s (%s)' % (filepath, err))
./python.exe -I -S -m test.regrtest -vv test_import test_lib2to3 > /dev/null  44.31s user 1.18s system 94% cpu 47.971 total

# Fixed commit

?  cpython git:(14e976e00e) time ./python.exe -I -S -m test.regrtest -vv test_import test_lib2to3 >/dev/null
Warning -- files was modified by test_import
  Before: []
  After:  ['@test_41839_tmp.pyc']
./python.exe -I -S -m test.regrtest -vv test_import test_lib2to3 > /dev/null  50.50s user 1.56s system 91% cpu 56.778 total

The test_import warning is also not reproducible with master as of now I will find the necessary commit and reply back in issue28655. As part of triaging I am closing this as duplicate with issue30117 as superseder which has the fix. Feel free to reopen this if needed.

Thanks

----------
nosy: +xtreak
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_lib2to3.test_parser.test_all_project_files() fails

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31837>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:32:36 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Wed, 26 Sep 2018 12:32:36 +0000
Subject: [issue34670] Add set_post_handshake_auth for TLS 1.3
In-Reply-To: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>
Message-ID: <1537965156.37.0.545547206417.issue34670@psf.upfronthosting.co.za>


Dimitri John Ledkov <dimitri.j.ledkov at intel.com> added the comment:

Will this be backported to the 2.7 branch as well? Pretty please =)

----------
nosy: +xnox

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34670>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:39:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 12:39:17 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537965557.12.0.545547206417.issue28655@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The dependency issue31837 dealing with test_lib2to3 failure was resolved by Victor in issue30117 and hence I marked it as a duplicate. The other issue regarding test_import is not reproducible on master as of  2aaf98c16ae3070378de523a173e29644037d8bd. test_import warning was reproducible with 14e976e00e65bf343ba0fca016c3c9132a843daf and it seems to have been fixed later. The same issue with test_import was reported by Victor in issue30834 which was closed as outdated since it was not reproducible. I will try to bisect to the commit that fixed test_import. I propose closing this as outdated as part of triaging.

Thanks much Serhiy and Victor for the reports and fixes.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:39:33 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 26 Sep 2018 12:39:33 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1537965573.54.0.545547206417.issue32956@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

I spent a few minutes with git blame/checkout/show and so far have found https://bugs.python.org/issue1869 (via https://github.com/python/cpython/commit/e6a076d). Still reading -- looks like there were a number of different changes made to round() at the same time for various reasons -- so maybe changing from round_half_up to round_half_even was necessary for the other improvements, and it couldn't have been exposed as a separate function? Or maybe that was just never proposed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:39:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 12:39:44 +0000
Subject: [issue31837] ParseError in test_all_project_files()
In-Reply-To: <1508605682.35.0.213398074469.issue31837@psf.upfronthosting.co.za>
Message-ID: <1537965584.78.0.545547206417.issue31837@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Karthikeyan!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31837>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:43:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 12:43:56 +0000
Subject: [issue34807] pathlib.[r]glob fails when the toplevel directory is not
 readable, whereas glob.glob "succeeds"
In-Reply-To: <1537950993.74.0.545547206417.issue34807@psf.upfronthosting.co.za>
Message-ID: <1537965836.03.0.545547206417.issue34807@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34807>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:47:42 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 12:47:42 +0000
Subject: [issue34262] Asyncio test fails under Win 7
In-Reply-To: <1532782721.54.0.56676864532.issue34262@psf.upfronthosting.co.za>
Message-ID: <1537966062.31.0.545547206417.issue34262@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34262>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:54:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 12:54:05 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1537966445.01.0.545547206417.issue34806@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> well, it was top of the branch yesterday

Hum, I don't understand because we don't have the same line number:

  File "/usr/lib/python3.7/distutils/log.py", line 34, in _log
    stream.write('%s\n' % msg)

$ git show bbdf8723324e31675f298dd273733cc13e1518df:Lib/distutils/log.py|gvim -

(...)
            try:
                stream.write('%s\n' % msg)
            except UnicodeEncodeError:
                # emulate backslashreplace error handler
                encoding = stream.encoding   # <~~~ line 34
                msg = msg.encode(encoding, "backslashreplace").decode(encoding)
                stream.write('%s\n' % msg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:55:59 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 26 Sep 2018 12:55:59 +0000
Subject: [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537966559.53.0.545547206417.issue34804@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Can you provide a link to the occurence of this repetition?

Thanks!

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34804>
_______________________________________

From report at bugs.python.org  Wed Sep 26 08:59:04 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 12:59:04 +0000
Subject: [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537966744.37.0.545547206417.issue34804@psf.upfronthosting.co.za>


Aydin <bagiyevaydin at gmail.com> added the comment:

https://docs.python.org/3/howto/functional.html

In the 5th paragraph.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34804>
_______________________________________

From report at bugs.python.org  Wed Sep 26 09:25:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 13:25:08 +0000
Subject: [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537968308.32.0.545547206417.issue34804@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34804>
_______________________________________

From report at bugs.python.org  Wed Sep 26 09:29:14 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 13:29:14 +0000
Subject: [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537968554.19.0.545547206417.issue34804@psf.upfronthosting.co.za>


Change by Aydin <bagiyevaydin at gmail.com>:


----------
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34804>
_______________________________________

From report at bugs.python.org  Wed Sep 26 09:44:56 2018
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 26 Sep 2018 13:44:56 +0000
Subject: [issue34809] On MacOSX with 3.7 python getting "Symbol not found:
 _PyString_AsString"
In-Reply-To: <1537963376.97.0.545547206417.issue34809@psf.upfronthosting.co.za>
Message-ID: <1537969496.32.0.545547206417.issue34809@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34809>
_______________________________________

From report at bugs.python.org  Wed Sep 26 09:48:03 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 26 Sep 2018 13:48:03 +0000
Subject: [issue31425] Expose AF_QIPCRTR in socket module
In-Reply-To: <1505168549.75.0.537554946733.issue31425@psf.upfronthosting.co.za>
Message-ID: <1537969683.87.0.545547206417.issue31425@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset bb8165172ac2ef8c7092e8e82928cc7f5f310ab3 by Tal Einat (Bjorn Andersson) in branch 'master':
bpo-31425: Expose AF_QIPCRTR in socket module (GH-3706)
https://github.com/python/cpython/commit/bb8165172ac2ef8c7092e8e82928cc7f5f310ab3


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31425>
_______________________________________

From report at bugs.python.org  Wed Sep 26 09:49:00 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 26 Sep 2018 13:49:00 +0000
Subject: [issue31425] Expose AF_QIPCRTR in socket module
In-Reply-To: <1505168549.75.0.537554946733.issue31425@psf.upfronthosting.co.za>
Message-ID: <1537969740.17.0.545547206417.issue31425@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31425>
_______________________________________

From report at bugs.python.org  Wed Sep 26 09:53:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 13:53:54 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537970034.14.0.545547206417.issue28655@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I confirm that "./python -I -S -m test.regrtest -j0 --fail-env-changed test_asyncio test_ctypes test_email test_idle test_import test_importlib test_json test_lib2to3" now pass on master. I close the issue.

Thanks Karthikeyan ;-)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:26:40 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 26 Sep 2018 14:26:40 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537972000.57.0.545547206417.issue34694@psf.upfronthosting.co.za>


Change by Paul Moore <p.f.moore at gmail.com>:


----------
nosy:  -paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:32:06 2018
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Celles?=)
Date: Wed, 26 Sep 2018 14:32:06 +0000
Subject: [issue34810] Maximum and minimum value of C types integers from Python
Message-ID: <1537972326.01.0.545547206417.issue34810@psf.upfronthosting.co.za>


New submission from S?bastien Celles <s.celles at gmail.com>:

Hello,

I'm looking for a way to get (using Python) the maximum and minimum values of C types integers (ie  uint8, int8, uint16, int16, uint32, int32, uint64, int64...) from Python.

I asked this question on StackOverflow and get a nice answer https://stackoverflow.com/questions/52475749/maximum-and-minimum-value-of-c-types-integers-from-python

but I wonder if this kind of feature couldn't be add directly in `ctypes.c_` as property.

Maybe we could have the following properties:
- `issigned`
- `max`
- `min`

Moreover being able to convert a number into a C type integer raising exception when input data is out of range could also be considered
Maybe using code like https://pastebin.com/cvm95m1x
(instead of silently overflow)

Kind regards

----------
messages: 326467
nosy: scls
priority: normal
severity: normal
status: open
title: Maximum and minimum value of C types integers from Python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34810>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:34:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 14:34:43 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537972483.5.0.545547206417.issue28655@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

test_import still fails on 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:37:22 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 26 Sep 2018 14:37:22 +0000
Subject: [issue34811] test_gdb fails with latest gdb
Message-ID: <1537972642.29.0.545547206417.issue34811@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

In Fedora we got a new build of gdb which makes python's test_gdb fail on x86_64, i686 and aarch64(arm 64 bits) architectures.

gdb's commits between the passing and failing tests:
https://github.com/bminor/binutils-gdb/compare/ab080c102869dd3ad300a99d0c00b256404fd76b...e08ef628a7e3098699ec6939584e2c9f7a9e1952

This is too big of a list, so here is the commits from gdb's python folder:

https://github.com/bminor/binutils-gdb/commits/master/gdb/python

The offensive commits should be between 89fbedf3abc90b62fbb7f08782ed78d87b3fccaa on Aug 18, 2018 and
94c8b7253a5e165ee92f7302f3247764d69b55e5 on Sep 16, 2018

Traceback to follow.

----------
components: Tests
messages: 326469
nosy: cstratak
priority: normal
severity: normal
status: open
title: test_gdb fails with latest gdb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34811>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:39:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 14:39:01 +0000
Subject: [issue34810] Maximum and minimum value of C types integers from Python
In-Reply-To: <1537972326.01.0.545547206417.issue34810@psf.upfronthosting.co.za>
Message-ID: <1537972741.5.0.545547206417.issue34810@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maximum values for uint8, int8, uint16, int16, uint32, int32, uint64, int64 are 2**8-1, 2**7-1, 2**16-1, 2**15-1, 2**32-1, 2**31-1, 2**64-1, 2**63-1 by definition. Minimum values are 0, -2**7, 0, -2**15, 0, -2**31, 0, -2**63.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34810>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:39:06 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 26 Sep 2018 14:39:06 +0000
Subject: [issue34811] test_gdb fails with latest gdb
In-Reply-To: <1537972642.29.0.545547206417.issue34811@psf.upfronthosting.co.za>
Message-ID: <1537972746.75.0.545547206417.issue34811@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34811>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:40:01 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 26 Sep 2018 14:40:01 +0000
Subject: [issue34811] test_gdb fails with latest gdb
In-Reply-To: <1537972642.29.0.545547206417.issue34811@psf.upfronthosting.co.za>
Message-ID: <1537972801.42.0.545547206417.issue34811@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 485, in test_NULL_ob_type
    'set v->ob_type=0')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 456, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 477, in test_NULL_ptr
    'backtrace'])
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_builtin_method (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 607, in test_builtin_method
    gdb_repr, gdb_output = self.get_gdb_repr('import sys; id(sys.stdout.readlines)')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 513, in test_builtins_help
    gdb_repr, gdb_output = self.get_gdb_repr('id(__builtins__.help)', import_site=True)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_bytes (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of bytes
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 301, in test_bytes
    self.assertGdbRepr(b'')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 491, in test_corrupt_ob_type
    exprepr='42')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 456, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 497, in test_corrupt_tp_flags
    exprepr='42')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 456, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 503, in test_corrupt_tp_name
    exprepr='42')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 456, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 289, in test_dicts
    self.assertGdbRepr({})
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_exceptions (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 387, in test_exceptions
    ''')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_frames (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 626, in test_frames
    'Unexpected gdb representation: %r\n%s' % (gdb_output, gdb_output))
AssertionError: None is not true : Unexpected gdb representation: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 373, in test_frozensets
    self.assertGdbRepr(frozenset(), "frozenset()")
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various int values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 275, in test_int
    self.assertGdbRepr(42)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 296, in test_lists
    self.assertGdbRepr([])
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 409, in test_modern_class
    id(foo)''')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 534, in test_selfreferential_dict
    self.get_gdb_repr("a = {} ; b = {'bar':a} ; a['foo'] = b ; id(a)")
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 523, in test_selfreferential_list
    self.get_gdb_repr("a = [3, 4, 5] ; a.append(a) ; id(a)")
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 558, in test_selfreferential_new_style_instance
    id(foo)''')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 545, in test_selfreferential_old_style_instance
    id(foo)''')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 355, in test_sets
    self.assertGdbRepr(set(), "set()")
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 283, in test_singletons
    self.assertGdbRepr(True)
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 325, in test_strings
    self.assertGdbRepr('')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 422, in test_subclassing_list
    id(foo)''')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 437, in test_subclassing_tuple
    id(foo)''')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 580, in test_truncation
    gdb_repr, gdb_output = self.get_gdb_repr('id(list(range(1000)))')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
======================================================================
FAIL: test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 347, in test_tuples
    self.assertGdbRepr(tuple(), '()')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 266, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 242, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
test test_gdb failed
======================================================================
FAIL: test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 690, in test_down_at_bottom
    'Unable to find a newer python frame\n')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 248, in assertEndsWith
    msg='%r did not end with %r' % (actual, exp_end))
AssertionError: False is not true : 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n' did not end with 'Unable to find a newer python frame\n'
======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 698, in test_up_at_top
    'Unable to find an older python frame\n')
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 248, in assertEndsWith
    msg='%r did not end with %r' % (actual, exp_end))
AssertionError: False is not true : 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n' did not end with 'Unable to find an older python frame\n'
======================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0/Lib/test/test_gdb.py", line 777, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n'
----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34811>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:42:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 14:42:10 +0000
Subject: [issue34811] test_gdb fails with latest gdb
In-Reply-To: <1537972642.29.0.545547206417.issue34811@psf.upfronthosting.co.za>
Message-ID: <1537972930.42.0.545547206417.issue34811@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34811>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:54:22 2018
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Celles?=)
Date: Wed, 26 Sep 2018 14:54:22 +0000
Subject: [issue34810] Maximum and minimum value of C types integers from Python
In-Reply-To: <1537972326.01.0.545547206417.issue34810@psf.upfronthosting.co.za>
Message-ID: <1537973662.11.0.545547206417.issue34810@psf.upfronthosting.co.za>


S?bastien Celles <s.celles at gmail.com> added the comment:

Thanks @serhiy.storchaka I'm aware of this... but I think it could be returned programmatically without much difficulty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34810>
_______________________________________

From report at bugs.python.org  Wed Sep 26 10:58:25 2018
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Celles?=)
Date: Wed, 26 Sep 2018 14:58:25 +0000
Subject: [issue34810] Maximum and minimum value of C types integers from Python
In-Reply-To: <1537972326.01.0.545547206417.issue34810@psf.upfronthosting.co.za>
Message-ID: <1537973905.3.0.545547206417.issue34810@psf.upfronthosting.co.za>


S?bastien Celles <s.celles at gmail.com> added the comment:

About raising exception with converting integer value that should overflow maybe we should have a parameter

    ctypes.c_uint8(256, raise=True)

will raise an exception but 

    ctypes.c_uint8(256)

will silently return c_ubyte(0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34810>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:02:26 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 15:02:26 +0000
Subject: [issue34811] test_gdb fails with latest gdb
In-Reply-To: <1537972642.29.0.545547206417.issue34811@psf.upfronthosting.co.za>
Message-ID: <1537974146.94.0.545547206417.issue34811@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34811>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:05:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 15:05:53 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537974353.14.0.545547206417.issue28655@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:05:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 15:05:53 +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: <1537974353.26.0.183324690243.issue33053@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8987

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:07:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 15:07:25 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537974445.0.0.545547206417.issue28655@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> test_import still fails on 3.6.

Oh, I only tested master. I wrote PR 9589 to fix test_import on 3.6.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:13:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 15:13:34 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537974814.04.0.545547206417.issue28655@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Serhiy. Thanks Victor for the fix. I can confirm this on 3.6. Interestingly `--fail-env-changed` flag didn't catch this but running in verbose mode failed.

`--fail-env-changed` passes

?  cpython git:(3707bcf02b) ./python.exe -I -S -m test.regrtest -j0 --fail-env-changed test_asyncio test_ctypes test_email test_idle test_import test_importlib test_json test_lib2to3
Run tests in parallel using 6 child processes
0:00:04 load avg: 3.51 [1/8] test_import passed
0:00:07 load avg: 3.51 [2/8] test_ctypes passed
0:00:09 load avg: 3.87 [3/8] test_idle passed
0:00:19 load avg: 6.23 [4/8] test_importlib passed
0:00:27 load avg: 6.05 [5/8] test_json passed
0:00:29 load avg: 5.72 [6/8] test_email passed
running: test_asyncio (59 sec 815 ms), test_lib2to3 (51 sec 972 ms)
0:01:06 load avg: 4.33 [7/8] test_asyncio passed (1 min 4 sec) -- running: test_lib2to3 (58 sec 276 ms)
0:01:09 load avg: 4.33 [8/8] test_lib2to3 passed (1 min 244 ms)

== Tests result: SUCCESS ==

All 8 tests OK.

# warnings are present

?  cpython git:(3707bcf02b) ./python.exe -I -S -m test.regrtest -vv test_import test_lib2to3 >/dev/null
Warning -- files was modified by test_import
  Before: []
  After:  ['@test_10093_tmp.pyc']

Total duration: 1 min 9 sec
Tests result: SUCCESS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:15:15 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 15:15:15 +0000
Subject: [issue28556] typing.py upgrades
In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za>
Message-ID: <1537974915.65.0.545547206417.issue28556@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8988

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28556>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:15:28 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Sep 2018 15:15:28 +0000
Subject: [issue28556] typing.py upgrades
In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za>
Message-ID: <1537974928.9.0.545547206417.issue28556@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8989

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28556>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:25:35 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 26 Sep 2018 15:25:35 +0000
Subject: [issue34765] Update install-sh
In-Reply-To: <1537544827.56.0.956365154283.issue34765@psf.upfronthosting.co.za>
Message-ID: <1537975535.71.0.545547206417.issue34765@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
keywords: +patch
pull_requests: +8990
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34765>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:26:44 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 15:26:44 +0000
Subject: [issue34262] Asyncio test fails under Win 7
In-Reply-To: <1532782721.54.0.56676864532.issue34262@psf.upfronthosting.co.za>
Message-ID: <1537975604.96.0.545547206417.issue34262@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

ProactorEventLoop is the default event loop with issue34687. There doesn't seem to be any warnings in buildbots as I have checked and as @panesen has mentioned this is not consistent. I am adding Victor as a notification if he has any thoughts. Victor, feel free to remove yourself if this is not relevant.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34262>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:27:04 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 15:27:04 +0000
Subject: [issue34262] Asyncio test fails under Win 7
In-Reply-To: <1532782721.54.0.56676864532.issue34262@psf.upfronthosting.co.za>
Message-ID: <1537975624.98.0.545547206417.issue34262@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34262>
_______________________________________

From report at bugs.python.org  Wed Sep 26 11:33:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 15:33:24 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537976004.3.0.545547206417.issue28655@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Verified the fix in the PR and there are no warnings

?  cpython git:(pr_9589) ./python.exe
Python 3.6.6+ (heads/pr_9589:844abda318, Sep 26 2018, 20:59:26)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
?  cpython git:(pr_9589) ./python.exe -I -S -m test.regrtest -vv test_import test_lib2to3 >/dev/null
?  cpython git:(pr_9589) ./python.exe -I -S -m test.regrtest -j0 --fail-env-changed test_asyncio test_ctypes test_email test_idle test_import test_importlib test_json test_lib2to3
Run tests in parallel using 6 child processes
0:00:06 load avg: 3.19 [1/8] test_import passed
0:00:10 load avg: 3.73 [2/8] test_ctypes passed
0:00:12 load avg: 3.73 [3/8] test_idle passed
0:00:20 load avg: 4.08 [4/8] test_importlib passed
0:00:27 load avg: 4.07 [5/8] test_json passed
0:00:29 load avg: 4.15 [6/8] test_email passed
running: test_asyncio (59 sec 700 ms), test_lib2to3 (49 sec 60 ms)
0:01:04 load avg: 3.97 [7/8] test_asyncio passed (1 min 2 sec) -- running: test_lib2to3 (54 sec 18 ms)
0:01:07 load avg: 3.97 [8/8] test_lib2to3 passed (55 sec 380 ms)

== Tests result: SUCCESS ==

All 8 tests OK.

Total duration: 1 min 7 sec
Tests result: SUCCESS


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:07:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:07:03 +0000
Subject: [issue34812] support.args_from_interpreter_flags() doesn't inherit -I
 (isolated) flag
Message-ID: <1537978023.88.0.545547206417.issue34812@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

The support.args_from_interpreter_flags() function recreates Python command line arguments from sys.flags, but it omits -I (sys.flags.isolated).

Because of that, "./python -I -m test ..." behaves differently than "./python -I -m test -j0 ...":
https://bugs.python.org/issue28655#msg326477

----------
components: Library (Lib), Tests
messages: 326478
nosy: vstinner
priority: normal
severity: normal
status: open
title: support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34812>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:07:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:07:24 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537978044.11.0.545547206417.issue28655@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I can confirm this on 3.6. Interestingly `--fail-env-changed` flag didn't catch this but running in verbose mode failed.

Oh... When using -j0, regrtest doesn't spawn worker processes using -I: the flag is simply omitted... As a side effect, forget() in test_import doesn't remove pyc_file from the current directory.

I created bpo-34812 to track this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:09:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:09:42 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1537978182.55.0.545547206417.issue28655@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 43500a5907eb9ae2e470dcbffe73012cd456f5a1 by Victor Stinner in branch '3.6':
bpo-28655: Fix test_import.test_missing_source_legacy() (GH-9589)
https://github.com/python/cpython/commit/43500a5907eb9ae2e470dcbffe73012cd456f5a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:09:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:09: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: <1537978182.69.0.668975606942.issue33053@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 43500a5907eb9ae2e470dcbffe73012cd456f5a1 by Victor Stinner in branch '3.6':
bpo-28655: Fix test_import.test_missing_source_legacy() (GH-9589)
https://github.com/python/cpython/commit/43500a5907eb9ae2e470dcbffe73012cd456f5a1


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33053>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:10:02 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 16:10:02 +0000
Subject: [issue34812] support.args_from_interpreter_flags() doesn't inherit -I
 (isolated) flag
In-Reply-To: <1537978023.88.0.545547206417.issue34812@psf.upfronthosting.co.za>
Message-ID: <1537978202.84.0.545547206417.issue34812@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34812>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:22:59 2018
From: report at bugs.python.org (calimeroteknik)
Date: Wed, 26 Sep 2018 16:22:59 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537978979.84.0.545547206417.issue34781@psf.upfronthosting.co.za>


calimeroteknik <calimeroteknik at free.fr> added the comment:

A friend has found a very simple example that triggers such an issue in a very reproducible manner.

Attached two versions, one where the child process mysteriously disappears in the cpython interpreter.

pypy is unaffected.

----------
nosy: +calimeroteknik
Added file: https://bugs.python.org/file47827/hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:27:06 2018
From: report at bugs.python.org (calimeroteknik)
Date: Wed, 26 Sep 2018 16:27:06 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537979226.72.0.545547206417.issue34781@psf.upfronthosting.co.za>


calimeroteknik <calimeroteknik at free.fr> added the comment:

Attaching the version that randomly raises ChildProcessError: [Errno 10] No child processes.
The child process is lost in limbo if we don't sleep/print after creating it.

----------
Added file: https://bugs.python.org/file47828/except-out.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:30:05 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 16:30:05 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537979405.93.0.545547206417.issue34781@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

@calimeroteknik, this doesn't seem to have anything to do with the issue at hand.  Please open a separate issue with your scripts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:30:14 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 16:30:14 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537979414.73.0.545547206417.issue34781@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


Removed file: https://bugs.python.org/file47828/except-out.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:30:16 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 16:30:16 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537979416.26.0.545547206417.issue34781@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


Removed file: https://bugs.python.org/file47827/hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:42:21 2018
From: report at bugs.python.org (calimeroteknik)
Date: Wed, 26 Sep 2018 16:42:21 +0000
Subject: [issue34813] child process disappears when removing a print statement
 after its creation
Message-ID: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>


New submission from calimeroteknik <calimeroteknik at free.fr>:

When two processes are created and killed, the behaviour is different if print or sleep statements are inserted.
It can also be random (different results executing the same program several times) on certain machines and versions of python.

Attached two versions, one where the child process mysteriously disappears in the cpython interpreter, and another other one that raises ChildProcessError: [Errno 10] No child processes.

This shows up with cpython, all versions I tested (3.7, 3.6, 3.5, 2.7). pypy is unaffected.

----------
files: hang.py
messages: 326485
nosy: calimeroteknik, davin, pitrou
priority: normal
severity: normal
status: open
title: child process disappears when removing a print statement after its creation
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47829/hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34813>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:43:09 2018
From: report at bugs.python.org (calimeroteknik)
Date: Wed, 26 Sep 2018 16:43:09 +0000
Subject: [issue34813] child process disappears when removing a print statement
 after its creation
In-Reply-To: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>
Message-ID: <1537980189.08.0.545547206417.issue34813@psf.upfronthosting.co.za>


Change by calimeroteknik <calimeroteknik at free.fr>:


Added file: https://bugs.python.org/file47830/except-out.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34813>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:55:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:55:34 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
Message-ID: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Python can be compiled in "shared" mode: "./configure --enable-shared", Py_ENABLE_SHARED is defined in pyconfig.h. Most Linux distributions use this configuration.

By default, Python builds most C extensions using setup.py which is based on distutils. The get_libraries() method of Lib/distutils/command/build_ext.py explicity add a dependency to libpythonX.Y if Py_ENABLE_SHARED is defined.

But it is possible to use Modules/Setup to build some C extensions using Makefile rather than setup.py. If "*shared*" is in Modules/Setup, following modules will be compiled as libraries (".so" files on Linux). For example, RHEL and Fedora use this configuration for many C extensions. Problem: C extensions compiled like are not linked to libpython.


Example of the issue on Fedora 28 with Python 2.7:

$ ldd $(python2 -c 'import _struct; print(_struct.__file__)')
	linux-vdso.so.1 (0x00007ffeedf38000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb4da876000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fb4da4b7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb4daca1000)

=> notice the lack of libpython

Python 3.6 is fine:

$ ldd $(python3 -c 'import _struct; print(_struct.__file__)')
	linux-vdso.so.1 (0x00007ffd493dd000)
	libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007f47b9160000)
	...


Patch used by Fedora to build _struct (and other modules) using Makefile:

https://src.fedoraproject.org/rpms/python2/blob/f27/f/python-2.7.1-config.patch



Another example of patch, to build _contextvars as a shared library:

diff --git a/Modules/Setup b/Modules/Setup
index a0622cc8c6..975aeff70d 100644
--- a/Modules/Setup
+++ b/Modules/Setup
@@ -148,7 +148,7 @@ _symtable symtablemodule.c
 # modules are to be built as shared libraries (see above for more
 # detail; also note that *static* or *disabled* cancels this effect):
 
-#*shared*
+*shared*
 
 # GNU readline.  Unlike previous Python incarnations, GNU readline is
 # now incorporated in an optional module, configured in the Setup file
@@ -166,7 +166,7 @@ _symtable symtablemodule.c
 #array arraymodule.c   # array objects
 #cmath cmathmodule.c _math.c # -lm # complex math library functions
 #math mathmodule.c _math.c # -lm # math library functions, e.g. sin()
-#_contextvars _contextvarsmodule.c  # Context Variables
+_contextvars _contextvarsmodule.c  # Context Variables
 #_struct _struct.c     # binary structure packing/unpacking
 #_weakref _weakref.c   # basic weak reference support
 #_testcapi _testcapimodule.c    # Python C API test module


Attached PR fixes Modules/makesetup to:

* (1) Add a dependency on the Makefile target to libpython: to make sure that the parallel compilation works as expected
* (2) Add a dependency to libpythonX.Y on the compiled shared library (".so" file on Linux)

----------
components: Build
messages: 326486
nosy: vstinner
priority: normal
severity: normal
status: open
title: makesetup: must link C extensions to libpython when compiled in shared mode
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 12:58:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:58:17 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537981097.4.0.545547206417.issue34814@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8991
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:00:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 17:00:56 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537981256.89.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Setup.patch: Example of patch to modify Modules/Setup to compile _contextvars as a shared library, to test the fix.

----------
Added file: https://bugs.python.org/file47831/Setup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:01:17 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 17:01:17 +0000
Subject: [issue34813] child process disappears when removing a print statement
 after its creation
In-Reply-To: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>
Message-ID: <1537981277.88.0.545547206417.issue34813@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think hang.py is correct.  If you launch a process using subprocess, the subprocess owns the child process.  You should not call waitpid() or os.kill() separately.  Also, since you don't keep a reference to the subprocess.Popen object, its destructor will run and may call waitpid() on the child process.  Depending on when exactly the destructor runs, it can interfere with your own waitpid() call.

----------
nosy: +giampaolo.rodola, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34813>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:01:55 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 17:01:55 +0000
Subject: [issue34813] child process disappears when removing a print statement
 after its creation
In-Reply-To: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>
Message-ID: <1537981315.25.0.545547206417.issue34813@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Those remarks apply to except-out.py, as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34813>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:10:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 17:10:04 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537981804.63.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Example of the bug:

---
$ git apply ~/Setup.patch
$ ./configure --with-pydebug --enable-shared
$ make
$ grep _contextvars Makefile
(...)

Modules/_contextvarsmodule.o: $(srcdir)/Modules/_contextvarsmodule.c; $(CC) $(CCSHARED) $(PY_CFLAGS) $(PY_CPPFLAGS)  -c $(srcdir)/Modules/_contextvarsmodule.c -o Modules/_contextvarsmodule.o

Modules/_contextvars$(EXT_SUFFIX):  Modules/_contextvarsmodule.o; $(BLDSHARED)  Modules/_contextvarsmodule.o   -o Modules/_contextvars$(EXT_SUFFIX)

$ find -name "_contextvars.*so"
./Modules/_contextvars.cpython-38dm-x86_64-linux-gnu.so

$ ldd $(find -name "_contextvars.*so")
	linux-vdso.so.1 (0x00007ffd27973000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd081433000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fd081074000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd081854000)
---

The _contextvars shared library is not linked to libpython. There is not "-lpythonX.Y" in the Makefile rule.


Now with the patch:
---
$ git clean -fdx
$ git apply ~/Setup.patch
$ ./configure --with-pydebug --enable-shared
$ make
$ grep _contextvars Makefile
(...)

Modules/_contextvarsmodule.o: $(srcdir)/Modules/_contextvarsmodule.c; $(CC) $(CCSHARED) $(PY_CFLAGS) $(PY_CPPFLAGS)  -c $(srcdir)/Modules/_contextvarsmodule.c -o Modules/_contextvarsmodule.o

Modules/_contextvars$(EXT_SUFFIX):  Modules/_contextvarsmodule.o $(LDLIBRARY); $(BLDSHARED)  Modules/_contextvarsmodule.o $(BLDLIBRARY)   -o Modules/_contextvars$(EXT_SUFFIX)

$ find -name "_contextvars.*so"
./Modules/_contextvars.cpython-38dm-x86_64-linux-gnu.so

$ ldd $(find -name "_contextvars.*so")
	linux-vdso.so.1 (0x00007ffd1e918000)
	libpython3.8dm.so.1.0 => not found
        (...)
---

With my patch, _contextvars.cpython-38dm-x86_64-linux-gnu.so is linked to libpython3.8dm.so.1.0 as expected. The Makefile rule adds  $(LDLIBRARY) to the dependencies of the _contextvars(...).so rule and it adds $(BLDLIBRARY) to the linker flags of this rule.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:10:25 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 17:10:25 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537981825.29.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Downstream (RHEL) issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1585201

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:13:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 17:13:10 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537981990.9.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I copied the nosy list from bpo-32430: people who understand and care about the Modules/Setup file :-)

----------
nosy: +barry, eric.smith, koobs, martin.panter, mdk, nascheme, pitrou, twouters, xdegaye, yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:13:17 2018
From: report at bugs.python.org (calimeroteknik)
Date: Wed, 26 Sep 2018 17:13:17 +0000
Subject: [issue34813] child process disappears when removing a print statement
 after its creation
In-Reply-To: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>
Message-ID: <1537981997.95.0.545547206417.issue34813@psf.upfronthosting.co.za>


calimeroteknik <calimeroteknik at free.fr> added the comment:

So this is invalid library usage, we need to run .wait() on the Popen object.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34813>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:21:54 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 17:21:54 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537982514.41.0.545547206417.issue34814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why do you call this a bug?
For me it's the reverse: it's linking to libpython.so which is a bug.  It means a C extension compiled with a shared-library Python cannot be imported on a monolithic Python (which doesn't have libpython.so).  It's a real problem when you want to redistribute compiled C extensions: if you compile it on RedHat/CentOS, it won't work on Ubuntu/Debian (the reverse works).

I even opened an issue about that: issue21536
("extension built with a shared python cannot be loaded with a static python")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:23:16 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 17:23:16 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537982596.74.0.545547206417.issue34814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Of course, one workaround to satisfy everyone would be to build a (empty) libpython.so even on static Python builds.  But I'm not sure Debian/Ubuntu would package it.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 13:24:18 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Sep 2018 17:24:18 +0000
Subject: [issue34813] child process disappears when removing a print statement
 after its creation
In-Reply-To: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>
Message-ID: <1537982658.95.0.545547206417.issue34813@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34813>
_______________________________________

From report at bugs.python.org  Wed Sep 26 14:03:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 18:03:15 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537984995.76.0.545547206417.issue31405@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 14:12:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 18:12:28 +0000
Subject: [issue31551] test_distutils fails if current directory contains spaces
In-Reply-To: <1506076771.77.0.41123566285.issue31551@psf.upfronthosting.co.za>
Message-ID: <1537985548.37.0.545547206417.issue31551@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31551>
_______________________________________

From report at bugs.python.org  Wed Sep 26 14:19:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Sep 2018 18:19:13 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537985953.57.0.545547206417.issue31405@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am adding windows as a component during triaging since PATHEXT seems to be windows specific. Unfortunately, I couldn't verify this since I don't have windows system to check this against master so leaving it to 3.6.

Thanks

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 15:10:55 2018
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 26 Sep 2018 19:10:55 +0000
Subject: [issue34694] Dismiss To Avoid Slave/Master wording cause it easier
 for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537989055.59.0.545547206417.issue34694@psf.upfronthosting.co.za>


Change by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy:  -mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34694>
_______________________________________

From report at bugs.python.org  Wed Sep 26 15:24:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 19:24:06 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537989846.69.0.545547206417.issue31405@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Isn't this an expected behavior?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 15:26:50 2018
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBCb3VkYQ==?=)
Date: Wed, 26 Sep 2018 19:26:50 +0000
Subject: [issue34781] infinite waiting in multiprocessing.Pool
In-Reply-To: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>
Message-ID: <1537990010.33.0.545547206417.issue34781@psf.upfronthosting.co.za>


Tom?? Bouda <tomas.bouda at gmail.com> added the comment:

By now I have spent several days trying to reproduce the behaviour in production environment with debugger attached. Unfortunately, no success. On the other hand yesterday the application froze, again, and colleague today experienced the problem in his script, too. (talking about RHEL)

Dealing with this kind of problem is always very frustrating.

By now, I agree with @pitrou that OSX/RHEL could be two different problems. In advance, I tried the approach by @calimeroteknik and this would actually make sense.

If the child process receives a signal (SIGTERM or SIGSEGV), parent waits forever. We do call 3rd party libraries and segfault is indeed possible. I've tried to send signal to a child and script really froze. By now, it seems to be the most probable explanation.

OSX debugger may also be buggy, yesterday I completely broke my system just by trying my original script, leading to a regular segfaults and system restart (never happened before).

Since I can't reproduce the problem under controlled conditions, I am ok with closing this bug. The script by @calimeroteknik seems to be pointing in the same direction and I think this may solve our problem, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34781>
_______________________________________

From report at bugs.python.org  Wed Sep 26 15:50:57 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 26 Sep 2018 19:50:57 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537991457.18.0.545547206417.issue31405@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

I don't think this is expected behaviour. It's not documented what should happen in this case but the behaviour suggested by the OP (to search for the path as given, followed by [path+e for e in os.environ['PATHEXT'].split(os.pathsep)] seems reasonable to me.

The details and corner cases need thrashing out, which I don't have time to do right now, but the principle seems sound.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 15:53:20 2018
From: report at bugs.python.org (Eli Schwartz)
Date: Wed, 26 Sep 2018 19:53:20 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1537991600.03.0.545547206417.issue34022@psf.upfronthosting.co.za>


Change by Eli Schwartz <eschwartz93 at gmail.com>:


----------
nosy: +eschwartz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Wed Sep 26 15:56:21 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 26 Sep 2018 19:56:21 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537991781.58.0.545547206417.issue31405@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

On further reflection, I'm less sure that the proposed behaviour is the best option, but I do think this warrants further consideration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:12:46 2018
From: report at bugs.python.org (Ryan McCampbell)
Date: Wed, 26 Sep 2018 20:12:46 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537992766.02.0.545547206417.issue31405@psf.upfronthosting.co.za>


Ryan McCampbell <rmccampbell7 at gmail.com> added the comment:

This is how windows looks up commands, as well as the built in "where" command. (Note that windows doesn't actually distinguish between "executable" files and just plain old files, so this could be confusing for UNIX users... a text file for instance will simply open in the default text editor when "executed" by the shell.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:32:48 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 26 Sep 2018 20:32:48 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1537993968.82.0.545547206417.issue2771@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Also a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:41:56 2018
From: report at bugs.python.org (Frank Schaefer)
Date: Wed, 26 Sep 2018 20:41:56 +0000
Subject: [issue34771] test_ctypes failing on Linux SPARC64
In-Reply-To: <1537638972.94.0.956365154283.issue34771@psf.upfronthosting.co.za>
Message-ID: <1537994516.87.0.545547206417.issue34771@psf.upfronthosting.co.za>


Frank Schaefer <kelledin at gmail.com> added the comment:

Further details:

I cloned libffi from a few days ago to see if I had any different behavior.  So far the test fails the same way with the updated libffi.

I'll also see about contacting libffi upstream and see what they can suggest here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34771>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:43:33 2018
From: report at bugs.python.org (Tim Peters)
Date: Wed, 26 Sep 2018 20:43:33 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537994613.33.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

High-order bit:  please restore the original tuple hash test.  You have the worst case of "but I didn't write it" I've ever encountered ;-)  Your new test is valuable, but I've seen several cases now where it fails to detect any problems where the original test fails catastrophically.  Tests are written to ensure known problems don't recur, so there's _never_ "a reason" to throw one away unless the test itself is in error.  The test suite only grows over time, and that's how it should be.

Example:  when I replace the computational guts of the tuple hash with the single line (64-bit build, and this is the only code remaining in the loop apart from setting y to the next tuple component's hash):

    x = (x * mult) + y;

both tests fail spectacularly.

But if I add one more line:

    x = (x * mult) + y;
    x += x >> 16;
    
your new test falls to 0 collisions, while the original test still suffers 83447 collisions (an improvement - down from 120050 - but still a spectacular failure).

We're flying blind enough here without deliberately plucking out one of our eyes ;-)  Indeed, the original tuple test is the only one in my collection that showed even a single collision after the two-line replacement just above.  "My collection" means your test, the original tuple hash test, and every example given in all the messages in this bug report.

Another "surprise":  replace addition with xor in the second line above:

    x = (x * mult) + y;
    x ^= x >> 16;

and then the original tuple test drops from 83447 to 0(!) collisions, while your new one jumps from 0 to a measly 12.


> The collision hash((3,3)) == hash((-3,-3)) is due a specific
> structure in the input to the FNV algorithm.

This is all so hypothetical it's impossible to know.  Perhaps the tuple hash function simply subtracts the hash of the first component from the hash of the second.  Then it's impossible to make any deterministic change to the component hashes that can stop either of the tuples from hashing to 0.  The weakness is entirely in the hash combining function then.

> The operation t ^= t << 7 that you suggested (and which I approve, except
> for the shift amount) is meant precisely to destroy that structure.

Except I have no reason to believe that destroying the input structure is of unique value.  As shown above, it's easy to change the tuple hash in a simple way that passes all known tests without touching `y` (aka `t`) at all.

>> It's x you care about directly, not t.

> That would not be a good solution, because that destroys the structure
> of the hash algorithm.   For Bernstein for example, each loop iteration
> should do something like
>
>    x = (x * m) + t
>
> for *some* value t depending on the input. If you mess with x, then it
> really becomes a different hash algorithm.

The two-liner above with the xor in the second line is exactly Bernstein 33A, followed by a permutation of 33A's _output_ space.  It works fine in tests.  Why should I care about merely that it's "different"?  33A on its own fails spectacularly - it damned well _better_ be "different" ;-)

There is no "Bernstein theory" to appeal to here - just raw assertions.  I'm not attached to any of these approaches.  The strongest I can say from trying many things is that "chaining permutations works best, but no detail appears to matter much, except that multiplication is the most valuable of all the permutations I've tried".

x*M is a permutation of the word-size space for any odd M, and any "big enough" odd M I tried appears to work about as well as any other.  Adding t is another.  The shift-xor in the second line above is a third (but the "+=" version instead was not a permutation, and it failed).

> That is far more dangerous than simply applying a permutation on t.

Why?

> Which "desirable properties" of t does the operation t ^= (t << 1) damage?

On second thought, none!  Across any contiguous range of integers, that preserves that the last k bits (for all k >= 1) remain as evenly distributed as in the inputs.  That wasn't obvious to me at first.  It's not true if the left shift is replaced by a right shift, though.

However, with a shift count of 1 I've generally found that the _original_ tuple hash test fails (not spectacularly, but fails all the same).  "Generally" means across a substantial number of varying the permutations used in other places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:48:57 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Sep 2018 20:48:57 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1537994937.82.0.545547206417.issue31405@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

It certainly doesn't match "which" semantics, but given the F_OK and X_OK flags I can see cases where it ought not to. I'm not sure it does what it implies for those either though.

I can see uses for "find files according to 'which'" and "find executable files according to 'which'".

Either way, I don't see an easy way to change the semantics any earlier than 3.8, so changing the target.

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:50:15 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 26 Sep 2018 20:50:15 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537995015.04.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Do you believe any other multiplier would work better toward that end?

Absolutely. Ideally, the multiplier should just be a random 64-bit number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:52:48 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 26 Sep 2018 20:52:48 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537995168.85.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> please restore the original tuple hash test.

Sure. I wasn't sure what to do and was I afraid that having 2 tests for tuple hashes would be too much. If that's OK for you, then surely I will restore the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Wed Sep 26 16:52:50 2018
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 26 Sep 2018 20:52:50 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1537995170.72.0.545547206417.issue34814@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> Downstream (RHEL) issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=1585201

Not sure that this is a bug. As Petr Viktorin points out in Comment #4, the reproducer is not expected to work because of the semantics of RTLD_LOCAL.

So the current bpo issue would be related only to a slight inconsistency between the build of extension modules by distutils and those built by the Makefile.

However, it seems that the loader of Android requires that those libraries be explicitly linked against libpython:

* The last paragraph on https://github.com/termux/termux-packages and the related termux issue "Shared library symbols not visible on dlopen()?" (at https://github.com/android-ndk/ndk/issues/201) explain this point.

* The issue I have submitted to pyephem "android cross-build needs the extension module to be linked against the math library" at https://github.com/brandon-rhodes/pyephem/issues/114 confirms this point on Android API level 21.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Wed Sep 26 17:06:05 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 26 Sep 2018 21:06:05 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537995965.13.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> The two-liner above with the xor in the second line is exactly Bernstein 33A, followed by a permutation of 33A's _output_ space.

Not output space, but internal state (I assume that you do that operation inside the loop). It's replacing DJBX33A by a different algorithm which is not DJBX33A. It may or may not work, that's not my point. It's just that I would avoid changing the structure of the algorithm if there is no reason to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Wed Sep 26 17:07:37 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 26 Sep 2018 21:07:37 +0000
Subject: [issue34521] test_socket.RecvmsgIntoSCMRightsStreamTest fails on
 AMD64 FreeBSD CURRENT Debug 3.x
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1537996057.18.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8992
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Wed Sep 26 17:14:34 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 26 Sep 2018 21:14:34 +0000
Subject: [issue31425] Expose AF_QIPCRTR in socket module
In-Reply-To: <1505168549.75.0.537554946733.issue31425@psf.upfronthosting.co.za>
Message-ID: <1537996474.0.0.545547206417.issue31425@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8993

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31425>
_______________________________________

From report at bugs.python.org  Wed Sep 26 17:20:42 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 26 Sep 2018 21:20:42 +0000
Subject: [issue31425] Expose AF_QIPCRTR in socket module
In-Reply-To: <1505168549.75.0.537554946733.issue31425@psf.upfronthosting.co.za>
Message-ID: <1537996842.86.0.545547206417.issue31425@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset f55c64c632af438d0daa043acdd95a5e74f31441 by Tal Einat in branch 'master':
bpo-31425: fix versionadded in docs and add attribution in NEWS (GH-9595)
https://github.com/python/cpython/commit/f55c64c632af438d0daa043acdd95a5e74f31441


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31425>
_______________________________________

From report at bugs.python.org  Wed Sep 26 17:23:15 2018
From: report at bugs.python.org (Tim Peters)
Date: Wed, 26 Sep 2018 21:23:15 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1537996995.11.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

>> The two-liner above with the xor in the second line is
>> exactly Bernstein 33A, followed by a permutation
>> of 33A's _output_ space.

> Not output space, but internal state

?  33A's output _is_ its internal state at the end.  This is a distinction that makes no difference.  I do distinguish here between 33A and the output of Python's `tuplehash()`, but the output space of both on a 64-bit box is a 64-bit int, so that's another pointless distinction to me.

> (I assume that you do that operation inside the loop).

Yes, as I said at the start, "this is the only code remaining in the loop apart from setting y to the next tuple component's hash".

> It's replacing DJBX33A by a different algorithm which is not
> DJBX33A.

Replacing DJBX33A's multiplier of 33 is also a different algorithm.  So is working with inputs other than unsigned bytes.  So is mucking with the inputs before adding them in.

> It may or may not work, that's not my point. It's just that
> I would avoid changing the structure of the algorithm if
> there is no reason to.

Which is also fine by me, except I see no actual reason to care.  All variations of "chain permutations" I've tried appear to work fine, except for those (which I haven't mentioned at all) that tried replacing multiplication with "weaker" permutations.

A minor exception is that, as already mentioned, applying the "leftshift-xor" permutation to the inputs with a shift count of 1 didn't pass the original tuple hash test in several cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Wed Sep 26 17:50:14 2018
From: report at bugs.python.org (Helena Centanin)
Date: Wed, 26 Sep 2018 21:50:14 +0000
Subject: [issue34691] _contextvars missing in xmaster branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1537998614.61.0.545547206417.issue34691@psf.upfronthosting.co.za>


Helena Centanin <helenamarycentanin2016 at gmail.com> added the comment:

Good night I installed the python program at the start it appears this message
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:06:47) [MSC v.1914 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>>

----------
components: +Installation -Build, Library (Lib), Windows
nosy: +helena.marina
title: _contextvars missing in x64 master branch Windows build? -> _contextvars missing in xmaster branch Windows build?
versions: +Python 3.7 -Python 3.8
Added file: https://bugs.python.org/file47832/Captura de Tela (12).png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Wed Sep 26 18:18:08 2018
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 26 Sep 2018 22:18:08 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1538000288.63.0.545547206417.issue31405@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

In a patch review [1] for issue 24505, I had a discussion with Toby Tobkin about extending the behavior of shutil.which() on Windows. This was to match the behavior of the CMD shell, including securing the search path via NeedCurrentDirectoryForExePath, searching for the exact filename, and implementing a real execute-access check. 

CMD won't directly execute a file that lacks execute access -- even a script or data file. We can implement this with a real implementation of os.access() that checks file security, for which there's an existing issue. (My previous suggestion to use CreateProcess and AssocQueryString to check for execute access was over the top. At the time I was thinking about building out support for a high-level shutil.execute, but it's out of scope here.)

Note that CMD will only try to execute an extensionless file if "." is in PATHEXT. (In the Windows file namespace, "name" and "name." are equivalent.) This obviously works for PE binaries, but we can also define an association for "." in the registy, which is useful for extensionless script files. Just associate "." files with a launcher that tries CreateProcess and falls back on a shebang line.

[1]: https://web.archive.org/web/20170619131224/http://bugs.python.org:80/review/24505/diff/16179/Lib/shutil.py

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Sep 26 20:00:28 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 27 Sep 2018 00:00:28 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538006428.06.0.545547206417.issue34370@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset adf493227f1efd5d6b34f46b854142bf3b5a411c by Ned Deily in branch '3.6':
bpo-34370: Update Tk 8.6 used with macOS installers
https://github.com/python/cpython/commit/adf493227f1efd5d6b34f46b854142bf3b5a411c


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Wed Sep 26 20:12:57 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 27 Sep 2018 00:12:57 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538007177.88.0.545547206417.issue34370@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset d9cfe5ed2c2c61eeae915b76f5e10aadbbb28da6 by Ned Deily in branch '3.7':
bpo-34370: Update Tk 8.6 used with macOS installers
https://github.com/python/cpython/commit/d9cfe5ed2c2c61eeae915b76f5e10aadbbb28da6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Wed Sep 26 22:31:50 2018
From: report at bugs.python.org (Ned Deily)
Date: Thu, 27 Sep 2018 02:31:50 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538015510.14.0.545547206417.issue34370@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

FYI, for the python.org binary macOS installers for the 3.7.1rc1 and 3.6.7rc1 releases, I cherry-picked a post-8.6.8 development snapshot of Tk 8.6 that should include Kevin's fix.  I would appreciate any feedback one way or the other whether this version of Tk 8.6 improves things over the vanilla 8.6.8 version used for the 3.7.0 and 3.6.6 releases.  Thanks!

----------
nosy: +rhettinger
resolution:  -> third party
stage:  -> commit review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Wed Sep 26 22:46:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 02:46:58 +0000
Subject: [issue31551] test_distutils fails if current directory contains spaces
In-Reply-To: <1506076771.77.0.41123566285.issue31551@psf.upfronthosting.co.za>
Message-ID: <1538016418.91.0.545547206417.issue31551@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There is a similar issue with whitespace in filenames causing failure in bdist_rpm tracked at issue809163. It has test cases but unfortunately the issue didn't move forward and has only patches. I tried the patches but none of them seem to fix the issue here. The issue seems to be in spec file generation with space in path of python executable. Did some debugging and my analysis as follows. Renamed my source directory 'cpython' as 'cpy thon' and made a clean build. It seems that sys.executable returns '/home/karthi/cpy thon/python' which is used as the python binary for the commands and hence with normal string concatenation the spec file generated [0] . I tried very basic fix of sys.executable.replace(' ', '\ ') to be used as a path. It generates the correct spec file [1] which passes and ./python -m test -vuall test_distutils also passes.

I am not sure if Python has a function to escape spaces for shell commands which would be more reliable. I tried shlex.quote but it handles only ' and ". I think having space in the directory might cause issues in places where we use string concatenation with sys.executable without taking spaces into account like the other issue with windows. I will try running the test suite sometime with space.

[0] With spaces. The commands that fail are /home/karthi/cpy thon/python setup.py build and /home/karthi/cpy thon/python setup.py install -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES

%define name foo
%define version 0.1
%define unmangled_version 0.1
%define release 1

Summary: UNKNOWN
Name: %{name}
Version: %{version}
Release: %{release}
Source0: %{name}-%{unmangled_version}.tar.gz
License: UNKNOWN
Group: Development/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
Prefix: %{_prefix}
BuildArch: noarch
Vendor: xxx <xxx>
Url: xxx

%description
UNKNOWN

%prep
%setup -n %{name}-%{unmangled_version}

%build
/home/karthi/cpy thon/python setup.py build

%install
/home/karthi/cpy thon/python setup.py install -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)


[1] sys.executable.replace(' ', '\ ') and the tests pass


%define name foo
%define version 0.1
%define unmangled_version 0.1
%define release 1

Summary: UNKNOWN
Name: %{name}
Version: %{version}
Release: %{release}
Source0: %{name}-%{unmangled_version}.tar.gz
License: UNKNOWN
Group: Development/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
Prefix: %{_prefix}
BuildArch: noarch
Vendor: xxx <xxx>
Url: xxx

%description
UNKNOWN

%prep
%setup -n %{name}-%{unmangled_version}

%build
/home/karthi/cpy\ thon/python setup.py build

%install
/home/karthi/cpy\ thon/python setup.py install -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)


I am adding 3.8 also as a target as part of triaging this issue.

Thanks

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31551>
_______________________________________

From report at bugs.python.org  Wed Sep 26 23:26:29 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 27 Sep 2018 03:26:29 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1538018789.48.0.545547206417.issue34744@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

The preferred way of adding new features to the Formatter is to subclass it, and modify one or more methods.  That's what the existing alternative formatters do.

A user can easily create such a subclass, and use it with their own parser, without having to modify the stock `argparse.py` file.

Given that flexibility, adding new features (as opposed to bug fixes) to the help formatter should have a low priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Wed Sep 26 23:35:49 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 27 Sep 2018 03:35:49 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
In-Reply-To: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>
Message-ID: <1538019349.73.0.545547206417.issue34803@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

The `type` parameter is normally a function (or more generally a callable).  When given a string it should convert it as needed, or raise an error.  In your example that function is the stock, 'int()'.

Test `int('123')`, `int('1e3')` etc for yourself to see what it can handle.

If you want to convert '1e3' to an integer, write your own function that handle it.  Don't expect argparse or the stock int() to do it for you.

More commonly people use 'type=bool', expecting it convert 'True' or 'False' strings to boolean values.  But that's not what the bool() function does.

To reiterate, 'type' is a function, not a desired class.

Since this is not a bug, I think this should be closed.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Thu Sep 27 01:41:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 05:41:41 +0000
Subject: [issue34806] distutils tests fail with recent 3.7 branch
In-Reply-To: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>
Message-ID: <1538026901.39.0.545547206417.issue34806@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@doko As an update 3.7.1rc1 is available . The fixes should be there. I think they are worth checking out to see if the cases still fail or if you can add the links for the branches 20180925 and 20180911 snapshot. I can do a clean rebuild of these branches to test them.

3.7.rc1 announcement : https://mail.python.org/pipermail/python-dev/2018-September/155329.html

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34806>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:11:36 2018
From: report at bugs.python.org (tom.r)
Date: Thu, 27 Sep 2018 06:11:36 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
Message-ID: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>


New submission from tom.r <tom.p.reichel at gmail.com>:

Added ellipsis_str function to Objects/sliceobject.c such that str(Ellipsis)=='...'.

----------
components: Interpreter Core
files: sliceobject.c
messages: 326522
nosy: photofone
priority: normal
severity: normal
status: open
title: Change Py_Ellipse __str__ behavior.
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file47833/sliceobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:14:28 2018
From: report at bugs.python.org (tom.r)
Date: Thu, 27 Sep 2018 06:14:28 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538028868.97.0.545547206417.issue34815@psf.upfronthosting.co.za>


Change by tom.r <tom.p.reichel at gmail.com>:


----------
keywords: +patch
pull_requests: +8994
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:15:44 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 27 Sep 2018 06:15:44 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1538028944.48.0.545547206417.issue32956@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

FWIW, I hadn't noticed this change in py3, but it would never have occurred to me that it's controversial... I thought everyone who'd studied the issue agreed that round-half-to-even was the best default :-). Numpy has always done round-to-even, and it's the default rounding mode mandated by IEEE754. (This doesn't mean that they mandate that round() itself follow this rule, but the implicit rounding that all floating point operations do has to follow this rule.) See also: https://en.wikipedia.org/wiki/Rounding#Round_half_to_even

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:18:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 06:18:17 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538029097.65.0.545547206417.issue34815@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:22:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 06:22:46 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538029366.85.0.545547206417.issue34815@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:23:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 06:23:59 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538029439.52.0.545547206417.issue34815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the rationale of this change?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:45:58 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 06:45:58 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538030758.23.0.545547206417.issue34815@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the PR but this seems to be backwards incompatible though I don't know if anyone depends on this and I am curious about the reason to change. Since this was added in e449af7da94 (1996) and I am not sure if this needs to be changed though it's up to Guido to take a call. There seems to be no tests for this in test suite that catches this change too.

$ python2.7
Python 2.7.14 (default, Mar 12 2018, 13:54:56)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str(Ellipsis)
'Ellipsis'
>>> repr(Ellipsis)
'Ellipsis'

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:47:55 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 27 Sep 2018 06:47:55 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1538030875.13.0.545547206417.issue34512@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:55:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 06:55:41 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1538031341.31.0.545547206417.issue34512@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Thu Sep 27 02:55:57 2018
From: report at bugs.python.org (tom.r)
Date: Thu, 27 Sep 2018 06:55:57 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538031357.0.0.545547206417.issue34815@psf.upfronthosting.co.za>


tom.r <tom.p.reichel at gmail.com> added the comment:

Frankly, because it bothered me that ``...`` evaluates to ``Ellipsis`` but that ``Ellipsis`` could never print as ``...``.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 03:06:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 07:06:47 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538032007.6.0.545547206417.issue34815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Are you aware that changing just __str__ will not change the result of repr(), so that nested Ellipsis and Ellipsis in REPL will be still represented by name?

>>> print(...)
...
>>> print([...])
[Ellipsis]
>>> ...
Ellipsis

But changing also __repr__ will conflict with using "..." for representing recursive collections.

>>> a = []
>>> a.append(a)
>>> a
[[...]]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 03:14:17 2018
From: report at bugs.python.org (Lars Friedrich)
Date: Thu, 27 Sep 2018 07:14:17 +0000
Subject: [issue34816] ctypes + hasattr
Message-ID: <1538032457.9.0.545547206417.issue34816@psf.upfronthosting.co.za>


New submission from Lars Friedrich <lars.friedrich at leica-microsystems.com>:

The following creates an OSError:

import ctypes
hasattr(ctypes.windll, 'test')

The expected behavior would be to return "False"

----------
components: ctypes
messages: 326528
nosy: lfriedri
priority: normal
severity: normal
status: open
title: ctypes + hasattr
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34816>
_______________________________________

From report at bugs.python.org  Thu Sep 27 03:14:59 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 07:14:59 +0000
Subject: [issue34817] Ellipsis docs has extra dot in the markdown that makes
 it look like .... (four dots)
Message-ID: <1538032499.31.0.545547206417.issue34817@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I looked up the Ellipsis documentation at https://docs.python.org/dev/library/constants.html#Ellipsis which has the below text : 

> The same as .... Special value used mostly in conjunction with extended slicing syntax for user-defined container data types.

The three dots are marked with backtick and look like codeblock but on a light theme it looks like a CSS issue. The backtick contains the actual ellipsis value (...) but the . at the end makes it look like .... especially since I was also using custom dark theme for https://docs.python.org so I thought it was four dots instead of three dots.

Markdown text at https://github.com/python/cpython/blob/master/Doc/library/constants.rst

> The same as ``...``.  Special used mostly in conjunction with extended slicing syntax for user-defined container data types.

It's very trivial but I thought to add a report and I am fine with a won't fix for this. I thought to add a PR but English is not my first language and I don't know if it can worded better. I can change it to "The same as ... which is a special value used mostly in conjunction with extended slicing syntax for user-defined container data types." to avoid the misleading dot and feedback welcome.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 326529
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Ellipsis docs has extra dot in the markdown that makes it look like .... (four dots)
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34817>
_______________________________________

From report at bugs.python.org  Thu Sep 27 03:19:54 2018
From: report at bugs.python.org (tom.r)
Date: Thu, 27 Sep 2018 07:19:54 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538032794.33.0.545547206417.issue34815@psf.upfronthosting.co.za>


tom.r <tom.p.reichel at gmail.com> added the comment:

Yes. I wanted to change just __str__ because the string value of an Ellipsis should be, well, an ellipsis. The __repr__ representation helps distinguish between recursion and an ellipsis object, so that's fine the way it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 04:01:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 08:01:06 +0000
Subject: [issue24412] setUpClass equivalent for addCleanup
In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za>
Message-ID: <1538035266.91.0.545547206417.issue24412@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is a design issue with the order of cleaning up. tearDown() is purposed to release resources acquired in setUp(). Resources acquired in test methods will be released in doCleanup() if use addCleanup(), but since doCleanup() is called after tearDown(), resources will be released not in reversed order of the time of acquiring. This causes issues if resources acquired in a test method depends on the resource acquired in setUp().

Adding doClassCleanups() and doModuleCleanups() with the same semantic will introduce this problem at class and module level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24412>
_______________________________________

From report at bugs.python.org  Thu Sep 27 04:01:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 08:01:15 +0000
Subject: [issue24412] setUpClass equivalent for addCleanup
In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za>
Message-ID: <1538035275.92.0.545547206417.issue24412@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24412>
_______________________________________

From report at bugs.python.org  Thu Sep 27 04:10:55 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 08:10:55 +0000
Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass
 inheritance
In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
Message-ID: <1538035855.17.0.545547206417.issue21919@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report and patience. This behavior is still reproducible on master as of f55c64c632 . I am adding Raymond as part of triaging who might have a better explanation about this. Raymond, feel free to remove yourself if this is not relevant.

A slightly cleaned up version of the program with repl statements removed for reference : 

class O(object):
     pass

class M(type):
     pass

class N(type):
     pass

class A(O, metaclass=M):
     pass

class B(O, metaclass=N):
     pass

print(B.__bases__)
print(B.__mro__)

print(type(B))
print(type(A))
print(issubclass(type(B), type(A)))

class C(A, metaclass=N):
     pass

class D(B, A):
     pass

class E(B, metaclass=N):
     pass

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21919>
_______________________________________

From report at bugs.python.org  Thu Sep 27 04:14:16 2018
From: report at bugs.python.org (Robert Collins)
Date: Thu, 27 Sep 2018 08:14:16 +0000
Subject: [issue24412] setUpClass equivalent for addCleanup
In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za>
Message-ID: <1538036056.57.0.545547206417.issue24412@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Serhiy, thats not a design flaw, its a feature.

in a class hierarchy, setup and teardown ordering is undefined: implementors can choose whatever order they want to execute in. e.g.

class A(TestCase):
 def setUp(self):
  super().setUp()
  acquire1()

class B(A):
 def setUp(self):
  acquire2()
  super().setUp()

class C(B):
 def setUp(self):
  super().setUp()
  acquire3()

will acquire 2, then 1, then 3.

tearDown() is similarly ill defined.

Secondly, consider

class Example(TestCase):
 def setUp(self):
  self._1 = acquire()
  self.addCleanUp(acquire())
  self._3 = acquire()

 def tearDown(self):
  self._3.cleanUp()
  self._1.cleanUp()
  super().tearDown()

As such, there is no ordering of cleanup + teardown that is 'right' in all cases.

The question then becomes, which ordering *most facilitates* migration from tearDown to cleanup.

The allowable orders are:
 - with a more complex implementation, per-class (no)
 - before tearDown starts
 - after tearDown finishes

The common case tearDown tends to look like this:

def tearDown(self):
  <local cleanup>
  super().tearDown()

so, by placing doCleanup after tearDown, we make it possible for base classes in a test hierarchy to migrate to cleanups without breaking compatibility with child classes. The cost, as you note is that we make it harder for child classes to migrate until the base class has migrated.

But it is strictly better to permit the base class to migrate, because in projects you cannot be sure of all your subclasses out there in the wild, but you can be sure of all your base classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24412>
_______________________________________

From report at bugs.python.org  Thu Sep 27 05:07:11 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Thu, 27 Sep 2018 09:07:11 +0000
Subject: [issue34818] test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7
 with AttributeError: __exit__
Message-ID: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>


New submission from Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:

test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7 with AttributeError: __exit__

When building python 2.7, update to 20180926 from the 2.7 branch, on Ubuntu 18.10 (cosmic) with OpenSSL 1.1.1 the test_ssl errors out like so:

======================================================================
ERROR: test_tls1_3 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_ssl.py", line 2815, in test_tls1_3
    with context.wrap_socket(socket.socket()) as s:
AttributeError: __exit__

Distribution issue https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1759172

----------
assignee: christian.heimes
components: SSL
messages: 326534
nosy: christian.heimes, xnox
priority: normal
severity: normal
status: open
title: test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7 with AttributeError: __exit__
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34818>
_______________________________________

From report at bugs.python.org  Thu Sep 27 05:36:26 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 09:36:26 +0000
Subject: [issue34818] test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7
 with AttributeError: __exit__
In-Reply-To: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>
Message-ID: <1538040986.99.0.545547206417.issue34818@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34818>
_______________________________________

From report at bugs.python.org  Thu Sep 27 05:46:07 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 27 Sep 2018 09:46:07 +0000
Subject: [issue34818] test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7
 with AttributeError: __exit__
In-Reply-To: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>
Message-ID: <1538041567.65.0.545547206417.issue34818@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
priority: normal -> deferred blocker
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34818>
_______________________________________

From report at bugs.python.org  Thu Sep 27 05:51:51 2018
From: report at bugs.python.org (orlnub123)
Date: Thu, 27 Sep 2018 09:51:51 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
Message-ID: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>


New submission from orlnub123 <orlnub123 at gmail.com>:

The map and as_completed functions can randomly timeout earlier or later due to NTP stepping the clock or something changing the time and/or date.

Here's some code to reproduce the issue for map:

import concurrent.futures
import time

with concurrent.futures.ThreadPoolExecutor() as executor:
    list(executor.map(time.sleep, [29, 30], timeout=3000))

And similar code to reproduce it for as_completed:

import concurrent.futures
import time

with concurrent.futures.ThreadPoolExecutor() as executor:
    future1 = executor.submit(time.sleep, 29)
    future2 = executor.submit(time.sleep, 30)
    list(concurrent.futures.as_completed([future1, future2], timeout=3000))

It doesn't error normally, as it shouldn't, but if you move your clock an hour ahead within 30 seconds of running it you get this:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "C:\Python\Python37\lib\concurrent\futures\_base.py", line 588, in result_iterator
    yield fs.pop().result(end_time - time.time())
  File "C:\Python\Python37\lib\concurrent\futures\_base.py", line 434, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

Or this if you used the as_completed example:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "C:\Python\Python37\lib\concurrent\futures\_base.py", line 238, in as_completed
    len(pending), total_futures))
concurrent.futures._base.TimeoutError: 1 (of 2) futures unfinished

The error stems from map and as_completed using time.time to calculate the duration for the timeout. The problem with time.time is that it's adjustable (i.e. it can skip around) which makes it unideal for comparing relative times. A solution would be to replace the time.time calls with either time.monotonic (preferable?) or time.perf_counter.

----------
components: Library (Lib)
messages: 326535
nosy: orlnub123
priority: normal
severity: normal
status: open
title: Executor.map and as_completed timeouts are able to deviate
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 05:58:05 2018
From: report at bugs.python.org (orlnub123)
Date: Thu, 27 Sep 2018 09:58:05 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538042285.32.0.545547206417.issue34819@psf.upfronthosting.co.za>


Change by orlnub123 <orlnub123 at gmail.com>:


----------
keywords: +patch
pull_requests: +8996
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 05:59:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 09:59:30 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538042370.55.0.545547206417.issue34819@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:01:49 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Thu, 27 Sep 2018 10:01:49 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538042509.94.0.545547206417.issue34521@psf.upfronthosting.co.za>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

Copying in my original email to Pablo that elucidated the test failure cause and resolution, including upstream commit/review/issue references for the recvmsg(2) changes IN CURRENT.

Full buildbot worker log attached

While I'm here, update list of versions (branches) affected.

------------------

The test suite fails:

  File
"/usr/home/buildbot/python/3.x.koobs-freebsd-current.nondebug/build/Lib/multiprocessing/reduction.py",
line 164, in recvfds
    raise RuntimeError('received %d items of ancdata' %
RuntimeError: received 0 items of ancdata

For these two tests (further up in the log [1]) ...

test_fd_transfer
(test.test_multiprocessing_forkserver.WithProcessesTestConnection) ... FAIL
test_large_fd_transfer
(test.test_multiprocessing_forkserver.WithProcessesTestConnection) ... FAIL

Further up we see (in the initial test run) ...

4 tests failed:
    test_multiprocessing_fork test_multiprocessing_forkserver
    test_multiprocessing_spawn test_socket

Then further up we see:

======================================================================
FAIL: testFDPassSeparateMinSpace
(test.test_socket.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/home/buildbot/python/3.x.koobs-freebsd-current.nondebug/build/Lib/test/test_socket.py",
line 3186, in testFDPassSeparateMinSpace
    self.checkRecvmsgFDs(2,
  File
"/usr/home/buildbot/python/3.x.koobs-freebsd-current.nondebug/build/Lib/test/test_socket.py",
line 3107, in checkRecvmsgFDs
    self.assertEqual(len(fds), numfds)
AssertionError: 1 != 2
======================================================================
FAIL: testFDPassSeparateMinSpace
(test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/home/buildbot/python/3.x.koobs-freebsd-current.nondebug/build/Lib/test/test_socket.py",
line 3186, in testFDPassSeparateMinSpace
    self.checkRecvmsgFDs(2,
  File
"/usr/home/buildbot/python/3.x.koobs-freebsd-current.nondebug/build/Lib/test/test_socket.py",
line 3107, in checkRecvmsgFDs
    self.assertEqual(len(fds), numfds)
AssertionError: 1 != 2
----------------------------------------------------------------------
Ran 554 tests in 27.636s
FAILED (failures=2, skipped=57)

I looked for recvmsg() changes in FreeBSD recently, and found ...

Commit: https://svnweb.freebsd.org/base?view=revision&revision=337423
Review: https://reviews.freebsd.org/D16561
Bug ID: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131876
Bug Desc:[socket] FD leak by receiving SCM_RIGHTS by recvmsg with small
control message buffer

The commit/bug/review details above point to recvmsg specific changes,
specifically, but maybe not *just*, for SCM_RIGHTS messages, which (in
my opinion) is way too similar to the test case specifics not to be related.

Also, the commit date of Aug 7 16:36:48 2018  seems right around the
time I updated the machine and the tests began to fail.

I can't say yet whether or not a bug crept in with the change, *but*,
the commit does say that it *fixes* bugs, which the python tests, or the
socket code in Python may be have been relying on.

It may also be that FreeBSD specific-behaviour isn't being
handled by the code and/or tests (truncated now where it wasn't before?)

It could also be the buffer sizes the socket code/tests use.

------------------

----------
keywords: +buildbot
stage: patch review -> backport needed
title: test_socket.RecvmsgIntoSCMRightsStreamTest fails on AMD64 FreeBSD CURRENT Debug 3.x -> test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail on AMD64 FreeBSD CURRENT
versions: +Python 2.7, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47835/freebsd-current.python.3.x.build.301.stdio.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:10:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 10:10:19 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538043019.42.0.545547206417.issue34819@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report and PR. I can find a very similar issue where time.time was changed to time.monotonic across multiprocessing module by Victor for the same reason : issue34054. I don't know why it wasn't changed in concurrent.futures . Seems this was reported here : https://bugs.python.org/issue29733#msg289116. I am adding Victor and Antoine who might have thoughts on this. Feel free to remove yourself if it's not relevant.

Thanks

----------
nosy: +pitrou, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:17:04 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 10:17:04 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538043424.17.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8998
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:17:14 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 10:17:14 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538043434.29.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:49:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 10:49:02 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538045342.77.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I search if C extensions of the Python standard libraries are always linked or not to libpython... it's complicated. I tested _ctypes, _hashlib and _struct modules:

* Debian and Ubuntu: NOT linked to libpython
* Conda: LINKED to libpython
* Mageia 7: LINKED to libpython
* Fedora 28, RHEL 7: LINKED to libpython on Python 2.7 and 3.6, except _struct which is NOT linked to libpython on Python 2.7

It means that using dlopen("libpython2.7.so.1.0", RTLD_LOCAL | RTLD_NOW) may or may not work depending on the Linux distribution and depending on the imported C extensions...

If we use the example of Fedora: some C extensions are compiled using Makefile (the Fedora package modifies Modules/Setup, as I showed previously), but others are compiled by setup.py. For example, _ctypes and _hashlib are compiled by setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:52:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 10:52:21 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538045541.38.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Ah, it seems like the bpo-832799 (reported in 2003) is similar to the RHEL bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1585201

Extract of the RHEL bug report:
---
pythontest.c:
#include <dlfcn.h>

int main(int argc, char *argv[])
{
    void *pylib = dlopen("libpython2.7.so.1.0", RTLD_LOCAL | RTLD_NOW);
    void (*Py_Initialize)(void) = dlsym(pylib, "Py_Initialize");
    Py_Initialize();
    int (*PyRun_SimpleStringFlags)(const char *, void *) = dlsym(pylib, "PyRun_SimpleStringFlags");
    PyRun_SimpleStringFlags("import json\n", 0);
    return 0;
}

2. Compile with "gcc -Wall -o pythontest pythontest.c -ldl -g"

3. Run ./pythontest -

Actual results:

it will fail with ImportError: /usr/lib64/python2.7/lib-dynload/_struct.so: undefined symbol: PyFloat_Type
---

The reporter is already aware of the fallback on RTLD_GLOBAL: "(optionally) change RTLD_LOCAL to RTLD_GLOBAL and see that it works".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 06:55:59 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Sep 2018 10:55:59 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1538045342.77.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <5c93016f-a82f-c078-ea48-f670ec0247cd@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 27/09/2018 ? 12:49, STINNER Victor a ?crit?:
> 
> I search if C extensions of the Python standard libraries are always linked or not to libpython... it's complicated. I tested _ctypes, _hashlib and _struct modules:
> 
> * Debian and Ubuntu: NOT linked to libpython

Do you realize libpython.so doesn't exist on Debian / Ubuntu?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:04:23 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 11:04:23 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538046263.55.0.545547206417.issue34819@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, please ignore the comment reference to https://bugs.python.org/issue29733#msg289116 . I misunderstood that it was about concurrent.futures using time.time but it turns out it was about the program using time.time as verifying the PR against the issue still has the timeout error.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:05:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 11:05:50 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538046350.55.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Extract of Antoine's comment on bpo-21536:
> (AFAIK, systems notorious for providing shared library Pythons are RedHat-alike systems, while Debian/Ubuntu provide statically linked Pythons)

Oh. I didn't notice this major difference...

* Ubuntu 16.04: Python 2.7.12 and Python 3.5.2 are not linked to libpython
* Fedora 28: Python 2.7.15 and Python 3.6.6 are linked to libpython (--enable-shared)
* FreeBSD 12 (alpha): Python 2.7 and Python 3.6 are linked to libpython (--enable-shared)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:10:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 11:10:13 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538046613.59.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> * FreeBSD 12 (alpha): Python 2.7 and Python 3.6 are linked to libpython (--enable-shared)

Note: _ctypes, _hashlib and _struct are all linked to libpython, on Python 2 and Python 3.

Antoine:
> Do you realize libpython.so doesn't exist on Debian / Ubuntu?

No, I didn't :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:10:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 11:10:34 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538046634.05.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Antoine:
> Why do you call this a bug?

"./configure --enable-shared && make" links C extensions to libpython. It's surprising that C extensions compiled by Makefile behave differently (not linked to libpython). We need consistency: either *never* link to libpython, or *always* link to libpython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:11:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 11:11:02 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538046662.75.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> It means a C extension compiled with a shared-library Python cannot be imported on a monolithic Python (which doesn't have libpython.so).  It's a real problem when you want to redistribute compiled C extensions: if you compile it on RedHat/CentOS, it won't work on Ubuntu/Debian (the reverse works).

Is it a real use case? Why would anyone use a RHEL binary on Debian? Debian already provides the full standard library.

C extensions of the standard library are tidily coupled to CPython. For example, it may be dangerous to use a C extension of Python 2.7.5 on Python 2.7.15.

I'm talking about the very specific case of C extensions which are part of the stdlib.

Third party C extensions distributed as portable wheel packages using the stable ABI is different use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:13:23 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Sep 2018 11:13:23 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538046803.04.0.545547206417.issue34814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is it a real use case? Why would anyone use a RHEL binary on Debian? Debian already provides the full standard library.

I'm not talking about the standard library obviously.  I don't remember my original use case exactly, but I must have been compiling a C extension on a system and expected it to work on another.

> C extensions of the standard library are tidily coupled to CPython. For example, it may be dangerous to use a C extension of Python 2.7.5 on Python 2.7.15.

I don't believe that.  Binary wheels uploaded to PyPI seem to work fine regardless of the exact bugfix version.

> Third party C extensions distributed as portable wheel packages using the stable ABI is different use case.

Most wheel packages don't use the stable ABI.  They are tied to a Python version such as 2.7, but they don't differentiate between e.g. 2.7.5 and 2.7.15.  We don't break the ABI between bugfix releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:16:31 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Sep 2018 11:16:31 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538046991.64.0.545547206417.issue34819@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset a94ee12c26aa8dd7dce01373779df8055aff765b by Antoine Pitrou (orlnub123) in branch 'master':
bpo-34819: Use a monotonic clock to compute timeouts in concurrent.futures (GH-9599)
https://github.com/python/cpython/commit/a94ee12c26aa8dd7dce01373779df8055aff765b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:16:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 11:16:44 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538047004.62.0.545547206417.issue34814@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm not talking about the standard library obviously.  I don't remember my original use case exactly, but I must have been compiling a C extension on a system and expected it to work on another.

It seems like we are talking about two different things:

* My issue is restricted to the C extensions compiled by Makefile and setup.py: C extensions of the standard libraries
* You are talking about third party extensions: that's out of the scope of this issue, since my issue is about Modules/makesetup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:18:45 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 11:18:45 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538047125.85.0.545547206417.issue34819@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9000

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:18:51 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 11:18:51 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538047131.51.0.545547206417.issue34819@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9001

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:20:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 11:20:45 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538047245.84.0.545547206417.issue34819@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, I missed the Lib/concurrent/futures/ directory when I tried to patch the whole stdlib to use monotonic clocks for timeouts :-( Thanks for the fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:21:02 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Sep 2018 11:21:02 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538047262.88.0.545547206417.issue34814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

But as you said, we need consistency: either *never* link to libpython, or *always* link to libpython.  You are proposing to always link, I'm arguing we should never link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:37:37 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 11:37:37 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538048257.65.0.545547206417.issue34819@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3a4aa6ac55e04c42757443d5b5854b6d893e0461 by Miss Islington (bot) in branch '3.6':
bpo-34819: Use a monotonic clock to compute timeouts in concurrent.futures (GH-9599)
https://github.com/python/cpython/commit/3a4aa6ac55e04c42757443d5b5854b6d893e0461


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:46:15 2018
From: report at bugs.python.org (orlnub123)
Date: Thu, 27 Sep 2018 11:46:15 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538048775.38.0.545547206417.issue34819@psf.upfronthosting.co.za>


orlnub123 <orlnub123 at gmail.com> added the comment:

Happy to help! I'm surprised it got merged so quickly, amazing response times all-around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:46:41 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 11:46:41 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538048801.54.0.545547206417.issue34819@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b01121fd4200f1c27873422f7f72d02eec08630 by Miss Islington (bot) in branch '3.7':
bpo-34819: Use a monotonic clock to compute timeouts in concurrent.futures (GH-9599)
https://github.com/python/cpython/commit/2b01121fd4200f1c27873422f7f72d02eec08630


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 07:47:19 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Sep 2018 11:47:19 +0000
Subject: [issue34819] Executor.map and as_completed timeouts are able to
 deviate
In-Reply-To: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>
Message-ID: <1538048839.75.0.545547206417.issue34819@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/issue34819>
_______________________________________

From report at bugs.python.org  Thu Sep 27 08:04:32 2018
From: report at bugs.python.org (Felipe Rodrigues)
Date: Thu, 27 Sep 2018 12:04:32 +0000
Subject: [issue34576] [EASY doc] http.server,
 SimpleHTTPServer: warn users on security
In-Reply-To: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>
Message-ID: <1538049872.7.0.545547206417.issue34576@psf.upfronthosting.co.za>


Felipe Rodrigues <felipe at felipevr.com> added the comment:

Well, even if we do fix some security issues in SimpleHTTPServer, it doesn't change the fact that it shouldn't really be used for sensitive applications. I like how Django docs handles a similar issue regarding their development server (https://docs.djangoproject.com/en/2.1/ref/django-admin/#runserver)

> DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that?s how it?s gonna stay. We?re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

I think that the same philosophy applies to SimpleHTTPServer. If the warning should be add to the docs, I'll be glad to issue an PR fixing it!

----------
nosy: +fbidu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34576>
_______________________________________

From report at bugs.python.org  Thu Sep 27 08:26:26 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 27 Sep 2018 12:26:26 +0000
Subject: [issue34816] ctypes + hasattr
In-Reply-To: <1538032457.9.0.545547206417.issue34816@psf.upfronthosting.co.za>
Message-ID: <1538051186.59.0.545547206417.issue34816@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

ctypes.windll is an instance of ctypes.LibraryLoader, which has a __getattr__ method that calls ctypes.WinDLL(name) and caches the result as an instance attribute. I suppose with chained exceptions it's reasonable to handle OSError in __getattr__ by raising AttributeError. For example:

    class A:
        def __init__(self, name):
            raise OSError

    class B:
        def __getattr__(self, name):
            try:
                A(name)
            except OSError:
                raise AttributeError

Demo:

    >>> b = B()
    >>> b.test
    Traceback (most recent call last):
      File "<stdin>", line 4, in __getattr__
      File "<stdin>", line 3, in __init__
    OSError

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 6, in __getattr__
    AttributeError

    >>> hasattr(b, 'test')
    False

FYI, I recommend avoiding the cdll and windll LibraryLoader instances. I wish they were deprecated because globally caching CDLL and WinDLL instances leads to conflicts between projects that use the same shared libraries.

----------
nosy: +eryksun
stage:  -> test needed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34816>
_______________________________________

From report at bugs.python.org  Thu Sep 27 08:35:06 2018
From: report at bugs.python.org (Lars Friedrich)
Date: Thu, 27 Sep 2018 12:35:06 +0000
Subject: [issue34816] ctypes + hasattr
In-Reply-To: <1538032457.9.0.545547206417.issue34816@psf.upfronthosting.co.za>
Message-ID: <1538051706.86.0.545547206417.issue34816@psf.upfronthosting.co.za>


Lars Friedrich <lars.friedrich at leica-microsystems.com> added the comment:

Thank you for your reply.

I am not sure if I understood correctly:
Do you suggest to modify ctypes.__init__.py so that the __getattr__ method of LibraryLoader catches the OSError and raises an AttributeError instead, as in your example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34816>
_______________________________________

From report at bugs.python.org  Thu Sep 27 08:40:20 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 27 Sep 2018 12:40:20 +0000
Subject: [issue34709] Suggestion: make getuser.getpass() also look at
 SUDO_USER environment variable
In-Reply-To: <1537160258.21.0.956365154283.issue34709@psf.upfronthosting.co.za>
Message-ID: <1538052020.19.0.545547206417.issue34709@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Versions 3.7 and below are all in feature-freeze, so this change could only apply to 3.8 and above.

I don't know if this feature is desirable or not.

If it is (sometimes?) desirable, my guess is that it would be undesirable to use SUDO_USER *unless* the effective user ID was 0. (Don't check for the name "root", that's only a convention.) In pseudocode:

    names = ('LOGNAME', 'USER', 'LNAME', 'USERNAME')
    if effective user ID == 0:
        names = ('SUDO_USER',) + names
    for name in names:
        ...


Also needs documentation and tests.

----------
nosy: +steven.daprano
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/issue34709>
_______________________________________

From report at bugs.python.org  Thu Sep 27 08:57:19 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 27 Sep 2018 12:57:19 +0000
Subject: [issue34763] Python lacks 0x4E17
In-Reply-To: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>
Message-ID: <1538053039.26.0.545547206417.issue34763@psf.upfronthosting.co.za>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34763>
_______________________________________

From report at bugs.python.org  Thu Sep 27 09:26:48 2018
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 27 Sep 2018 13:26:48 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538054808.2.0.545547206417.issue34370@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Ned, please hold off a bit on this--another developer is doing some final fine-tuning of the scrolling code so it fully passes Tk's test suite. I'm waiting for the final commit of this code any day now.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Thu Sep 27 09:33:53 2018
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 27 Sep 2018 13:33:53 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1538055233.47.0.545547206417.issue34814@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

Debian/Ubuntu doesn't link against the library because it would add dependencies on all supported Python versions. Normally this is just during transition times, but e.g. for the upcoming Ubuntu 18.10 release we didn't finish the transition and so ship two Python3 versions. The packaging tools would add package dependencies on both 3.6 and 3.7 what you don't want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Thu Sep 27 09:38:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 13:38:58 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538055538.79.0.545547206417.issue34521@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Commit merged into master:

commit 7291108d88ea31d205da4db19d202d6cbffc6d93
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Thu Sep 27 10:25:03 2018 +0100

    Fix tests in test_socket to use correctly CMSG_LEN (GH-9594)
    
    After some failures in AMD64 FreeBSD CURRENT Debug 3.x buildbots
    regarding tests in test_socket that are using
    testFDPassSeparateMinSpace(), FreeBDS revision 337423 was pointed
    out to be the reason the test started to fail.
    
    A close examination of the manpage for cmsg_space(3) reveals that
    the number of file descriptors needs to be taken into account when
    using CMSG_LEN().
    
    This commit fixes tests in test_socket to use correctly CMSG_LEN, taking
    into account the number of FDs.

3.7:

commit addef07ca7d7b6971d59c062c3229e91a99e5f5e (upstream/3.7, 3.7)
Author: Miss Islington (bot) <31488909+miss-islington at users.noreply.github.com>
Date:   Thu Sep 27 06:30:47 2018 -0700

3.6:

commit fe48b6df101aac10dc846fa6fd1a41f877e77025 (upstream/3.6, 3.6)
Author: Miss Islington (bot) <31488909+miss-islington at users.noreply.github.com>
Date:   Thu Sep 27 06:30:55 2018 -0700

(the commit message doesn't contain bpo-34521, so bots didn't added comments here about the commits)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 09:53:15 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 27 Sep 2018 13:53:15 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538056395.09.0.545547206417.issue34521@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

It looks like the test_socket is fixed but some related issues are still left in multiprocessing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 09:58:02 2018
From: report at bugs.python.org (wencan)
Date: Thu, 27 Sep 2018 13:58:02 +0000
Subject: =?utf-8?q?=5Bissue34820=5D_binascii=2Ec=3A1578=3A1=3A_error=3A_the_contro?=
 =?utf-8?q?l_flow_of_function_=E2=80=98binascii=5Fcrc32=E2=80=99_does_not_?=
 =?utf-8?q?match_its_profile_data_=28counter_=E2=80=98arcs=E2=80=99=29?=
Message-ID: <1538056682.62.0.545547206417.issue34820@psf.upfronthosting.co.za>


New submission from wencan <wencan at live.cn>:

git version: a94ee12c26aa8dd7dce01373779df8055aff765b

/home/wencan/Projects/github.com/python/cpython/Modules/binascii.c: In function ?binascii_crc32?:
/home/wencan/Projects/github.com/python/cpython/Modules/binascii.c:1578:1: error: the control flow of function ?binascii_crc32? does not match its profile data (counter ?arcs?) [-Werror=coverage-mismatch]
 }
 ^
/home/wencan/Projects/github.com/python/cpython/Modules/binascii.c:1578:1: error: the control flow of function ?binascii_crc32? does not match its profile data (counter ?time_profiler?) [-Werror=coverage-mismatch]

----------
components: Build
messages: 326563
nosy: wencan
priority: normal
severity: normal
status: open
title: binascii.c:1578:1: error: the control flow of function ?binascii_crc32? does not match its profile data (counter ?arcs?)
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34820>
_______________________________________

From report at bugs.python.org  Thu Sep 27 10:25:40 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Sep 2018 14:25:40 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538058340.49.0.545547206417.issue34815@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm against this. The str() and repr() of Ellipsis are 'Ellipsis' for a reason: to remind the user that this is "just" an object, not a piece of special syntax.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 10:39:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 14:39:15 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1538059155.57.0.545547206417.issue32892@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Since Python 3.6 ;-)

Thank you for correction Victor. It is what I meant. Why I had written 3.8? :-?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 27 10:42:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 14:42:43 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1538059363.93.0.545547206417.issue32892@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3f22811fef73aec848d961593d95fa877f77ecbf by Serhiy Storchaka in branch 'master':
bpo-32892: Use ast.Constant instead of specific constant AST types. (GH-9445)
https://github.com/python/cpython/commit/3f22811fef73aec848d961593d95fa877f77ecbf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 27 11:25:48 2018
From: report at bugs.python.org (=?utf-8?b?0JjQs9C+0YDRjCDQndC40LrQuNGC0LjQvQ==?=)
Date: Thu, 27 Sep 2018 15:25:48 +0000
Subject: [issue34821] Crash after run Python interpreter from removed directory
Message-ID: <1538061948.41.0.545547206417.issue34821@psf.upfronthosting.co.za>


New submission from ????? ??????? <igarok33210 at gmail.com>:

How to repeat: see screen.

For example, command "lsb_release" is also not found removed directory, but there is no crash.

Python2, in this case, run without problem.

----------
files: python_bug.png
messages: 326567
nosy: ????? ???????
priority: normal
severity: normal
status: open
title: Crash after run Python interpreter from removed directory
type: crash
versions: Python 3.4
Added file: https://bugs.python.org/file47836/python_bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34821>
_______________________________________

From report at bugs.python.org  Thu Sep 27 11:29:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 15:29:36 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1538062176.32.0.545547206417.issue32892@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thank you Serhiy :-D I really love ast.Constant, it simplify many things when writing code modifying the AST.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Thu Sep 27 11:50:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Sep 2018 15:50:24 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538063424.68.0.545547206417.issue34521@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Is test_socket of Python 2.7 affected by the issue? If not, I suggest to remove 2.7 from this issue and close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 12:02:52 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 27 Sep 2018 16:02:52 +0000
Subject: [issue34700] typing.get_type_hints doesn't know about typeshed
In-Reply-To: <1537042200.54.0.956365154283.issue34700@psf.upfronthosting.co.za>
Message-ID: <1538064172.3.0.545547206417.issue34700@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
assignee:  -> levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34700>
_______________________________________

From report at bugs.python.org  Thu Sep 27 12:17:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 16:17:40 +0000
Subject: [issue34822] Simplify AST for slices
Message-ID: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently an AST for expressions can have non-terminal nodes of two types: expr and slice. Every of them can be a one of several kinds. A slice can be of kind Index (just an expression), Slice (optional expressions separated by ":") or ExtSlice (slices separated by ",").

For example, the expression "d[a, ..., b:c]" is represented as:

    Subscript(
        Name('d', Load()),
        ExtSlice(
            [
                Index(Name('a', Load())),
                Index(Constant(Ellipsis)),
                Slice(Name('b', Load()), Name('c', Load()), None)
            ]
        ),
        Load()
    )

and the expression "d[a, ..., b]" is represented as:

    Subscript(
        Name('d', Load()),
        Index(
            Tuple(
                [
                    Name('a', Load()),
                    Constant(Ellipsis),
                    Name('b', Load())
                ],
                Load()
            )
        ),
        Load()
    )

(note that ExtSlice is used only if there are slices in subexpressions).

I suggest to get rid of the separate slice type. The Slice kind will be a kind of the expr type instead of the slice type. The ExtSlice kind will be always replaced with a Tuple, even if subexpressions contain slices. Nodes of the Index kind will be replaced with expr nodes to which they are referred. For example, the expression "d[a, ..., b:c]" will be represented as:

    Subscript(
        Name('d', Load()),
        Tuple(
            [
                Name('a', Load()),
                Constant(Ellipsis),
                Slice(Name('b', Load()), Name('c', Load()), None)
            ],
            Load()
        ),
        Load()
    )

This will simplify the code for handling AST, especially the C code. The following PR removes around 400 lines of code (a half of them are generated, but others are handwritten). I hope that this regularization will help to write a general code for walking AST for expressions and remove more duplicated code in ast_opt.c, ast_unparse.c, and symtable.c. This even can help to solve a problem with crashes in handling too deep AST if implement the recursion without using the C stack (but this is dreams).

This change is more breaking than a change in issue32892. What will continue to work:

* The code for creating an AST when pass values as arguments: `Index(value)` will return just `value`, `ExtSlice(slices)` will return `Tuple(slices, Load())`.

* NodeVisitor based processing. Methods visit_Index() and visit_ExtSlice() will be never invoked. The semantic of visit_Slice() will be not changed. visit_Tuple() will be invoked instead of visit_ExtSlice() for extended slices.

* isinstance() and issubclass() checks for Slice. Subclassing of Slice.

What will no longer work (with the current implementation):

* The code that creates empty AST nodes and sets their attributes. `node = Index(); node.value = value` will no longer work.

* The code that reads attributes of just created Index and ExtSlice nodes. `Index(value)` will return just `value` instead of a new object whose attribute "value" is a specified value. A list of subexpressions of ExtSlice(slices) will be accessible as the "elts" attribute instead of "dims" (because it is a Tuple).

* isinstance() and issubclass() checks for Index and ExtSlice will always return False.

* Subclassing of Index and ExtSlice. Instantiating subclasses of Index and ExtSlice will return the same result as for Index and ExtSlice, i.e. not instance of these classes.

* The code that produces a Python code from AST will need to handle indexing with tuples specially (see Tools/parser/unparse.py) because d[(a, b)] is valid syntax (although parenthesis are redundant), but d[(a, b:c)] is not.

Some limitations are caused by the desire for simplicity and can be removed. For example it is possible to add the "dims" alias of "elts" to Tuple, and make subclasses working as before. It is more hard and inefficient to keep isinstance() checks and attribute access for Index. If some breakage for Index is not avoidable, I'm not sure that it is worth to spent efforts for imitating the old behavior for ExtSlice.

----------
components: Interpreter Core, Library (Lib)
messages: 326570
nosy: benjamin.peterson, brett.cannon, gvanrossum, nascheme, ncoghlan, serhiy.storchaka, thautwarm, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Simplify AST for slices
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Thu Sep 27 12:30:20 2018
From: report at bugs.python.org (tom.r)
Date: Thu, 27 Sep 2018 16:30:20 +0000
Subject: [issue34815] Change Py_Ellipse __str__ behavior.
In-Reply-To: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>
Message-ID: <1538065820.78.0.545547206417.issue34815@psf.upfronthosting.co.za>


tom.r <tom.p.reichel at gmail.com> added the comment:

That's understandable. Thanks for considering it, closing the patch.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34815>
_______________________________________

From report at bugs.python.org  Thu Sep 27 12:47:02 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 27 Sep 2018 16:47:02 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1538066822.21.0.545547206417.issue34776@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Thu Sep 27 12:56:48 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 27 Sep 2018 16:56:48 +0000
Subject: [issue34803] argparse int type does not accept scientific notation
In-Reply-To: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>
Message-ID: <1538067408.65.0.545547206417.issue34803@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34803>
_______________________________________

From report at bugs.python.org  Thu Sep 27 12:58:23 2018
From: report at bugs.python.org (Michael Stapelberg)
Date: Thu, 27 Sep 2018 16:58:23 +0000
Subject: =?utf-8?q?=5Bissue34823=5D_libffi_detection_doesn=E2=80=99t_work_in_my_se?=
 =?utf-8?q?tup?=
Message-ID: <1538067503.8.0.545547206417.issue34823@psf.upfronthosting.co.za>


New submission from Michael Stapelberg <michael+python at stapelberg.ch>:

(Tested with Python 3.7, but AFAICT, the situation hasn?t changed in Python 3.8.)

Python?s configure tries to fill the LIBFFI_INCLUDEDIR system variable with the value of -I as returned by pkg-config libffi --cflags-only-I.

Python?s setup.py tries to determine whether libffi is present by searching a couple of well-known library directories.

Both of these checks fail in my environment (think Linux From Scratch). I?m setting the following environment variables:

CPATH=/home/michael/libffi-3.2.1/include
LIBRARY_PATH=/home/michael/libffi-3.2.1/lib64

gcc can build against libffi just fine:

% echo echo '#include <ffi.h>                  
> int main() {}' > foo.c
% gcc -o foo foo.c -lffi
% ldd foo
	linux-vdso.so.1 (0x00007ffe4450a000)
	libffi.so.6 => /home/michael/libffi-3.2.1/lib64/libffi.so.6 (0x00007f3935aba000)
	libc.so.6 => /home/michael/glibc-2.27/lib/libc.so.6 (0x00007f3935902000)
	/lib64/ld-linux-x86-64.so.2 => /home/michael/glibc-2.27/lib/ld-linux-x86-64.so.2 (0x00007f3935aca000)

However, when compiling Python, I?m getting the following error message, resulting in the _ctypes module not being built:

INFO: Could not locate ffi libs and/or headers

Now, one issue is that pkg-config understands CPATH, so calling pkg-config --cflags-only-I is not sufficient to obtain the include directory, one also needs to clear CPATH:

% pkg-config libffi --cflags-only-I      

% CPATH= pkg-config libffi --cflags-only-I
-I/home/michael/libffi-3.2.1/include

After patching this in configure, LIBFFI_INCLUDEDIR is set correctly, but the build still fails, as the libffi shared object is located in my non-standard path, which setup.py doesn?t check.

Without knowing much about the Python internals, it seems to me that both of these issues would be fixed if Python stopped trying to find the libffi include/lib locations and just used pkg-config to detect the required CFLAGS and LDFLAGS, just like Python currently does with openssl.

Is there any reason we can?t use pkg-config for libffi like that?

Thanks!

----------
components: Installation
messages: 326572
nosy: stapelberg
priority: normal
severity: normal
status: open
title: libffi detection doesn?t work in my setup
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34823>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:06:43 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 27 Sep 2018 17:06:43 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1538068003.31.0.545547206417.issue34776@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:07:57 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 27 Sep 2018 17:07:57 +0000
Subject: [issue34824] _ssl.c: Possible null pointer dereference
Message-ID: <1538068077.13.0.545547206417.issue34824@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

If _PyBytes_Resize() fails in _ssl_MemoryBIO_read_impl(), Py_DECREF() will be called on a null pointer.

----------
assignee: christian.heimes
components: Extension Modules, SSL
messages: 326573
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: _ssl.c: Possible null pointer dereference
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34824>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:09:12 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 17:09:12 +0000
Subject: [issue34824] _ssl.c: Possible null pointer dereference
In-Reply-To: <1538068077.13.0.545547206417.issue34824@psf.upfronthosting.co.za>
Message-ID: <1538068152.78.0.545547206417.issue34824@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/issue34824>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:11:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 17:11:20 +0000
Subject: [issue34822] Simplify AST for slices
In-Reply-To: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>
Message-ID: <1538068280.66.0.545547206417.issue34822@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +9002
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:11:30 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 27 Sep 2018 17:11:30 +0000
Subject: [issue34824] _ssl.c: Possible null pointer dereference
In-Reply-To: <1538068077.13.0.545547206417.issue34824@psf.upfronthosting.co.za>
Message-ID: <1538068290.33.0.545547206417.issue34824@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +9003
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34824>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:19:45 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 27 Sep 2018 17:19:45 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1538068785.21.0.545547206417.issue34022@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
pull_requests: +9004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:19:45 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 27 Sep 2018 17:19:45 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1538068785.37.0.183324690243.issue29708@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
pull_requests: +9005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:20:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 17:20:06 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538068806.94.0.545547206417.issue34762@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Perhaps this change caused new compiler warnings:

In file included from ./Include/pytime.h:6:0,
                 from ./Include/Python.h:68,
                 from /home/serhiy/py/cpython/Modules/_asynciomodule.c:1:
/home/serhiy/py/cpython/Modules/_asynciomodule.c: In function ?_asyncio_Task___init___impl?:
./Include/object.h:895:14: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
         (op) = (op2);                           \
              ^
/home/serhiy/py/cpython/Modules/_asynciomodule.c:1954:5: note: in expansion of macro ?Py_XSETREF?
     Py_XSETREF(self->task_context, PyContext_CopyCurrent());
     ^~~~~~~~~~
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c: In function ?init_current_context?:
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c:1503:44: warning: passing argument 1 of ?PyContextVar_Set? from incompatible pointer type [-Wincompatible-pointer-types]
     PyContextToken *tok = PyContextVar_Set(current_context_var, tl_context);
                                            ^~~~~~~~~~~~~~~~~~~
In file included from ./Include/Python.h:116:0,
                 from /home/serhiy/py/cpython/Modules/_decimal/_decimal.c:29:
./Include/context.h:63:24: note: expected ?PyObject * {aka struct _object *}? but argument is of type ?PyContextVar * {aka struct _pycontextvarobject *}?
 PyAPI_FUNC(PyObject *) PyContextVar_Set(PyObject *var, PyObject *value);
                        ^~~~~~~~~~~~~~~~
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c:1503:27: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
     PyContextToken *tok = PyContextVar_Set(current_context_var, tl_context);
                           ^~~~~~~~~~~~~~~~
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c: In function ?current_context?:
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c:1517:26: warning: passing argument 1 of ?PyContextVar_Get? from incompatible pointer type [-Wincompatible-pointer-types]
     if (PyContextVar_Get(current_context_var, NULL, &tl_context) < 0) {
                          ^~~~~~~~~~~~~~~~~~~
In file included from ./Include/Python.h:116:0,
                 from /home/serhiy/py/cpython/Modules/_decimal/_decimal.c:29:
./Include/context.h:56:17: note: expected ?PyObject * {aka struct _object *}? but argument is of type ?PyContextVar * {aka struct _pycontextvarobject *}?
 PyAPI_FUNC(int) PyContextVar_Get(
                 ^~~~~~~~~~~~~~~~
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c: In function ?PyDec_SetCurrentContext?:
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c:1564:44: warning: passing argument 1 of ?PyContextVar_Set? from incompatible pointer type [-Wincompatible-pointer-types]
     PyContextToken *tok = PyContextVar_Set(current_context_var, v);
                                            ^~~~~~~~~~~~~~~~~~~
In file included from ./Include/Python.h:116:0,
                 from /home/serhiy/py/cpython/Modules/_decimal/_decimal.c:29:
./Include/context.h:63:24: note: expected ?PyObject * {aka struct _object *}? but argument is of type ?PyContextVar * {aka struct _pycontextvarobject *}?
 PyAPI_FUNC(PyObject *) PyContextVar_Set(PyObject *var, PyObject *value);
                        ^~~~~~~~~~~~~~~~
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c:1564:27: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
     PyContextToken *tok = PyContextVar_Set(current_context_var, v);
                           ^~~~~~~~~~~~~~~~
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c: In function ?PyInit__decimal?:
/home/serhiy/py/cpython/Modules/_decimal/_decimal.c:5542:25: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
     current_context_var = PyContextVar_New("decimal_context", NULL);
                         ^

----------
nosy: +serhiy.storchaka
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:24:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 17:24:00 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538069040.18.0.545547206417.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Right, I'll make a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:33:00 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 17:33:00 +0000
Subject: [issue34821] Crash after run Python interpreter from removed directory
In-Reply-To: <1538061948.41.0.545547206417.issue34821@psf.upfronthosting.co.za>
Message-ID: <1538069580.46.0.545547206417.issue34821@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34821>
_______________________________________

From report at bugs.python.org  Thu Sep 27 13:43:51 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 17:43:51 +0000
Subject: [issue34821] Crash after run Python interpreter from removed directory
In-Reply-To: <1538061948.41.0.545547206417.issue34821@psf.upfronthosting.co.za>
Message-ID: <1538070231.07.0.545547206417.issue34821@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report and steps. Can you try this on Python 3.5 ? I think this is the related issue issue22834 that was not fixed in Python 3.4 and has the same line numbers. I can't reproduce this on my Ubuntu machine with Python 3.6.5 from Anaconda though in the path

Steps to reproduce as below : 

karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ ls /tmp/foo
ls: cannot access '/tmp/foo': No such file or directory

# Create the directory
karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ mkdir /tmp/foo
karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ cd /tmp/foo

# Load a REPL

karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ python3
Python 3.6.5 |Anaconda, Inc.| (default, Apr 29 2018, 16:14:56)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

# Delete the directory
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ rm -rf /tmp/foo/
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ rm -rf /tmp/foo

# Load the REPL

karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ python3
Python 3.6.5 |Anaconda, Inc.| (default, Apr 29 2018, 16:14:56)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ uname -a
Linux ubuntu-s-1vcpu-1gb-blr1-01 4.4.0-127-generic #153-Ubuntu SMP Sat May 19 10:58:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# Python 2

karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ python2
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>


Hope it helps! Unfortunately I don't have Python 3.4 on my machine to give this a try. If you are not able to reproduce this with Python 3.5 then I propose closing this as duplicate linking to the other issue. Thanks again for the report!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34821>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:00:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:00:22 +0000
Subject: [issue34825] Add more entries to os module to pathlib reference table
Message-ID: <1538071222.64.0.545547206417.issue34825@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I found issue33194 where unlink from pathlib can be used to delete a file or symlink similar to os.unlink or os.remove but the visibility for the function was low. I found there is a reference table with os module functions and their equivalent pathlib methods. I think this can be improved by adding an entry for Path.unlink as an equivalent for os.remove and os.unlink. I would suggest adding some more functions to this table. The added functions are as below : 

:func:`os.chmod`                       :meth:`Path.chmod`
:func:`os.mkdir`                       :meth:`Path.mkdir`
:func:`os.rename`                      :meth:`Path.rename`
:func:`os.replace`                     :meth:`Path.replace`
:func:`os.rmdir`                       :meth:`Path.rmdir`
:func:`os.remove`, :func:`os.unlink`   :meth:`Path.unlink` 
:func:`os.path.samefile`               :meth:`Path.samefile`

The only issue is that some functions have a dir_fd=None in os module and I think this table is used for functions that do equivalent actions and not as drop-in replacements with equal type signatures. Feedback welcome. Since the table is present only on 3.7 and master I am leaving 3.6 for versions. I will push a PR shortly for this.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 326577
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Add more entries to os module to pathlib reference table
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34825>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:04:44 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 27 Sep 2018 18:04:44 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1538071484.62.0.545547206417.issue34022@psf.upfronthosting.co.za>


Elvis Pranskevichus <elvis at magic.io> added the comment:

https://github.com/python/cpython/pull/9607 turns SOURCE_DATE_EPOCH into a *default* rather than absolute override.

test_cmd_line_script and test_runpy fail due to the lack of support for hash-based .pycs in zipimport, which needs fixing also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:09:25 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:09:25 +0000
Subject: [issue34825] Add more entries to os module to pathlib reference table
In-Reply-To: <1538071222.64.0.545547206417.issue34825@psf.upfronthosting.co.za>
Message-ID: <1538071765.01.0.545547206417.issue34825@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +9006
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34825>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:24:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:24:22 +0000
Subject: [issue34821] Crash after run Python interpreter from removed directory
In-Reply-To: <1538061948.41.0.545547206417.issue34821@psf.upfronthosting.co.za>
Message-ID: <1538072662.31.0.545547206417.issue34821@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Just installed Python 3.4 and can confirm this is fixed in 3.5 but exists on Python 3.4.9 though I don't receive any segfaults though as in the picture with 3.4.

karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ mkdir /tmp/foo
karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ cd /tmp/foo
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ rm -rf /tmp/foo
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ python3.4
Python 3.4.9 (default, Aug  3 2018, 23:38:40)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "/usr/lib/python3.4/site.py", line 419, in register_readline
    import readline
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2222, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2164, in _find_spec
  File "<frozen importlib._bootstrap>", line 1940, in find_spec
  File "<frozen importlib._bootstrap>", line 1911, in _get_spec
  File "<frozen importlib._bootstrap>", line 1879, in _path_importer_cache
FileNotFoundError: [Errno 2] No such file or directory
>>>
karthi at ubuntu-s-1vcpu-1gb-blr1-01:/tmp/foo$ python3.5
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Python 3.4.9 is the latest release and Python 3.4.10 will be released in March 2019 according to https://www.python.org/dev/peps/pep-0429/#release-schedule . Looking at the patch for this issue and since 3.4 is in security fixes mode I think this fix has a less probability of getting backported which I think is an explicit decision as I can see from the issue.


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34821>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:27:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:27:21 +0000
Subject: =?utf-8?q?=5Bissue34820=5D_binascii=2Ec=3A1578=3A1=3A_error=3A_the_contro?=
 =?utf-8?q?l_flow_of_function_=E2=80=98binascii=5Fcrc32=E2=80=99_does_not_?=
 =?utf-8?q?match_its_profile_data_=28counter_=E2=80=98arcs=E2=80=99=29?=
In-Reply-To: <1538056682.62.0.545547206417.issue34820@psf.upfronthosting.co.za>
Message-ID: <1538072841.57.0.545547206417.issue34820@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34820>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:39:14 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:39:14 +0000
Subject: =?utf-8?q?=5Bissue34820=5D_binascii=2Ec=3A1578=3A1=3A_error=3A_the_contro?=
 =?utf-8?q?l_flow_of_function_=E2=80=98binascii=5Fcrc32=E2=80=99_does_not_?=
 =?utf-8?q?match_its_profile_data_=28counter_=E2=80=98arcs=E2=80=99=29?=
In-Reply-To: <1538056682.62.0.545547206417.issue34820@psf.upfronthosting.co.za>
Message-ID: <1538073554.79.0.545547206417.issue34820@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. 

* Can you please add the OS, GCC details, full traceback and command that triggers the error? 
* Is it consistent?
* Are you adding a flag to treat all the warnings as errors? 

I assume you are running PGO. As I can see on the bots for PGO they are green on Debian for the commit : https://buildbot.python.org/all/#/builders/47/builds/1609/steps/2/logs/stdio .  There is a issue related to PGO that causes internal compiler error but I don't think it's related here and it suggests doing make clean since previous build artifacts might cause an issue : https://bugs.python.org/issue31963#msg305708

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34820>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:42:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 18:42:53 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538073773.42.0.545547206417.issue34762@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +9007
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:48:13 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Sep 2018 18:48:13 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1538074093.88.0.545547206417.issue32956@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Joshua]

> 1. Update the round() docs to make the documentation of this behavior less buried,

Sounds reasonable to me; I'm definitely open to documentation improvements. Though it doesn't seem all that buried to me: the round-ties-to-even behaviour is described in the third sentence in the first place I'd look for round documentation (https://docs.python.org/3/library/functions.html#round). It would be misleading to move the information earlier, because the use of round-ties-to-even is specific to the builtin types: user-defined types can do whatever they like via the __round__ magic method.

> 2. include a (brief) justification (possibly even just a link to http://wiki.c2.com/?BankersRounding or some more-authoritative document), and

Sure, a link to a source on bankers rounding could work.

> 3. link to where else this change in Python 3 was discussed more, if anywhere, or else confirm this change was made based on no additional analysis that we can find written down.

I'm not aware of much discussion beyond the thread that Serhiy already pointed to. There's a little bit more (but not much) on rounding the py3k mailing list (try a Google search for "site:mail.python.org/pipermail/python-3000 rounding").

> It'd also be interesting to hear if this is something we wish we'd done differently now, but that shouldn't distract from 1, 2, and 3.

I can't speak for anyone else, but it's certainly not something I think should have been done differently, with one caveat: the silent and subtle change in behaviour from Python 2 to Python 3 was a bit unpleasant, and a possible source of late-discovered (or undiscovered) bugs.

> so maybe changing from round_half_up to round_half_even was necessary for the other improvements [...]

No. The change was independent of other fixes and changes. There _is_ quite a history of round changes: fixes for the single-argument round function in odd corner cases (earlier versions of Python used the simple add-half-and-chop algorithm, with gives the wrong answer for 0.4999999999999999 and for 4503599627370497.0 thanks to FPU-level rounding in the add-half step); making two-argument round correctly-rounded in all cases in Python 2.7 and 3.1 via the same dtoa.c machinery used for str<->float conversions; changing the return type of single-argument round in Python 3; making round generic via the __round__ magic method, etc. But none of these required the change in rounding mode.

We need to recognise that there are various different contexts where the idea of "rounding" comes into play in a general-purpose language. Some examples:

1. FPU-level rounding for basic floating-point operations (addition, multiplication, sqrt, etc.)
2. Conversion of source-code decimal numeric literals (e.g., in "bad_pi = 3.14") to the _nearest_ exactly representable binary float/double; the notion of _nearest_ needs some way to break ties.
3. Formatting a float for output as a string (format(my_float, ".2f"))
4. Rounding a float to the nearest integer (Python's single-argument "round")
5. Rounding a binary float to some number of decimal places (two-argument round), which is a rather more subtle operation than it might seem at first sight

For 1., there's decades of numerical evidence that round-ties-to-even is what you want to do, and that's why IEEE 754 makes it the default rounding mode, and why it's the rounding mode you're likely to be using for numeric work out of the box in any mainstream language. [For one demonstration of where the unbiasedness of round-ties-to-even can matter, see https://stackoverflow.com/a/45245802/270986. Apologies for linking to my own answer here, but it was easily accessible. I'm sure there are many better demonstrations out there.]

Case 2 is really a special case of 1. Though not (usually) FPU-supported: you can think of conversion from decimal string to binary floating-point as another primitive floating-point operation, and it's one that's covered by IEEE 754; round-ties-to-even (or at least, some precision- or algorithm-limited _approximation_ to round-ties-to-even) is again a common default across languages and operating systems.

Case 3 is also covered by IEEE 754, and I believe that "most" languages use round-ties-to-even here, too. C's fprintf (for example) specifies that e-style, f-style, and g-style formatting should be "correctly rounded" (C99 7.19.6.1p13), where "correctly rounded" means "[...] nearest in value, subject to the current rounding mode [...]" (C99 3.9); in practice, that's usually round-ties-to-even. Java's DecimalFormat uses round-ties-to-even by default (source:  https://docs.oracle.com/javase/7/docs/api/java/text/DecimalFormat.html). I haven't checked other languages, but I expect that many of them do something similar.

Cases 4 and 5 are mostly what we're arguing about in this issue. It's much less clear to me that the numerical benefits are significant at this level (compared to FPU-level last-bit-rounding, where those benefits are really unarguable). But note that these cases are really just floatified versions of case 3. Indeed, Python 3's current two-argument round algorithm is based directly on the string conversion code used for string formatting. And the use of round-ties-to-even for case 3 is already well established (and was already established long before Python 3.)

What happens for these 5 cases in Java? It _looks_ to me as though the first three cases use round-ties-to-even, the fourth uses round-ties-to-away by default, and the last isn't directly supported by the language. (But it's been a long time since I dabbled in Java.)

Like I said, I'm not totally convinced about the numerical benefits of round-ties-to-even for user-level round-to-n-decimal-places operations as opposed to FPU-level rounding (though I'm open to persuasion). That's partly because round-to-two-decimal-places (for example) is actually quite a peculiar operation to be doing on a binary float in the first place, and in practice ties don't really appear or affect the behaviour that often. (It might *look* as though you have a value "2.675" in your dataframe, but on a typical machine that value is actually being stored as "2.67499999999999982236431605997495353221893310546875", so it doesn't matter one whit whether you're using round-ties-to-even or round-ties-to-away: under correct rounding, both are going to give you the surprising result of 2.67 when you round to two decimal places).

What I really like about Python's choice is the consistency. In Python, since Python 3, all five cases of rounding described above use round-ties-to-even. In Python 2, float formatting used round-ties-to-even (most of the time in practice, though for Python 2.6 and earlier the exact behaviour depended on the system), while "round" used round-ties-to-away for a very closely-related operation, and there are bug reports and StackOverflow questions from users surprised by the discrepancy between float formatting and two-argument round. In Python 3, we have the pleasant situation that "round" and string formatting agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:55:58 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 18:55:58 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538074558.75.0.545547206417.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 994269ccee5574f03cda6b018399347fc52bf330 by Yury Selivanov in branch 'master':
bpo-34762: Update PyContext* to PyObject* in asyncio and decimal (GH-9609)
https://github.com/python/cpython/commit/994269ccee5574f03cda6b018399347fc52bf330


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 14:55:59 2018
From: report at bugs.python.org (Tim Peters)
Date: Thu, 27 Sep 2018 18:55:59 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538074559.23.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I should have spelled this out before:  these are all permutations, so in general permuting the result space of `x * mult + y` (or any other permutation involving x and y) is exactly the same as not permuting it but applying a different permutation to y instead.

Specifically, the sequence:

    x = x * mult + y  (mod 2**N)
    x = P(x)  # P is any permutation of N-bit integers

is the same as (and this isn't "deep" - it's trivial):

    x = x * mult + Q(y, x)  (mod 2**N)
    
where Q(y, x) = P(x * mult + y) - x * mult  (mod 2**N)

Q is a "richer" class of permutation though, because it's a different permutation for each fixed value of `x`, and uses multiplication to help disperse bits.

While it would take a lot of work to quantify this, in my experiments the tuple hash is significantly less touchy when permuting x after than when permuting y before, presumably because Q is richer.

The two tuple hash tests have many inputs whose tuple component hashes have very similar (even identical) bit patterns.  There's only so much dirt-simple permutations (like "y ^= y << 1") can do to break the patterns.  So, e.g., change a shift count, change the multiplier, ..., and at least one of those two tests fails depressingly often.  Not spectacularly, but over the limit they allow.  Q(y, x) does a far better job of magnifying small differences.

Something I haven't tried:  use a richer permutation of y that _doesn't_ depend on x.  For example, the frozenset hash has much the same underlying challenge, and uses this permutation to "blow up" small input differences:

static Py_uhash_t
_shuffle_bits(Py_uhash_t h)
{
    return ((h ^ 89869747UL) ^ (h << 16)) * 3644798167UL;
}

But that's a lot more expensive than a single shift-xor, and the speed of tuple hashing is more important than of frozenset hashing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:10:30 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:10:30 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538075430.89.0.545547206417.issue34762@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +9008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:30:16 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Sep 2018 19:30:16 +0000
Subject: [issue34533] Apply PEP384 to _csv module
In-Reply-To: <1535478304.23.0.56676864532.issue34533@psf.upfronthosting.co.za>
Message-ID: <1538076616.62.0.545547206417.issue34533@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

This is a duplicate of issue 14935. Could you please retarget PR 8977 against issue 14935?

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> PEP 384 Refactoring applied to _csv module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34533>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:33:29 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:33:29 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538076809.26.0.545547206417.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 24cb7de15d3a5979425b281ab4f600f7c2b401f2 by Yury Selivanov in branch '3.7':
[3.7] bpo-34762: Update PyContext* refs to PyObject* in asyncio and decimal (GH-9610)
https://github.com/python/cpython/commit/24cb7de15d3a5979425b281ab4f600f7c2b401f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:34:03 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Sep 2018 19:34:03 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538076843.16.0.545547206417.issue34802@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:35:15 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:35:15 +0000
Subject: [issue34762] Change contextvars C API to use PyObject
In-Reply-To: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>
Message-ID: <1538076915.56.0.545547206417.issue34762@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thank you Serhiy, for re-opening this!  I've pushed fixes to 3.7 and master branches.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34762>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:39:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:39:28 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077168.0.0.545547206417.issue34802@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +9009
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:42:03 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:42:03 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077323.12.0.545547206417.issue34802@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'll make a simple fix for the asyncio.coroutine decorator docs.

> I would suggest below for #coroutines :  

>> Coroutines declared with async/await syntax is the preferred way of writing asyncio applications but asyncio also supports legacy generator-based coroutines.

I don't want to further emphasize generator-based coroutines beyond how they are covered right now.  We'll drop support for them in a just a couple of versions anyways.

----------
assignee:  -> docs at python
components: +Documentation, asyncio
nosy: +docs at python
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:45:42 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Sep 2018 19:45:42 +0000
Subject: [issue7674] select.select() corner cases: duplicate fds,
 out-of-range fds
In-Reply-To: <1263192751.1.0.719382931138.issue7674@psf.upfronthosting.co.za>
Message-ID: <1538077542.58.0.545547206417.issue7674@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7674>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:48:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:48:34 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077714.01.0.545547206417.issue34802@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 59ee5b12938efbf534f2a19300a847bf6b23a77d by Yury Selivanov in branch 'master':
bpo-34802: Fix asyncio.iscoroutine() docs (GH-9611)
https://github.com/python/cpython/commit/59ee5b12938efbf534f2a19300a847bf6b23a77d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:48:44 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 19:48:44 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077724.97.0.545547206417.issue34802@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:53:22 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 19:53:22 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538078002.55.0.545547206417.issue34802@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 85ccedc5b57ddda198e7176ba787e3896435c504 by Miss Islington (bot) in branch '3.7':
bpo-34802: Fix asyncio.iscoroutine() docs (GH-9611)
https://github.com/python/cpython/commit/85ccedc5b57ddda198e7176ba787e3896435c504


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:54:38 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Sep 2018 19:54:38 +0000
Subject: [issue34248] dbm errors should contain file names
In-Reply-To: <1532698438.31.0.56676864532.issue34248@psf.upfronthosting.co.za>
Message-ID: <1538078078.36.0.545547206417.issue34248@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 9df346bf98069a87de14a3c2f69009d800994c63 by Berker Peksag (Zsolt Cserna) in branch 'master':
bpo-34248: Add filename to error raised in {gnu,ndbm}.open() (GH-8590)
https://github.com/python/cpython/commit/9df346bf98069a87de14a3c2f69009d800994c63


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34248>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:55:04 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Sep 2018 19:55:04 +0000
Subject: [issue34248] dbm errors should contain file names
In-Reply-To: <1532698438.31.0.56676864532.issue34248@psf.upfronthosting.co.za>
Message-ID: <1538078104.43.0.545547206417.issue34248@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34248>
_______________________________________

From report at bugs.python.org  Thu Sep 27 15:57:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:57:08 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538078228.42.0.545547206417.issue34802@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/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 16:20:44 2018
From: report at bugs.python.org (Gefn)
Date: Thu, 27 Sep 2018 20:20:44 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538079644.25.0.545547206417.issue34802@psf.upfronthosting.co.za>


Gefn <insomgla at gmail.com> added the comment:

I think it's much clearer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Thu Sep 27 16:36:23 2018
From: report at bugs.python.org (Jose Gama)
Date: Thu, 27 Sep 2018 20:36:23 +0000
Subject: [issue34777] urllib.request accepts anything as a header parameter
 for some URLs
In-Reply-To: <1537857504.82.0.545547206417.issue34777@psf.upfronthosting.co.za>
Message-ID: <327915814.549820.1538080574491@mail.yahoo.com>


Jose Gama <josephgama at yahoo.com> added the comment:

Thank you for the quick reply. You are correct about the difficulties of using a universally accepted list.This is one example that generates errors on the server side. Just for the record.

#!/usr/bin/env python3
from urllib.request import Request, urlopenfrom urllib.error import URLError
# process SSB dataurl1 = 'https://raw.githubusercontent.com/mapnik/test-data/master/csv/points.csv'url2 = 'https://gitlab.cncf.ci/kubernetes/kubernetes/raw/c69582dffba33e9f1c08ff2fc67924ea90f1448c/test/test_owners.csv'url3 = 'http://data.ssb.no/api/klass/v1/classifications/131/changes?from=2016-01-01&to=9999-12-31'headers1 = {'Accept': 'text/csv'}headers2 = {'Akcept': 'text/csv'}headers3 = {'Accept': 'tekst/cxv'}headers4 = {'Accept': '1234'}req = Request(url3, headers=headers4)resp = urlopen(req)content =? resp.read().decode(resp.headers.get_content_charset()) # get the character encoding from the server responseprint(content)
'''req = Request(url3, headers=headers3)
urllib.error.HTTPError: HTTP Error 500: Internal Server Error

req = Request(url3, headers=headers4)
urllib.error.HTTPError: HTTP Error 406: Not Acceptable'''

    On Tuesday, September 25, 2018, 8:38:26 AM GMT+2, Karthikeyan Singaravelan <report at bugs.python.org> wrote:  

Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. I tried similar requests and it works this way for other tools like curl since Akcept could be a custom header in some use cases though it could be a? typo in this context. There is no predefined set of media types that we need to validate as far as I can see from https://tools.ietf.org/html/rfc2616#section-14.1 and it depends on the server configuration to do validation. It's hard for Python to maintain a list of acceptable MIME types for validation across releases. A list of registered MIME types that is updated periodically : https://www.iana.org/assignments/media-types/media-types.xhtml and RFC for registration : https://tools.ietf.org/html/rfc6838

Some sample requests from curl with invalid headers.

curl -X GET https://httpbin.org/get -H 'Authorization: Token bc23f14356c114a8ffa319773583426878b7b37f' -H 'Cache-Control: no-cache' -H 'Content-Type: application/json' -H 'Akcept: tekst/csv'
{
? "args": {},
? "headers": {
? ? "Accept": "*/*",
? ? "Akcept": "tekst/csv",
? ? "Authorization": "Token bc23f14356c114a8ffa319773583426878b7b37f",
? ? "Cache-Control": "no-cache",
? ? "Connection": "close",
? ? "Content-Type": "application/json",
? ? "Host": "httpbin.org",
? ? "User-Agent": "curl/7.37.1"
? },
? "origin": "182.73.135.26",
? "url": "https://httpbin.org/get"
}

curl -X GET https://httpbin.org/get -H 'Authorization: Token bc23f14356c114a8ffa319773583426878b7b37f' -H 'Cache-Control: no-cache' -H 'Content-Type: application/json' -H 'Accept: tekst'
{
? "args": {},
? "headers": {
? ? "Accept": "tekst",
? ? "Authorization": "Token bc23f14356c114a8ffa319773583426878b7b37f",
? ? "Cache-Control": "no-cache",
? ? "Connection": "close",
? ? "Content-Type": "application/json",
? ? "Host": "httpbin.org",
? ? "User-Agent": "curl/7.37.1"
? },
? "origin": "182.73.135.26",
? "url": "https://httpbin.org/get"
}

Feel free to add in if I am missing something here but I think it's hard for Python to maintain the updated list and adding warning/error might break someone's code.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

From report at bugs.python.org  Thu Sep 27 16:47:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 20:47:57 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1538081277.38.0.545547206417.issue32956@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> the silent and subtle change in behaviour from Python 2 to Python 3 was a bit unpleasant, and a possible source of late-discovered (or undiscovered) bugs. 

This change was advertised in the "What?s New In Python 3.0" document.

https://docs.python.org/3/whatsnew/3.0.html#builtins

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Thu Sep 27 17:08:35 2018
From: report at bugs.python.org (Amos S)
Date: Thu, 27 Sep 2018 21:08:35 +0000
Subject: [issue34709] Suggestion: make getuser.getpass() also look at
 SUDO_USER environment variable
In-Reply-To: <1537160258.21.0.956365154283.issue34709@psf.upfronthosting.co.za>
Message-ID: <1538082515.09.0.545547206417.issue34709@psf.upfronthosting.co.za>


Amos S <amos.shapira at gmail.com> added the comment:

The use of environment variables like USER and LOGNAME instead of getuid() etc is done in order to try to get "who really initiated this process?" rather than "who this process belongs to?". This is hidden today when SUDO_USER is ignored.

This also fits my interpretation of the function's documentation: 'Return the "login name" of the user.'

For instance, in a system I use I have to sudo to a system user other than root in order to execute certain scripts and this patch would reveal the original user who executed the sudo command.

I updated the test case already in the existing PR.

I update to the documentation to list SUDO_USER.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34709>
_______________________________________

From report at bugs.python.org  Thu Sep 27 17:11:14 2018
From: report at bugs.python.org (paul j3)
Date: Thu, 27 Sep 2018 21:11:14 +0000
Subject: [issue32552] Improve text for file arguments in
 argparse.ArgumentDefaultsHelpFormatter class
In-Reply-To: <1515976536.21.0.467229070634.issue32552@psf.upfronthosting.co.za>
Message-ID: <1538082674.27.0.545547206417.issue32552@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

An alternative to customizing a HelpFormatter is to write your own utility `add_argument` function, e.g.

def my_add_argument(parser, *args, add_default=True, **kwargs):
    if add_default:
        help = kwargs.get('help','')
        help += ' (default: %(default)s)'
        kwargs['help'] = help
    return parser.add_argument(*args, **kwargs)

which could be used as

my_add_argument(parser, '-g', help='bar help', default='other', add_default=False)

There are some refinements to the _get_help_string() that I showed earlier, such as only adding the '%s' to actions where default makes sense (optionals and a subset positionals).  One could also skip it if the default is the default default None, etc.

One way or other the user can already control whether the help line shows the default.  ArgumentDefaultsHelpFormatter just automates this for a straight forward parser.  

I'm going to close this issue since it isn't really needed (and no one has proposed a clever patch).

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32552>
_______________________________________

From report at bugs.python.org  Thu Sep 27 18:58:54 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Sep 2018 22:58:54 +0000
Subject: [issue34826] io.BufferedReader crashes in 2.7 on memoryview attribute
 access
Message-ID: <1538089134.67.0.545547206417.issue34826@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

The following test code segfaults on Python 2.7:

```python
import io
class X(io.RawIOBase):
  def readable(self):
    return True
  def readinto(self, b):
    if isinstance(b, memoryview):
      print(b.format)  # XXX boom, crashes here.
    return 0

io.BufferedReader(X()).read(8)
```

The crash happens on the b.format attribute access.

This does not happen on 3.6.

----------
components: IO, Library (Lib)
messages: 326597
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: io.BufferedReader crashes in 2.7 on memoryview attribute access
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34826>
_______________________________________

From report at bugs.python.org  Thu Sep 27 19:21:42 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 27 Sep 2018 23:21:42 +0000
Subject: [issue34826] io.BufferedReader crashes in 2.7 on memoryview attribute
 access
In-Reply-To: <1538089134.67.0.545547206417.issue34826@psf.upfronthosting.co.za>
Message-ID: <1538090502.76.0.545547206417.issue34826@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

See #27195 and PR 8415.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34826>
_______________________________________

From report at bugs.python.org  Thu Sep 27 20:24:40 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 28 Sep 2018 00:24:40 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538094280.01.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +9012

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 20:24:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 28 Sep 2018 00:24:41 +0000
Subject: [issue34521] test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail
 on AMD64 FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538094281.48.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +9012, 9013

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Thu Sep 27 21:14:31 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 01:14:31 +0000
Subject: [issue34818] test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7
 with AttributeError: __exit__
In-Reply-To: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>
Message-ID: <1538097271.06.0.545547206417.issue34818@psf.upfronthosting.co.za>


Dimitri John Ledkov <dimitri.j.ledkov at intel.com> added the comment:

Similar client sockets are used in that file, but they are wrapped in extra `with closing(...) as s:`

Is closing() wrapper missing in this test case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34818>
_______________________________________

From report at bugs.python.org  Thu Sep 27 22:10:14 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 28 Sep 2018 02:10:14 +0000
Subject: [issue18578] Rename and document test.bytecode_helper as
 test.support.bytecode_helper
In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za>
Message-ID: <1538100614.52.0.545547206417.issue18578@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@seydou, would you be interested in making a GitHub pull request for your patch?

----------
assignee:  -> docs at python
components: +Documentation, Tests
nosy: +cheryl.sabella, docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.8 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18578>
_______________________________________

From report at bugs.python.org  Thu Sep 27 22:59:51 2018
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 28 Sep 2018 02:59:51 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538103591.95.0.545547206417.issue34521@psf.upfronthosting.co.za>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

To clarify affected tests/versions:

Python 3.x - test_socket test_multiprocessing_spawn
Python 2.7 - test_multiprocessing_spawn

All of the issues are related to incorrect recvmsg(2) buffer length use, so I've amended the issue summary to describe the complete root problem.

The be explicit,

- test_socket fix requires backporting to all supported 3.x branches
- test_multiprocessing_* test fixes (via multiprocessing.reduction fix) requires backporting to all supported 3.x branches *and* 2.7

----------
title: test_socket.Recvmsg[Into]SCMRightsStreamTest tests fail on AMD64 FreeBSD CURRENT -> Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 00:20:03 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Sep 2018 04:20:03 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538108403.73.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Perhaps worth noting that FNV-1a works great if used as _intended_:  on a stream of unsigned bytes.  All tests except the new tuple hash test suffer no collisions; the new test suffers 14.  Nothing is needed to try to worm around nested tuple catastrophes, or to worm around mixing integers of similar magnitude but different signs.  The obvious downside:  on a 64-bit box, it's 8 times as many multiplies :-(  Here's a 64-bit version:

    Py_uhash_t t = (Py_uhash_t)y;
    for (int i = 0; i < sizeof(t); ++i) {
        x = (x ^ (t & 0xff)) * (Py_uhash_t)1099511628211ULL;
        t >>= 8;
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 28 00:43:07 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Sep 2018 04:43:07 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538109787.39.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Also worth noting:  other projects need to combine hashes too.  Here's a 64-bit version of the highly regarded C++ Boost[1] library's hash_combine() function (I replaced its 32-bit int literal with "a random" 64-bit one):

    x ^= (Py_uhash_t)y + 0x94ae1875aa5647f1UL + (x << 6) + (x >> 2);

It's very cheap.  It also sucks horribly if used as the guts Python's tuple hash loop ;-)

This isn't a paradox.  Best I can tell, Python may be unique in trying _not_ to make all hashes "look random".  If you have only randomish hashes to combine, the Boost approach works fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 28 01:21:02 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 05:21:02 +0000
Subject: [issue34777] urllib.request accepts anything as a header parameter
 for some URLs
In-Reply-To: <1537718868.74.0.956365154283.issue34777@psf.upfronthosting.co.za>
Message-ID: <1538112062.44.0.545547206417.issue34777@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the details. Each server behaves differently for these headers which depends on the server configuration and using other client like curl will also return the same result as Python does. So I would propose closing it as not a bug since there is no bug with Python and it behaves like other clients do.

Thanks again for the report!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

From report at bugs.python.org  Fri Sep 28 01:22:23 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 05:22:23 +0000
Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format
In-Reply-To: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za>
Message-ID: <1538112143.22.0.545547206417.issue27195@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27195>
_______________________________________

From report at bugs.python.org  Fri Sep 28 01:22:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 05:22:33 +0000
Subject: [issue34826] io.BufferedReader crashes in 2.7 on memoryview attribute
 access
In-Reply-To: <1538089134.67.0.545547206417.issue34826@psf.upfronthosting.co.za>
Message-ID: <1538112153.83.0.545547206417.issue34826@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34826>
_______________________________________

From report at bugs.python.org  Fri Sep 28 01:44:33 2018
From: report at bugs.python.org (Micheal Taylor)
Date: Fri, 28 Sep 2018 05:44:33 +0000
Subject: [issue34827] Make argparse.NameSpace iterable
Message-ID: <1538113473.95.0.545547206417.issue34827@psf.upfronthosting.co.za>


New submission from Micheal Taylor <bubthegreat at gmail.com>:

There was an issue to make argparse.Namespace iterable with a specific intent on being able to convert it to a dictionary (https://bugs.python.org/issue8982).  Additionally there was another improvement request to make it accessible like a dictionary.  (https://bugs.python.org/issue8979)

While vars(args) and args.thing do accomplish the needs, I'm really lazy, and would like the object to be more accessible - for instance, if I will always need to access every attribute (because I make a small namespace that fits a simple script, making it iterable would be convenient.  It's also more convenient to use the typical **thing syntax for passing it into functions if all the attributes are required for different things.  This keeps code within the functions that would use it simpler, because we no longer need to reference args.thing, we can reference thing directly within the function it's been passed to.  vars(args) does accomplish this, but it is arguably not as familiar for folks as the more "familiar" syntax of **args.

----------
components: Library (Lib)
messages: 326605
nosy: bubthegreat
priority: normal
severity: normal
status: open
title: Make argparse.NameSpace iterable
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34827>
_______________________________________

From report at bugs.python.org  Fri Sep 28 01:57:33 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 05:57:33 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1538114253.94.0.545547206417.issue34736@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1fba2ffc37da52c08db51fe4360459990b0311c9 by Miss Islington (bot) (Tal Einat) in branch 'master':
bpo-34736: improve error message for invalid length b64decode inputs (GH-9563)
https://github.com/python/cpython/commit/1fba2ffc37da52c08db51fe4360459990b0311c9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Fri Sep 28 01:57:36 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 05:57:36 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1538114256.92.0.545547206417.issue34736@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:08:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Sep 2018 06:08:56 +0000
Subject: [issue34827] Make argparse.NameSpace iterable
In-Reply-To: <1538113473.95.0.545547206417.issue34827@psf.upfronthosting.co.za>
Message-ID: <1538114936.03.0.545547206417.issue34827@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

issue8982 is not about making argparse.Namespace iterable, it is about better documenting it.

issue8979 was rejected for several reasons which are still valid.

For making **args working, args shouldn't be iterable, it should have the keys() method. And this will conflict with the --keys option.

Python is not a JavaScript. Objects and dictionaries are different things here. If you want to convert argparse.Namespace to dict, vars(args) is the One Obvious Way. It is officially documented.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34827>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:12:58 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 06:12:58 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1538115178.08.0.545547206417.issue34736@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7e35081bc828291da5793db49ab45dee4fda5043 by Miss Islington (bot) in branch '3.7':
bpo-34736: improve error message for invalid length b64decode inputs (GH-9563)
https://github.com/python/cpython/commit/7e35081bc828291da5793db49ab45dee4fda5043


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:14:40 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 28 Sep 2018 06:14:40 +0000
Subject: [issue34736] Confusing base64.b64decode output
In-Reply-To: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>
Message-ID: <1538115280.58.0.545547206417.issue34736@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks, Mark!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34736>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:27:41 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 28 Sep 2018 06:27:41 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1538116061.53.0.545547206417.issue34776@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:51:55 2018
From: report at bugs.python.org (Joel Klimont)
Date: Fri, 28 Sep 2018 06:51:55 +0000
Subject: [issue34828] sqlite.iterdump does not work for (most) databases with
 autoincrement
Message-ID: <1538117515.33.0.545547206417.issue34828@psf.upfronthosting.co.za>


New submission from Joel Klimont <joel.klimont at gmail.com>:

There is a bug in sqlite3/dump.py when wanting to dump databases that use autoincrement in one or more tables.

The problem is that the iterdump command assumes that the table "sqlite_sequence" is present in the new database in which the old one is dumped into.

>From the sqlite3 documentation:
"SQLite keeps track of the largest ROWID using an internal table named "sqlite_sequence". The sqlite_sequence table is created and initialized automatically whenever a normal table that contains an AUTOINCREMENT column is created. The content of the sqlite_sequence table can be modified using ordinary UPDATE, INSERT, and DELETE statements."
Source: https://sqlite.org/autoinc.html#the_autoincrement_keyword

Example:
BEGIN TRANSACTION;
CREATE TABLE "posts" (
    id int primary key
);
INSERT INTO "posts" VALUES(0);
CREATE TABLE "tags" (
    id integer primary key autoincrement,
    tag varchar(256) unique,
    post int references posts
);
INSERT INTO "tags" VALUES(NULL, "test", 0);
COMMIT;

The following code should work but because of the assumption that "sqlite_sequence" exists it will fail:

>> import sqlite3
>> cx = sqlite3.connect("test.db")
>> for i in cx.iterdump():
>>    print i
>> cx2 = sqlite3.connect(":memory:")
>> query = "".join(line for line in cx.iterdump())
>> cx2.executescript(query)

Exception:
Traceback (most recent call last):
  File "/home/test.py", line 10, in <module>
    cx2.executescript(query)
sqlite3.OperationalError: no such table: sqlite_sequence

Here is the ouput of cx.iterdrump()
BEGIN TRANSACTION;
CREATE TABLE "posts" (
    id int primary key
);
INSERT INTO "posts" VALUES(0);
DELETE FROM "sqlite_sequence";
INSERT INTO "sqlite_sequence" VALUES('tags',1);
CREATE TABLE "tags" (
    id integer primary key autoincrement,
    tag varchar(256) unique,
    post int references posts
);
INSERT INTO "tags" VALUES(1,'test',0);
COMMIT;

As you can see the problem is that "DELETE FROM "sqlite_sequence";" and "INSERT INTO "sqlite_sequence" VALUES('tags',1);" are put into the dump before that table even exists. They should be put at the end of the transaction. (Like the sqlite3 command ".dump" does.)
Note that some databases that use autoincrement will work as it could be that a table with autoincrement is created before the sqlite_sequence commands are put into the dump.

File: https://github.com/python/cpython/blob/master/Lib/sqlite3/dump.py

I have already forked the repository, written tests etc. and if you want I will create a pull request.

----------
components: Library (Lib)
messages: 326610
nosy: itssme
priority: normal
severity: normal
status: open
title: sqlite.iterdump does not work for (most) databases with autoincrement
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/issue34828>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:56:33 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 28 Sep 2018 06:56:33 +0000
Subject: [issue34828] sqlite.iterdump does not work for (most) databases with
 autoincrement
In-Reply-To: <1538117515.33.0.545547206417.issue34828@psf.upfronthosting.co.za>
Message-ID: <1538117793.66.0.545547206417.issue34828@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> I have already forked the repository, written tests etc. and if you
> want I will create a pull request.

Please do!

Note that 3.4 and 3.5 are in security-fix-only mode and let's decide whether fixing 2.7 is worth the trouble when you submit your PR. Thank you!

----------
nosy: +berker.peksag
stage:  -> needs patch
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34828>
_______________________________________

From report at bugs.python.org  Fri Sep 28 02:58:36 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Sep 2018 06:58:36 +0000
Subject: [issue34818] test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7
 with AttributeError: __exit__
In-Reply-To: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>
Message-ID: <1538117916.08.0.545547206417.issue34818@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Yes, that's it. In Python 2.7, socket classes don't implement the context manager protocol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34818>
_______________________________________

From report at bugs.python.org  Fri Sep 28 03:09:02 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Sep 2018 07:09:02 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1538118542.11.0.545547206417.issue32956@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This change was advertised in the "What?s New In Python 3.0" document.

Not originally, it wasn't. That information was added later, by me. :-) [1]

In any case, I wasn't referring to documentation. I meant "silent" in the runtime-sense: there was no run-time error or warning associated with the behaviour change (in contrast to the `print` function change, for example). Few people read the "what's new" documents, and someone who's written Python 2 code using round has no particular reason to suspect a behaviour change, and no visible indication that such a change has occurred, when porting their code to Python 3. Nevertheless, their numerical results may be slightly different as a result of the porting. Hence the potential for late-discovered bugs.

[1] https://github.com/python/cpython/commit/f4112e2653f310b6e6a210c659648dbe45d3a042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Fri Sep 28 03:16:41 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 28 Sep 2018 07:16:41 +0000
Subject: [issue32956] python 3 round bug
In-Reply-To: <1519658635.56.0.467229070634.issue32956@psf.upfronthosting.co.za>
Message-ID: <1538119001.73.0.545547206417.issue32956@psf.upfronthosting.co.za>


Change by Nathaniel Smith <njs at pobox.com>:


----------
nosy:  -njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32956>
_______________________________________

From report at bugs.python.org  Fri Sep 28 03:54:37 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Sep 2018 07:54:37 +0000
Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format
In-Reply-To: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za>
Message-ID: <1538121277.08.0.545547206417.issue27195@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +9015

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27195>
_______________________________________

From report at bugs.python.org  Fri Sep 28 04:37:55 2018
From: report at bugs.python.org (Juliette Monsel)
Date: Fri, 28 Sep 2018 08:37:55 +0000
Subject: [issue34829] Add missing selection_ methods to tkinter Spinbox
Message-ID: <1538123875.3.0.545547206417.issue34829@psf.upfronthosting.co.za>


New submission from Juliette Monsel <j_4321 at protonmail.com>:

Though the text area of the tkinter Spinbox behaves like an Entry, the methods selection_from, selection_range, selection_present and selection_to have not been implemented. So for consistency with the Entry widget, I suggest to add them.

----------
components: Tkinter
messages: 326614
nosy: j-4321-i
priority: normal
severity: normal
status: open
title: Add missing selection_ methods to tkinter Spinbox
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34829>
_______________________________________

From report at bugs.python.org  Fri Sep 28 04:46:38 2018
From: report at bugs.python.org (Juliette Monsel)
Date: Fri, 28 Sep 2018 08:46:38 +0000
Subject: [issue34829] Add missing selection_ methods to tkinter Spinbox
In-Reply-To: <1538123875.3.0.545547206417.issue34829@psf.upfronthosting.co.za>
Message-ID: <1538124398.74.0.545547206417.issue34829@psf.upfronthosting.co.za>


Change by Juliette Monsel <j_4321 at protonmail.com>:


----------
keywords: +patch
pull_requests: +9016
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34829>
_______________________________________

From report at bugs.python.org  Fri Sep 28 04:48:08 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 28 Sep 2018 08:48:08 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538124488.05.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Replacing DJBX33A's multiplier of 33 is also a different algorithm.  So is working with inputs other than unsigned bytes.

I would argue that this is just extending the parameters of the algorithm. If the algorithm is general enough, then that shouldn't be a problem.

> So is mucking with the inputs before adding them in.

Not really. If you consider it an algorithm for hashing a sequence, that is just changing the input sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:05:39 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Sep 2018 09:05:39 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1538125539.72.0.545547206417.issue34369@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I think removing all mention of ?None? is a step too far. The ?devpoll?, ?epoll?, and ?poll? documentation all say that ?None? is acceptable for the timeout. Only the ?select? function doesn?t say this.

What about adding to the text:

* ?timeout? in seconds (floats possible); the default is ?None?, to wait forever

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:20:44 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:20:44 +0000
Subject: [issue34830] functools.partial is weak referncable
Message-ID: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

According to the doc:

    :class:`partial` objects are like :class:`function` objects in that they are callable, weak referencable, and can have attributes.

I don't understand why "weak" here, and it's the only occurence of "weak referencable" in the documentation.

I don't see an object in Python being referencable but NOT weak referencable, do I miss something obvious here?

----------
assignee: docs at python
components: Documentation
messages: 326617
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: functools.partial is weak referncable
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:29:52 2018
From: report at bugs.python.org (Jose Gama)
Date: Fri, 28 Sep 2018 09:29:52 +0000
Subject: [issue34777] urllib.request accepts anything as a header parameter
 for some URLs
In-Reply-To: <1538112062.44.0.545547206417.issue34777@psf.upfronthosting.co.za>
Message-ID: <837072876.809527.1538126985241@mail.yahoo.com>


Jose Gama <josephgama at yahoo.com> added the comment:

Yes, I agree, it's not a bug.This note might help other people who run into the same questions, particularly with error handling.Thank you!
    On Friday, September 28, 2018, 7:21:03 AM GMT+2, Karthikeyan Singaravelan <report at bugs.python.org> wrote:  

Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the details. Each server behaves differently for these headers which depends on the server configuration and using other client like curl will also return the same result as Python does. So I would propose closing it as not a bug since there is no bug with Python and it behaves like other clients do.

Thanks again for the report!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:36:27 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 28 Sep 2018 09:36:27 +0000
Subject: [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127387.06.0.545547206417.issue34830@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

```

In [1]: import weakref                                                                                                    

In [2]: class A: 
   ...:     __slots__ = ()                                                                                                

In [3]: weakref.ref(A())                                                                                                  
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-60f73a442704> in <module>
----> 1 weakref.ref(A())

TypeError: cannot create weak reference to 'A' object

```

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:38:24 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 28 Sep 2018 09:38:24 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1538127504.9.0.545547206417.issue34369@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I agree Martin, I hadn't noticed that the docs don't otherwise mention the default behavior WRT timeout.

I've added a description as per your suggestion to the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:41:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 09:41:07 +0000
Subject: [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127667.69.0.545547206417.issue34830@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:42:26 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:42:26 +0000
Subject: [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127746.06.0.545547206417.issue34830@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

TIL.

So it really make sense in this context to tell a functools.partial is weak referencable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:43:14 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 28 Sep 2018 09:43:14 +0000
Subject: [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127794.41.0.545547206417.issue34830@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I think yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:43:58 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:43:58 +0000
Subject: [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127838.53.0.545547206417.issue34830@psf.upfronthosting.co.za>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:50:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Sep 2018 09:50:15 +0000
Subject: [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538128215.34.0.545547206417.issue34830@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Instances of many builtin types are not weak referencable.

>>> weakref.ref(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'int' object
>>> weakref.ref([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'list' object

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34830>
_______________________________________

From report at bugs.python.org  Fri Sep 28 05:51:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 09:51:10 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538128270.11.0.545547206417.issue34521@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 077061a7b24917aaf31057885c69919c5a553c88 by Victor Stinner (Pablo Galindo) in branch 'master':
bpo-34521: Fix tests in test_multiprocessing_spawn to use correctly CMSG_SPACE (GH-9613)
https://github.com/python/cpython/commit/077061a7b24917aaf31057885c69919c5a553c88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 06:09:40 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 10:09:40 +0000
Subject: [issue34777] urllib.request accepts anything as a header parameter
 for some URLs
In-Reply-To: <1537718868.74.0.956365154283.issue34777@psf.upfronthosting.co.za>
Message-ID: <1538129380.87.0.545547206417.issue34777@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sure, thanks for the confirmation. Closing it as not a bug.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34777>
_______________________________________

From report at bugs.python.org  Fri Sep 28 06:34:46 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Sep 2018 10:34:46 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1538130886.53.0.545547206417.issue25095@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Hi William, when I mentioned ?Content-Length?, I meant adding it to the response from the server. See the second version of ?do_GET? in my earlier comment <https://bugs.python.org/issue25095#msg309522>. But that is no good without also adding the ?self.con.close()? line to the client I mentioned in two of my other comments.

In your latest rev. e6b09d4 (and earlier rev. 2022b6f) you send ?Content-Length: 0? in a GET _request_, which doesn?t make much sense. GET requests never have bodies of any length. It is the ?200 OK? _response_ that should have a body according to HTTP. The server has to shut down the connection or add ?Content-Length: 0? (or use chunked encoding) to indicate the end of the body to the proxy.

So I would prefer to either adjust the ?do_GET? server function as well as adding ?self.con.close()? to the client, or just go back to rev. c1afa6b (?Connection: close?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Sep 28 07:01:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Sep 2018 11:01:03 +0000
Subject: [issue34829] Add missing selection_ methods to tkinter Spinbox
In-Reply-To: <1538123875.3.0.545547206417.issue34829@psf.upfronthosting.co.za>
Message-ID: <1538132463.54.0.545547206417.issue34829@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34829>
_______________________________________

From report at bugs.python.org  Fri Sep 28 07:13:46 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 11:13:46 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538133226.32.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9017

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 07:13:54 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 11:13:54 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538133234.74.0.545547206417.issue34521@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9018

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 07:20:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 11:20:34 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1538133634.58.0.545547206417.issue25095@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Fri Sep 28 07:31:56 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 11:31:56 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538134316.56.0.545547206417.issue34521@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5d33ee1595767d68800fda13bc68b7b01dba5117 by Miss Islington (bot) in branch '3.6':
bpo-34521: Fix tests in test_multiprocessing_spawn to use correctly CMSG_SPACE (GH-9613)
https://github.com/python/cpython/commit/5d33ee1595767d68800fda13bc68b7b01dba5117


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 07:36:17 2018
From: report at bugs.python.org (Caleb Hattingh)
Date: Fri, 28 Sep 2018 11:36:17 +0000
Subject: [issue34831] Asyncio Tutorial
Message-ID: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>


New submission from Caleb Hattingh <caleb.hattingh at gmail.com>:

Hi Yury,

As discussed, below is a very rough outline of a proposed TOC for an asyncio tutorial. No content has been written yet (only what you see below). I think we should nail down the TOC first.

Asyncio Tutorial
================

Proposed Table of Contents:

- Why asyncio?
    - Reason #1: thread safety by not using threads at all.
    - Reason #2: very many concurrent socket connections, which threads
      make cumbersome.
    - Demo: concurrency without threads
        - (only goals here are to *briefly* introduce the syntax, and then
          demonstrate concurrency without threads)
        - show two tasks, one prints out integers 0-9, while the other
          prints out letters of the alphabet, A-I.
        - pose the question: "they're running concurrently but we're
          not using threads: how is that possible?"
        - explain that there is a thing called an "event loop" behind
          the scenes that allows execution to switch between the two
          every time one of them "waits".
        - emphasize that you can easily spot where the switch can happen,
          it is where you see the "await" keyword. Switches will occur
          nowhere else.

- The difference between functions and `async def` functions
    - async & await
        - show `async def` functions, compare to `def` functions.  
        - use inspect module to show what things actually are, e.g. function,
          coroutine function, coroutine, generator function, generator,
          asynchronous generator function, asynchronous generator.
        - point out you can only use "await" inside an async def fn
        - point out that `await <x>` is an expression, and you can
          use it in most places any other expression can be used.

- How to run `async def` functions
    - point out there are two different issues: (a) `async def` functions
      can call other functions, and other `async def` functions using
      `await`, but also, (b) how to "get started" with the first
      `async def` function? Answer: run the event loop.
    - show `asyncio.run()`, in particular running an `async def main()`
      function, which itself can call others.

- Dealing with concurrent functions
    - (This is maybe too similar to the new docs in the section
      https://docs.python.org/3/library/asyncio-task.html?highlight=asyncio%20run#coroutines-and-tasks)
    - What if you want to run an `async def` function, but you don't
      want to wait for it? Answer: create a "task" for it.
    - What if you want to run multiple functions concurrently, and you
      do want to wait for all of them to finish? Answer: use `gather`
      or `wait()`

- Case Study: chat server/client (my proposal)
    - (goal is to walk through building a realistic example of using 
      asyncio)
    - (This will be a lot more fun than a web-crawler. Web-crawlers are
      super boring!)
    - (I'm pretty confident the size of the code can be kept small. A 
      lot can be done in under 50 lines, as I showed in the case studies
      in my book)
    - server uses streams API
    - server receives many long-lived connections
    - user can create/join a "room", and then start typing messages.
      Other connected clients in the same room will see the messages.
    - client implementation has some options:
        - could use Tkinter gui, using streams API in an event loop 
          on a separate thread. (This would show how asyncio isn't some 
          alien thing, but is part of python. Would also show how to 
          set up asyncio to work in a separate thread. Finally, would not
          require any external dependencies, only the stdlib is needed
          for the entire case study.)
        - could use a browser client, connecting back to the server 
          over a websocket connection. (This might seem simpler, but 
          in fact introduces a lot more complexity than just using
          tkinter. We need to bring in html, css, probably some js and
          probably also a third-party websockets python library. I feel
          like it isn't a good fit for a stdlib python tutorial, but it 
          is a more modern approach.)
        - there are not a lot of other options. terminal-based client 
          might be possible, but probably hard, not cross-platform, and 
          will be unappealing to many people. 
    - When describing the code, point out:
        - you have to choose a "message protocol" (size-prefixed is fine)
        - you must put `send` and `recv` in separate tasks
        - server will "keep track" of connected clients and the room
          (or rooms?) they've joined
        - startup and shutdown, specific references to the new `run()`
          function
        - <others>?

----------
assignee: docs at python
components: Documentation, asyncio
messages: 326628
nosy: asvetlov, cjrh, docs at python, willingc, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio Tutorial
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34831>
_______________________________________

From report at bugs.python.org  Fri Sep 28 08:15:36 2018
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 28 Sep 2018 12:15:36 +0000
Subject: [issue34810] Maximum and minimum value of C types integers from Python
In-Reply-To: <1537972326.01.0.545547206417.issue34810@psf.upfronthosting.co.za>
Message-ID: <1538136936.9.0.545547206417.issue34810@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

What is the use case for getting the maximum and minimum of the fixed bit integers like `uint8`? It's a trivial formula to calculate those.

Now, if you're talking about platform dependent types like `int` and `long` then it might makes more sense to add such an api. Or is your end goal to just have an exception be raised when trying to fit a large number in a small type like in your example?

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34810>
_______________________________________

From report at bugs.python.org  Fri Sep 28 08:20:13 2018
From: report at bugs.python.org (Michael Harris)
Date: Fri, 28 Sep 2018 12:20:13 +0000
Subject: [issue34832] "Short circuiting" in base64's b64decode, decode,
 decodebytes
Message-ID: <1538137213.36.0.545547206417.issue34832@psf.upfronthosting.co.za>


New submission from Michael Harris <pw.michael.harris at gmail.com>:

When given an invalid base64 string that starts with a valid base64 substring, the functions will return the decoded bytes only up to the substring rather then ignoring the non-alphabet character.

Examples:
>>> base64.b64decode("AAAAAAAA")
b'\x00\x00\x00\x00\x00\x00'
>>> base64.b64decode("AA=AAAAAA")
b'\x00\x00\x00\x00\x00\x00'
>>> base64.b64decode("AAA=AAAAA")
b'\x00\x00'

----------
components: Library (Lib)
messages: 326630
nosy: pw.michael.harris
priority: normal
severity: normal
status: open
title: "Short circuiting" in base64's b64decode, decode, decodebytes
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34832>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:04:27 2018
From: report at bugs.python.org (Joel Klimont)
Date: Fri, 28 Sep 2018 13:04:27 +0000
Subject: [issue34828] sqlite.iterdump does not work for (most) databases with
 autoincrement
In-Reply-To: <1538117515.33.0.545547206417.issue34828@psf.upfronthosting.co.za>
Message-ID: <1538139867.41.0.545547206417.issue34828@psf.upfronthosting.co.za>


Change by Joel Klimont <joel.klimont at gmail.com>:


----------
keywords: +patch
pull_requests: +9019
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34828>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:07:11 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Sep 2018 13:07:11 +0000
Subject: [issue34817] Ellipsis docs has extra dot in the markdown that makes
 it look like .... (four dots)
In-Reply-To: <1538032499.31.0.545547206417.issue34817@psf.upfronthosting.co.za>
Message-ID: <1538140031.41.0.545547206417.issue34817@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

In these situations, I use quotes or brackets to mention a symbol without using it as punctuation. Using words might also help. What about:

Ellipsis
  The same as the ellipsis literal ?...?. Special value used [etc]

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34817>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:08:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 13:08:01 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538140081.15.0.545547206417.issue34521@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 007fda436f707ac95c2fa8f8886efd9e09d5b630 by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-34521: Fix tests in test_multiprocessing_spawn to use correctly CMSG_SPACE (GH-9613) (GH-9619)
https://github.com/python/cpython/commit/007fda436f707ac95c2fa8f8886efd9e09d5b630


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:09:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 13:09:48 +0000
Subject: [issue34833] [CI] Azure Pipeline: Initialize Agent failed
Message-ID: <1538140188.61.0.545547206417.issue34833@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Error: "Initialize Agent failed". Sorry... I don't see any additional information, only this error message...

Failed build:
https://python.visualstudio.com/cpython/_build/results?buildId=31597&view=logs

Source:
https://github.com/python/cpython/pull/9619

It's not the first time that I see this issue.

----------
components: Tests
messages: 326633
nosy: steve.dower, vstinner
priority: normal
severity: normal
status: open
title: [CI] Azure Pipeline: Initialize Agent failed
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34833>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:11:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 13:11:14 +0000
Subject: [issue34833] [CI] Azure Pipeline: Initialize Agent failed
In-Reply-To: <1538140188.61.0.545547206417.issue34833@psf.upfronthosting.co.za>
Message-ID: <1538140274.01.0.545547206417.issue34833@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Ah, I found more info:

##[Error 1]
The agent: Hosted Agent lost communication with the server. Verify the machine is running and has a healthy network connection. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610 

##[Error 2]
The request was failed due to an internal service error. Please try again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34833>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:11:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 13:11:20 +0000
Subject: [issue34833] [CI] Azure Pipeline: Initialize Agent failed
In-Reply-To: <1538140188.61.0.545547206417.issue34833@psf.upfronthosting.co.za>
Message-ID: <1538140280.36.0.545547206417.issue34833@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34833>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:12:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 13:12:17 +0000
Subject: [issue34521] Multiple tests (test_socket,
 test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer
 lengths, causing failures on FreeBSD CURRENT
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1538140336.99.0.545547206417.issue34521@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Pablo: I merged your PR on master, and backport it to 3.6 and 3.7. But I let you handle 2.7, since I expect a conflict :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:23:34 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Sep 2018 13:23:34 +0000
Subject: [issue34818] test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7
 with AttributeError: __exit__
In-Reply-To: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>
Message-ID: <1538141014.4.0.545547206417.issue34818@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +9020
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34818>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:39:09 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Sep 2018 13:39:09 +0000
Subject: [issue34771] test_ctypes failing on Linux SPARC64
In-Reply-To: <1537638972.94.0.956365154283.issue34771@psf.upfronthosting.co.za>
Message-ID: <1538141949.13.0.545547206417.issue34771@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Seems to be a common theme on various 64-bit ABIs. There is already a fix for Python?s Windows copy of the FFI library (Issue 29565), and a ?hack? for Arm and x86 Windows (again!): Issue 30353.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34771>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:50:56 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 28 Sep 2018 13:50:56 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538142656.93.0.545547206417.issue12782@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee:  -> pablogsal
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Sep 28 09:50:45 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 28 Sep 2018 13:50:45 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538142645.37.0.545547206417.issue12782@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This was closed without enough explanation. Suggesting people should use ExitStack due to a Python grammar deficiency is suboptimal to say the least.

This problem is coming back to users of Black due to Black's removal of backslashes. It's the only piece of our grammar where backslashes are required for readability which shows there's something wrong.

The syntax ambiguity that Nick is raising fortunately shouldn't be a problem because a single tuple is an invalid context manager. In other contexts if the organizational parentheses are matched by the with-statement and not by the underlying `test`, that's also fine since they were organizational this doesn't make the `test` invalid.

Pablo has a working patch for this, we intend to fix this wart for Python 3.8.

----------
nosy: +lukasz.langa
resolution: wont fix -> 
stage:  -> patch review
status: closed -> open
versions: +Python 3.8 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Sep 28 10:20:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 14:20:48 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1538144448.26.0.545547206417.issue34022@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> https://github.com/python/cpython/pull/9607 turns SOURCE_DATE_EPOCH into a *default* rather than absolute override.

Once we decided to merge or reject this PR, we should maybe update the PEP 552 to clarify the interaction with the SOURCE_DATE_EPOCH environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Fri Sep 28 10:48:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Sep 2018 14:48:19 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538146099.41.0.545547206417.issue12782@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Especially since the dynamic flexibility of ExitStack comes at a genuine runtime cost when unwinding the resource stack.

I also (very!) belatedly noticed that I never answered Julian's request for clarification about the potential grammar ambiguity, so going into detail about that now:

The first item in the grammar after the 'with' keyword is a 'test' node, which can already start with a parenthesis, which means a naive attempt at allowing grouping parentheses will likely fail to generate a valid LL(1) parser.

That doesn't mean a more sophisticated change isn't possible (and Pablo has apparently implemented one) - it just means that the required grammar update is going to be more complicated than just changing:

    with_stmt: 'with' with_item (',' with_item)*  ':' suite

to be:

    with_stmt: 'with' (with_items | '(' with_items ')') ':' suite
    with_items: with_item (',' with_item)*

(That would need too much lookahead to decide whether an opening parenthesis belongs to the first 'with_item' in 'with_items' or if it's starting the alternative multi-line grouping construct)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Sep 28 10:49:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 14:49:05 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1538146145.77.0.545547206417.issue34687@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +9021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Fri Sep 28 11:38:53 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 28 Sep 2018 15:38:53 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538149133.04.0.545547206417.issue34751@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I spent about 2 days doing an extensive study of the FNV and DJB algorithms. I share my conclusions below.

To be very clear what I mean, I am talking about the following algorithms (t is a tuple and m is the multiplier which is always assumed to be odd).

def FNV(t, m):
    h = 1
    for x in t:
        h = ((h * m) ^ x) % 2**32
    return h

def DJB(t, m):
    h = 1
    for x in t:
        h = ((h * m) + x) % 2**32
    return h

I am restricting to 32 bits because we need to support that anyway and because it's computationally easier than 64 bits.

I took the point of view of fixing two different tuples t and u and then seeing for which multipliers m a collision hash(t, m) == hash(u, m) occurs. Since the lower k bits of the hash depend only on the lower k bits of the multiplier, it is actually feasible to list all m's for which there is a collision; I wrote a C program to do that. Note that there are 2**31 possible odd multipliers and 2**32 different possible hash values: so you expect about 0.5 collisions on average.

For the entries of the tuples, I took random integers in the range from 0 to 63 (so the issue with negative numbers in FNV does not occur). I mostly considered tuples of length 4, 5 and 6.

It turns out that both algorithms have pairs (t, u) for which a massive number of collisions occur:

- For FNV, the tuples (12, 50, 52, 24, 3), (28, 18, 52, 56, 19) have 2**26 collisions (all multipliers with lower byte 0x01, 0x7f, 0x81 or 0xff give collisions)
- For DJB, the tuples (22, 10, 12, 22, 29), (23, 14, 18, 26, 30) have 2**24 collisions (all multipliers with lower byte 0xff give collisions)

However, when you then look at the multipliers for these bad cases, they all have a special structure in the lower bits of which there are 2 cases:

- A special bit pattern like 0x001, 0x003, 0x555, 0xccd, ...
- A zero of a low-degree polynomial like 0x9fa5 which is a zero of x^2 + x + 2 modulo 2**16 (this may only be relevant for DJB)

In order to eliminate these 2 cases, I decided to fix the lower byte of the multiplier. I wanted it to be 3 or 5 mod 8 to have maximal multiplicative order and then I checked which byte had the worst algebraic relations and no obvious bit pattern. I decided to take 0xc5 as lower byte.

When considering only multipliers with 0xc5 as lower byte, I found no very bad cases. I checked lots of pairs of tuples of length <= 6 and entries <= 64 and the worst I could find was 8192 collisions for FNV and 1024 collisions for DJB. This maximum number was found for tuples of length 5. Also, the maximum number of collisions seems bounded as the bitsize increases. For a 25-bit hash, I got the same maximum numbers of collisions as for a 32-bit hash. So, the probability of getting a collision decreases by a factor of 2 for every bit added, which is what you want.

When testing various bounds on the entries and tuple lengths, DJB is generally a little bit better than FNV (by 2 metrics: the maximum number of collisions and the root-mean-square of the number of collisions).

So my conclusion would be to use DJB as core algorithm, taking care to pick a good multiplier (or at least not an obviously bad multiplier).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 28 11:40:13 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Sep 2018 15:40:13 +0000
Subject: [issue34687] asyncio: is it time to make ProactorEventLoop as the
 default event loop?
In-Reply-To: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>
Message-ID: <1538149213.59.0.545547206417.issue34687@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 37aae9dcf18753b8ffda99d1a5758a90af852464 by Miss Islington (bot) (Victor Stinner) in branch 'master':
bpo-34687: Update asyncio doc for ProactorEventLoop (GH-9623)
https://github.com/python/cpython/commit/37aae9dcf18753b8ffda99d1a5758a90af852464


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34687>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:14:57 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 16:14:57 +0000
Subject: [issue34834] test_ssl.test_options does not correctly account for
 built-in ctx defaults with openssl 1.1.1
Message-ID: <1538151296.99.0.545547206417.issue34834@psf.upfronthosting.co.za>


New submission from Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:

self.assertEqual(default, ctx.options) in test_options fails with openssl 1.1.1 as it does not correctly account for OP_ENABLE_MIDDLEBOX_COMPAT. It is not defined by the python2.7 ssl module either.

either ssl.OP_ENABLE_MIDDLEBOX_COMPAT needs to be backported, or the test case should just add that constant in when openssl version is >= 1.1.1

----------
messages: 326642
nosy: xnox
priority: normal
severity: normal
status: open
title: test_ssl.test_options does not correctly account for built-in ctx defaults with openssl 1.1.1
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34834>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:18:26 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 16:18:26 +0000
Subject: [issue34834] test_ssl.test_options does not correctly account for
 built-in ctx defaults with openssl 1.1.1
In-Reply-To: <1538151296.99.0.545547206417.issue34834@psf.upfronthosting.co.za>
Message-ID: <1538151506.78.0.545547206417.issue34834@psf.upfronthosting.co.za>


Change by Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:


----------
keywords: +patch
pull_requests: +9022
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34834>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:21:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 28 Sep 2018 16:21:38 +0000
Subject: [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538151698.05.0.545547206417.issue34802@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +9023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34802>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:26:40 2018
From: report at bugs.python.org (Dr_Zaszus)
Date: Fri, 28 Sep 2018 16:26:40 +0000
Subject: [issue34835] Multiprocessing module update fails with pip3
Message-ID: <1538152000.15.0.545547206417.issue34835@psf.upfronthosting.co.za>


New submission from Dr_Zaszus <asserov at gmail.com>:

pip3 install --upgrade multiprocessing 

fails with a python2 error in 'setup.py': 
       print 'Macros:'
                     ^
   SyntaxError: Missing parentheses in call to 'print'. Did you mean print('Macros:')?

----------
components: Installation
messages: 326643
nosy: Dr_Zaszus
priority: normal
severity: normal
status: open
title: Multiprocessing module update fails with pip3
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34835>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:32:44 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 16:32:44 +0000
Subject: [issue34836] test_ssl.test_default_ecdh_curve needs no tls1.3 flag in
 2.7, for now
Message-ID: <1538152364.12.0.545547206417.issue34836@psf.upfronthosting.co.za>


New submission from Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:

test_default_ecdh_curve fails, as ssl.OP_NO_TLSv1_3 is not set on the context. and the test case can only work with non-tls1.3 connections.

this indicates that the pull request that sprinkled ssl.OP_NO_TLSv1_3 everywhere was not backported, taking into account all the other backports that did subsequently remove those flags in many test cases.

at the moment that test case is failing, but it would be nice if it didn't.

----------
messages: 326644
nosy: xnox
priority: normal
severity: normal
status: open
title: test_ssl.test_default_ecdh_curve needs no tls1.3 flag in 2.7, for now
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34836>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:34:40 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 16:34:40 +0000
Subject: [issue34836] test_ssl.test_default_ecdh_curve needs no tls1.3 flag in
 2.7, for now
In-Reply-To: <1538152364.12.0.545547206417.issue34836@psf.upfronthosting.co.za>
Message-ID: <1538152480.44.0.545547206417.issue34836@psf.upfronthosting.co.za>


Change by Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:


----------
keywords: +patch
pull_requests: +9024
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34836>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:36:05 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 28 Sep 2018 16:36:05 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538152565.2.0.545547206417.issue12782@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The Python grammar is already not LL(1) strictly. Take for example the production for "argument":

argument: ( test [comp_for] | test '=' test | '**' test | '*' test )

obviously the first sets of test and test are the same and is ambiguous, but the NDFAs are still able to produce DFAs that can generate a concrete syntax tree that allows the AST generation to disambiguate that the second test is a NAME and not any other thing. 

The rule with_stmt: 'with' ( with_item (',' with_item)* | '(' with_item (',' with_item)* [','] ')' ) ':' suite

will generate a similar scenario. The NDFAs will generate DFAs that will ultimately allow us to just skip the more external group of parenthesis when generating the nodes. This makes valid all these expressions:

         with (manager() as x, manager() as y):
             pass
         with (manager() as x, manager() as y,):
             pass
         with (manager()):
             pass
         with (manager() as x):
             pass
         with (((manager()))):
             pass
         with ((((manager()))) as x):

but not this one:

         with (((manager()))) as x:

the reason is that it assigns the first LPAR to the second production and it fails when searching for the one that is at the end. I think this limitation is OK.

If you want to play with that. here is a prototype of the implementation with some tests:

https://github.com/pablogsal/cpython/tree/parenthesized_with

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:39:28 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 28 Sep 2018 16:39:28 +0000
Subject: [issue34835] Multiprocessing module update fails with pip3
In-Reply-To: <1538152000.15.0.545547206417.issue34835@psf.upfronthosting.co.za>
Message-ID: <1538152768.96.0.545547206417.issue34835@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

``pip3 search multiprocessing`` says:

multiprocessing (2.6.2.1)            - Backport of the multiprocessing package to Python 2.4 and 2.5

so you are trying to install a Python 2.4/2.5 package into Python 3.7, which naturally cannot work.

In Python 2.6+ multiprocessing is a std lib module and you don't need to use pip to install it. I'm not sure if pip works with Python 2.4 or 2.5, but if it does, you'll need to use the 2.4/2.5 version of pip to do the update, not pip3.

I'm going to close this as not a bug. If you disagree, please give reasons why you think it should be reopened.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34835>
_______________________________________

From report at bugs.python.org  Fri Sep 28 12:47:50 2018
From: report at bugs.python.org (Dr_Zaszus)
Date: Fri, 28 Sep 2018 16:47:50 +0000
Subject: [issue34835] Multiprocessing module update fails with pip3
In-Reply-To: <1538152000.15.0.545547206417.issue34835@psf.upfronthosting.co.za>
Message-ID: <1538153270.52.0.545547206417.issue34835@psf.upfronthosting.co.za>


Dr_Zaszus <asserov at gmail.com> added the comment:

No, you are right, thank you. But just to be clear, how do I update multiprocessing in python3 then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34835>
_______________________________________

From report at bugs.python.org  Fri Sep 28 13:04:44 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 28 Sep 2018 17:04:44 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538154284.65.0.545547206417.issue12782@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The DFA for the rule

with_stmt: 'with' ( with_item (',' with_item)* | '(' with_item (',' with_item)* [','] ')' ) ':' suite

is:

DFA for with_stmt                                                                                                                                 [512/2103]
  State 0
    'with' -> 1
  State 1
    '(' -> 2
    with_item -> 3
  State 2
    with_item -> 4
  State 3
    ',' -> 5
    ':' -> 6
  State 4
    ')' -> 7
    ',' -> 8
  State 5
    with_item -> 3
  State 6
    suite -> 10
  State 7
    ':' -> 6
  State 8
    ')' -> 7
    with_item -> 4
  State 9
    ',' -> 5
    ':' -> 6
  State 10 (final)
  State 11
    ')' -> 7
    ',' -> 8

It works because the transition from State 1 into a "(" is going to prioritize the path:

0 -> 1 -> "(" -> 2

instead if 

0 -> 1 -> with_item -> 3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Sep 28 13:13:36 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Sep 2018 17:13:36 +0000
Subject: [issue34768] Add documentation explaining __init__.py in packages
In-Reply-To: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>
Message-ID: <1538154816.23.0.545547206417.issue34768@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the expectation is that people will know about modules and packages long before they upload things to PyPI.  The import system and the packaging tools are two independent domains.

For example the official tutorial has an intro: https://docs.python.org/3/tutorial/modules.html#packages

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34768>
_______________________________________

From report at bugs.python.org  Fri Sep 28 13:38:45 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 17:38:45 +0000
Subject: [issue34834] test_ssl.test_options does not correctly account for
 built-in ctx defaults with openssl 1.1.1
In-Reply-To: <1538151296.99.0.545547206417.issue34834@psf.upfronthosting.co.za>
Message-ID: <1538156325.8.0.545547206417.issue34834@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34834>
_______________________________________

From report at bugs.python.org  Fri Sep 28 13:39:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 17:39:30 +0000
Subject: [issue34836] test_ssl.test_default_ecdh_curve needs no tls1.3 flag in
 2.7, for now
In-Reply-To: <1538152364.12.0.545547206417.issue34836@psf.upfronthosting.co.za>
Message-ID: <1538156370.07.0.545547206417.issue34836@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34836>
_______________________________________

From report at bugs.python.org  Fri Sep 28 13:51:49 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Sep 2018 17:51:49 +0000
Subject: [issue15994] memoryview to freed memory can cause segfault
In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
Message-ID: <1538157109.95.0.545547206417.issue15994@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15994>
_______________________________________

From report at bugs.python.org  Fri Sep 28 14:16:44 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Sep 2018 18:16:44 +0000
Subject: [issue25812] locale.nl_langinfo() can't decode value
In-Reply-To: <1449350345.3.0.205814810685.issue25812@psf.upfronthosting.co.za>
Message-ID: <1538158604.26.0.545547206417.issue25812@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25812>
_______________________________________

From report at bugs.python.org  Fri Sep 28 14:17:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Sep 2018 18:17:36 +0000
Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass
 inheritance
In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
Message-ID: <1538158656.13.0.545547206417.issue21919@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

>  I am adding Raymond as part of triaging who might have a better explanation about this. 

Guido, is this something we care about?  There is value in checking for metaclass conflicts when a class is created (to catch plausible mistakes and to assure that the right __new__() and __init__() methods run).  But post-creation, it's unclear whether there is value in rerunning checks and whether its even possible to know how other base classes might have affected the class creation.

Do this go in the "consenting adults" category (in the same way that we allow the __class__ attribute to be changed on instances without trying to verify whether it makes sense)?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21919>
_______________________________________

From report at bugs.python.org  Fri Sep 28 14:18:12 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Sep 2018 18:18:12 +0000
Subject: [issue25812] locale.nl_langinfo() can't decode value
In-Reply-To: <1449350345.3.0.205814810685.issue25812@psf.upfronthosting.co.za>
Message-ID: <1538158692.2.0.545547206417.issue25812@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/issue25812>
_______________________________________

From report at bugs.python.org  Fri Sep 28 14:18:40 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Sep 2018 18:18:40 +0000
Subject: [issue34797] Convert heapq to the argument clinic
In-Reply-To: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>
Message-ID: <1538158720.71.0.545547206417.issue34797@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34797>
_______________________________________

From report at bugs.python.org  Fri Sep 28 14:34:40 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Sep 2018 18:34:40 +0000
Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass
 inheritance
In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
Message-ID: <1538159680.59.0.545547206417.issue21919@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

As long as you can't crash CPython with this, this is the responsibility of the code that assigns to __bases__. If they don't take care, the program's behavior is undefined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21919>
_______________________________________

From report at bugs.python.org  Fri Sep 28 14:50:44 2018
From: report at bugs.python.org (paul j3)
Date: Fri, 28 Sep 2018 18:50:44 +0000
Subject: [issue34827] Make argparse.NameSpace iterable
In-Reply-To: <1538113473.95.0.545547206417.issue34827@psf.upfronthosting.co.za>
Message-ID: <1538160644.47.0.545547206417.issue34827@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

As documented in https://docs.python.org/3/library/argparse.html#the-namespace-object

you can create your own 'namespace' class, that does everything you want and more.  argparse makes very few assumptions about the object - using getattr, setattr, and hasattr where possible.

All that the argparse.Namespace class adds to a plain object is the ability to set initial attributes, and to display them in a pretty way.

Look at Namespace.__repr__ to see how it accesses its attributes.

For a function with a

    fn(*args, **kwargs)

signature, a namespace 'ns', can be passed in in 2 ways:

   fn(*ns._get_kwargs(), **ns.__dict__)

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34827>
_______________________________________

From report at bugs.python.org  Fri Sep 28 15:01:07 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Sep 2018 19:01:07 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1538161267.58.0.545547206417.issue21109@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/issue21109>
_______________________________________

From report at bugs.python.org  Fri Sep 28 15:15:49 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Sep 2018 19:15:49 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538162149.8.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

[Tim]
> Perhaps worth noting that FNV-1a works great if used as
> _intended_:  on a stream of unsigned bytes.
> ...
>
>    Py_uhash_t t = (Py_uhash_t)y;
>    for (int i = 0; i < sizeof(t); ++i) {
>        x = (x ^ (t & 0xff)) * (Py_uhash_t)1099511628211ULL;
>        t >>= 8;
>    }

And that's all - no hacks for nested tuples, no hacks for mixed-sign ints, just 100% pure FNV-1a.

So, just for fun, how about 100% pure Bernstein 33A or 33X?  Those replace the 3rd line above with, respectively,

        x = (x * 33) + (t & 0xff); // 33A

or

        x = (x * 33) ^ (t & 0xff); // 33X


And those _also_ work great:  no collisions at all across my collection, except for the new tuple test, where they suffer 10 and 8 collisions respectively (note that the new test retains only the 32 least-significant hash bits).

Those are remarkable partly because multiplying by 33 is a weak permutation on its own:  it's just a left shift (by 5) and an add.  And while you can find odd multipliers with lower order (mod 2**N) than 33, you have to work to find one - it's exceptionally poor in this respect.  For example, pow(33, 8, 256) == 1, but half of the odd multipliers in range(256) have order 64 (mod 256).  Only 16 of 'em have order <= 8.

Then again, we're applying that weak permutation 8 times per 64-bit input here, and folding in a fresh byte each time.  It seems that, overall, that's "stronger" than applying a stronger - but still easily spelled - permutation just one or two times to a 64-bit input.

The only thing I've tried using 64-bit ops that was comparably robust across these tests used the frozenset hash's permutation on the inputs:

    Py_uhash_t t = (Py_uhash_t)y;
    t = ((t ^ 89869747UL) ^ (t << 16)) * 3644798167UL;
    x = (x * mult) + t;

That was quite insensitive to the choice of `mult`.  For example, in this instead:

    Py_uhash_t t = (Py_uhash_t)y;
    t ^= t << 1;
    x = (x * mult) + t;

the original tuple test had 24 collision and the new test 6 using the current multiplier; changing to the FNV-1a 32-bit multiplier, those zoomed to 857 and 44; then to the FNV-1a 64-bit multiplier, zoomed again to 477 and 2027; then to the "random" 1484268081, way down to 0 and 25; and finally to the "random" 5517301966916670289, down to 0 and 4.  Which didn't inspire confidence ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Fri Sep 28 15:18:37 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 28 Sep 2018 19:18:37 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538162317.21.0.545547206417.issue34370@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

The scroll problem (clicking on the upper half of the slider is taken as "through1") still persists for me on Mojave with 3.7.1 RC1 downloaded from python.org and including Tcl/Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Fri Sep 28 15:39:51 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Sep 2018 19:39:51 +0000
Subject: [issue34797] Convert heapq to the argument clinic
In-Reply-To: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>
Message-ID: <1538163591.87.0.545547206417.issue34797@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset e2f48bf0e851dc79d888c70fd24c631a8a9e1030 by Raymond Hettinger (Pablo Galindo) in branch 'master':
bpo-34797: Convert heapq to the argument clinic (GH-9560)
https://github.com/python/cpython/commit/e2f48bf0e851dc79d888c70fd24c631a8a9e1030


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34797>
_______________________________________

From report at bugs.python.org  Fri Sep 28 15:40:30 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Sep 2018 19:40:30 +0000
Subject: [issue34797] Convert heapq to the argument clinic
In-Reply-To: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>
Message-ID: <1538163630.11.0.545547206417.issue34797@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34797>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:01:31 2018
From: report at bugs.python.org (Frank Schaefer)
Date: Fri, 28 Sep 2018 20:01:31 +0000
Subject: [issue34771] test_ctypes failing on Linux SPARC64
In-Reply-To: <1537638972.94.0.956365154283.issue34771@psf.upfronthosting.co.za>
Message-ID: <1538164891.69.0.545547206417.issue34771@psf.upfronthosting.co.za>


Frank Schaefer <kelledin at gmail.com> added the comment:

FYI the libffi bug report is open here:

https://github.com/libffi/libffi/issues/451

As noted in the bug report, this issue actually doesn't appear to impact ARM64 (or ARM32 GNUEABI/GNUEABIHF).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34771>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:04:13 2018
From: report at bugs.python.org (Sean Harrington)
Date: Fri, 28 Sep 2018 20:04:13 +0000
Subject: [issue34837] Multiprocessing.pool API Extension - Non-Global
 Initialization of Workers
Message-ID: <1538165053.48.0.545547206417.issue34837@psf.upfronthosting.co.za>


Change by Sean Harrington <seanharr11 at gmail.com>:


----------
components: Library (Lib)
nosy: seanharr11
priority: normal
severity: normal
status: open
title: Multiprocessing.pool API Extension - Non-Global Initialization of Workers
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34837>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:14:17 2018
From: report at bugs.python.org (Sean Harrington)
Date: Fri, 28 Sep 2018 20:14:17 +0000
Subject: [issue34837] Multiprocessing.pool API Extension - Non-Global
 Initialization of Workers
Message-ID: <1538165657.25.0.545547206417.issue34837@psf.upfronthosting.co.za>


Change by Sean Harrington <seanharr11 at gmail.com>:


----------
keywords: +patch
pull_requests: +9025
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34837>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:19:26 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 28 Sep 2018 20:19:26 +0000
Subject: [issue25812] locale.nl_langinfo() can't decode value
In-Reply-To: <1449350345.3.0.205814810685.issue25812@psf.upfronthosting.co.za>
Message-ID: <1538165966.36.0.545547206417.issue25812@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> nnja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25812>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:26:37 2018
From: report at bugs.python.org (Joel Klimont)
Date: Fri, 28 Sep 2018 20:26:37 +0000
Subject: [issue34828] sqlite.iterdump does not work for (most) databases with
 autoincrement
In-Reply-To: <1538117515.33.0.545547206417.issue34828@psf.upfronthosting.co.za>
Message-ID: <1538166397.97.0.545547206417.issue34828@psf.upfronthosting.co.za>


Joel Klimont <joel.klimont at gmail.com> added the comment:

I made the pull request: https://github.com/python/cpython/pull/9621

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34828>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:52:47 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Sep 2018 20:52:47 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538167967.17.0.545547206417.issue34370@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks for testing, Vlad.  And thanks for the followup, Kevin.  I guess we'll wait to hear more from Kevin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Fri Sep 28 16:53:06 2018
From: report at bugs.python.org (Sean Harrington)
Date: Fri, 28 Sep 2018 20:53:06 +0000
Subject: [issue34837] Multiprocessing.pool API Extension - Pass Data to
 Workers w/o Globals
Message-ID: <1538167986.95.0.545547206417.issue34837@psf.upfronthosting.co.za>


Change by Sean Harrington <seanharr11 at gmail.com>:


----------
title: Multiprocessing.pool API Extension - Non-Global Initialization of Workers -> Multiprocessing.pool API Extension - Pass Data to Workers w/o Globals

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34837>
_______________________________________

From report at bugs.python.org  Fri Sep 28 17:15:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Sep 2018 21:15:58 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
Message-ID: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

An arg clinic specification such as

    p: object(subclass_of='&PyTuple_Type')

generates slow code using _PyArg_ParseStack() that has to parse a format string like "O!" to decide to make a type check.  Instead, it should directly generate a branch-predictable test for the type check and then call the much quicker function _PyArg_UnpackStack().

See https://github.com/python/cpython/pull/9628 for an example of this change giving a 30% speedup.

----------
components: Argument Clinic
messages: 326659
nosy: larry, rhettinger, serhiy.storchaka, vstinner
priority: low
severity: normal
status: open
title: Improve arg clinic code generation for cases with type checking
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Fri Sep 28 17:20:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Sep 2018 21:20:13 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1538169613.62.0.545547206417.issue34838@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Fri Sep 28 17:46:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 21:46:15 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1538171175.03.0.545547206417.issue34838@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Fri Sep 28 18:17:04 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 28 Sep 2018 22:17:04 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
 in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1538173024.95.0.545547206417.issue9056@psf.upfronthosting.co.za>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +9026
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9056>
_______________________________________

From report at bugs.python.org  Fri Sep 28 18:29:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Sep 2018 22:29:08 +0000
Subject: [issue34779] IDLE internals show up in tracebacks when returning
 objects that cannot be `repr`ed
In-Reply-To: <1537727943.66.0.956365154283.issue34779@psf.upfronthosting.co.za>
Message-ID: <1538173748.73.0.545547206417.issue34779@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34779>
_______________________________________

From report at bugs.python.org  Fri Sep 28 19:09:45 2018
From: report at bugs.python.org (Umesh Pathak)
Date: Fri, 28 Sep 2018 23:09:45 +0000
Subject: [issue29001] logging.handlers.RotatingFileHandler rotation broken
 under gunicorn
In-Reply-To: <1482004859.28.0.622019934032.issue29001@psf.upfronthosting.co.za>
Message-ID: <1538176185.62.0.545547206417.issue29001@psf.upfronthosting.co.za>


Change by Umesh Pathak <umeshpd.pathak at gmail.com>:


----------
keywords: +patch
pull_requests: +9027
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29001>
_______________________________________

From report at bugs.python.org  Fri Sep 28 19:12:07 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 28 Sep 2018 23:12:07 +0000
Subject: [issue29001] logging.handlers.RotatingFileHandler rotation broken
 under gunicorn
In-Reply-To: <1482004859.28.0.622019934032.issue29001@psf.upfronthosting.co.za>
Message-ID: <1538176327.42.0.545547206417.issue29001@psf.upfronthosting.co.za>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +vinay.sajip
versions: +Python 3.8 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29001>
_______________________________________

From report at bugs.python.org  Fri Sep 28 19:23:00 2018
From: report at bugs.python.org (Laurent Gautier)
Date: Fri, 28 Sep 2018 23:23:00 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1538176980.27.0.545547206417.issue34778@psf.upfronthosting.co.za>


Laurent Gautier <lgautier at gmail.com> added the comment:

@mattip : do you mean that it can currently be achieved by calling `cast` with a specific shape parameter ? If the case, how so ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Fri Sep 28 19:26:42 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 28 Sep 2018 23:26:42 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1538177202.15.0.545547206417.issue34838@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/issue34838>
_______________________________________

From report at bugs.python.org  Fri Sep 28 19:37:28 2018
From: report at bugs.python.org (Felipe Rodrigues)
Date: Fri, 28 Sep 2018 23:37:28 +0000
Subject: [issue34832] "Short circuiting" in base64's b64decode, decode,
 decodebytes
In-Reply-To: <1538137213.36.0.545547206417.issue34832@psf.upfronthosting.co.za>
Message-ID: <1538177848.18.0.545547206417.issue34832@psf.upfronthosting.co.za>


Felipe Rodrigues <felipe at felipevr.com> added the comment:

I am not sure if simply ignoring the non-valid character is the best way to go. Feels like silencing errors.

b64decode does accept the 'validate' flag - defaulted to False - that will halt the execution and throw an error.

What might be a good idea is to implement an 'errors' argument that accepts 'ignore' as a value, like we do for bytes.decode (https://docs.python.org/3/library/stdtypes.html#bytes.decode)

----------
nosy: +fbidu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34832>
_______________________________________

From report at bugs.python.org  Fri Sep 28 19:49:43 2018
From: report at bugs.python.org (Felipe Rodrigues)
Date: Fri, 28 Sep 2018 23:49:43 +0000
Subject: [issue34832] "Short circuiting" in base64's b64decode, decode,
 decodebytes
In-Reply-To: <1538137213.36.0.545547206417.issue34832@psf.upfronthosting.co.za>
Message-ID: <1538178583.02.0.545547206417.issue34832@psf.upfronthosting.co.za>


Felipe Rodrigues <felipe at felipevr.com> added the comment:

Actually, I'm not even sure if it makes sense to decode the 'first valid substring'... IMHO, we should warn the user

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34832>
_______________________________________

From report at bugs.python.org  Fri Sep 28 20:18:04 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 00:18:04 +0000
Subject: [issue34839] doctest: Change example under warnings section
Message-ID: <1538180284.16.0.545547206417.issue34839@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

The Warnings section of the doctest documentation (https://docs.python.org/3.8/library/doctest.html#warnings) contains an example that the printing order of a dictionary is not guaranteed.  Since it is now guaranteed to be insertion order, perhaps the example should be changed.

----------
assignee: docs at python
components: Documentation
messages: 326663
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: doctest: Change example under warnings section
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34839>
_______________________________________

From report at bugs.python.org  Fri Sep 28 20:28:19 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 29 Sep 2018 00:28:19 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1538180899.21.0.545547206417.issue34609@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The failure line that Cheryl found in her traceback is at https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py#L101 .

Maybe Antoine has an idea since he did a bunch of work on import locking?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Fri Sep 28 20:34:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 29 Sep 2018 00:34:53 +0000
Subject: [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1538181293.27.0.545547206417.issue34831@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I like this, great job!


Couple of thoughts on how we should organize this:

* I think we should stick to your structure and push things to docs.python.org as soon as every next section is somewhat ready.

* Every big section should probably have its own page, linking prev/next tutorial pages.

* I'd organize the tutorial in a dedicated directory like "Doc/library/asyncio-tutorial/".  Context: I wanted to reorganize all current "Doc/library/asyncio*.rst" files under one dir too, but decided to keep the existing file structure to avoid breaking links to the docs from SO/google).  We shouldn't repeat that mistake again.

BTW, maybe we should consider using the new iPythonn async repl: https://blog.jupyter.org/ipython-7-0-async-repl-a35ce050f7f7   What do you think about that?


Some comments on the proposed TOC:

>    - Reason #1: thread safety by not using threads at all.
>    - Reason #2: very many concurrent socket connections, which threads
>      make cumbersome.

This section is super important to get right, as I see people ask the "why and where should I use asyncio" _all_ _the_ _time_.  So I'll expand on this section in a detail.

Reason #1 and #2 are correct, but I think we should really focus on making #1 comprehensive and clear:

* async/await makes all context switches visible; that makes it easy to spot race conditions and reason about your code (think about ORMs that can make 100s of queries to render one web page); you've likely seen https://glyph.twistedmatrix.com/2014/02/unyielding.html

* in general, all datastructures are safe for async (we cannot say same for threads);

* an async/await library means that it's safe to use it in concurrent async/await code (you can never be sure if some library is thread-safe, even if it claims that);

* language constructs like 'async for' and 'async with' enable structured concurrency;

And on #2:

* high-throughput IO or 1000s of long-living connections are only doable with asyncio

* if you don't need to scale your code right now but might need in near future investing in async/await is wise


>- How to run `async def` functions
>    - point out there are two different issues: (a) `async def` functions
>      can call other functions, and other `async def` functions using
>      `await`, but also, (b) how to "get started" with the first
>      `async def` function? Answer: run the event loop.

Just a quick note: I'd try to not mention the low-level loop APIs as long as possible (e.g. no loop.run_until_complete() etc).


- Dealing with concurrent functions
    - (This is maybe too similar to the new docs in the section
      https://docs.python.org/3/library/asyncio-task.html?highlight=asyncio%20run#coroutines-and-tasks)

Right, we'll need to update the asyncio-task.rst file.  I think we'll collapse first two section into one ("Coroutines" and "Awaitables" into "Awaitables") and link the tutorial from that new section.


> - Case Study: chat server/client (my proposal)
> [..]
>     - server uses streams API

Yay for streams!

> [..]
>     - client implementation has some options:

I never use tkinter myself :( I remember trying to use it and it didn't work on my macOS.  So I'd try to either:

* build a simple browser app (that would require us to implement HTTP 0.9 which can be fun);
* build a terminal app;
* use iPython repl to connect to our asyncio server (might end up being more complicated than the first two options).

----------
nosy: +Elvis.Pranskevichus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34831>
_______________________________________

From report at bugs.python.org  Sat Sep 29 00:46:43 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 29 Sep 2018 04:46:43 +0000
Subject: [issue29001] logging.handlers.RotatingFileHandler rotation broken
 under gunicorn
In-Reply-To: <1482004859.28.0.622019934032.issue29001@psf.upfronthosting.co.za>
Message-ID: <1538196403.4.0.545547206417.issue29001@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's not Gunicorn-specific - more a case of multiple processes writing to a single log file. This is not supported directly, as documented here:

https://docs.python.org/3/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes

As the cookbook says, you can set up a separate process to handle logging to file, which listens with a socket server or a multiprocessing QueueListener; your worker processes would communicate with it using either a SocketHandler or a QueueHandler, as appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29001>
_______________________________________

From report at bugs.python.org  Sat Sep 29 00:49:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 29 Sep 2018 04:49:11 +0000
Subject: [issue29001] logging.handlers.RotatingFileHandler rotation broken
 under gunicorn
In-Reply-To: <1482004859.28.0.622019934032.issue29001@psf.upfronthosting.co.za>
Message-ID: <1538196551.53.0.545547206417.issue29001@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29001>
_______________________________________

From report at bugs.python.org  Sat Sep 29 02:03:26 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 29 Sep 2018 06:03:26 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538201006.51.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Jeroen, thanks for helping us fly slightly less blind! ;-) It's a lot of work.

I'd say you may as well pick a prime.  It's folklore, but "a reason" is that you've discovered that regular bit patterns in multipliers can hurt, and sticking to primes eliminates worlds of simple & subtle bit patterns.

Another bit of folklore:  pick a multiplier such that for each byte, neither it nor its complement are close in value to any other byte of the multiplier.  Which may seem more valuable for byte-oriented hashes, yet the byte-oriented FNV violates it spectacularly:  all FNV multipliers have _no_ bits set higher than 2**8 except for their leading bit.  So the longer the FNV multiplier, the more all-0 bytes it contains.

Which appears to be a deliberate choice to limit how quickly each new input byte propagates to other lower-order state bits across iterations.  The DJB33 algorithms accomplish that by using a tiny multiplier (relative to the output hash width) instead.

As I explained in other msgs here, treating tuple component hashes as sequences of bytes seems to deliver excellent results with the unaltered byte-oriented versions of FNV-1[a] and DJBX33[AX] - too good for anything in my test collection to detect anything even suspicious, let alone "a problem" (although it would be easy to contrive problem cases for 33[AX] - 33 is way "too small" to avoid collisions even across tuples with a single component).

So part of our challenge appears to me to be that we're trying instead to produce a hash from inputs of the _same_ bit width.  DJB/FNV were designed to produce hashes of width at least 4 times their inputs' bit widths.  Each input has a relatively tiny effect on the internal state for them.  For us, each input can change the entire internal state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sat Sep 29 02:38:06 2018
From: report at bugs.python.org (shuoz)
Date: Sat, 29 Sep 2018 06:38:06 +0000
Subject: [issue34840] dlopen() error with no error message from dlerror()
Message-ID: <1538203086.61.0.545547206417.issue34840@psf.upfronthosting.co.za>


New submission from shuoz <zzw20124321 at gmail.com>:

python _ctypes.dlclose(arg). 
Never check the arg  so we get a Segmentation fault (core dumped)

poc.py
```
import _ctypes
_ctypes.dlclose(3)  # 3-4294967296
```
python poc.py


gdb info

```
----------------------------------registers-----------------------------------]
RAX: 0x7ffff7ffcca0 --> 0x40d0d00000000 
RBX: 0x0 
RCX: 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
RDX: 0x2e10a0bf96213a9d 
RSI: 0x0 
RDI: 0x3 
RBP: 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
RSP: 0x7fffffffd280 --> 0x0 
RIP: 0x7ffff7dee161 (<_dl_close+1>:	test   BYTE PTR [rdi+0x3d4],0x8)
R8 : 0x3 
R9 : 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
R10: 0xc55dc0 --> 0x31 ('1')
R11: 0x7ffff7eec3d8 --> 0x9 ('\t')
R12: 0x3 
R13: 0x7ffff7e952b0 --> 0x1 
R14: 0x7ffff2d12140 (<py_dl_close>:	push   r14)
R15: 0x7ffff7e17228 --> 0x16
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff7dee152:	nop    DWORD PTR [rax+0x0]
   0x7ffff7dee156:	nop    WORD PTR cs:[rax+rax*1+0x0]
   0x7ffff7dee160 <_dl_close>:	push   rbx
=> 0x7ffff7dee161 <_dl_close+1>:	test   BYTE PTR [rdi+0x3d4],0x8
   0x7ffff7dee168 <_dl_close+8>:	mov    rbx,rdi
   0x7ffff7dee16b <_dl_close+11>:	jne    0x7ffff7dee210 <_dl_close+176>
   0x7ffff7dee171 <_dl_close+17>:	mov    edx,DWORD PTR [rdi+0x310]
   0x7ffff7dee177 <_dl_close+23>:	test   edx,edx
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd280 --> 0x0 
0008| 0x7fffffffd288 --> 0x7ffff7de7564 (<_dl_catch_error+116>:	mov    rax,QWORD PTR [rsp+0x8])
0016| 0x7fffffffd290 --> 0x0 
0024| 0x7fffffffd298 --> 0x7ffff7fd8720 --> 0x7fffffffd2e0 --> 0x7ffff737f690 --> 0x0 
0032| 0x7fffffffd2a0 --> 0x0 
0040| 0x7fffffffd2a8 --> 0x7ffff737f690 --> 0x0 
0048| 0x7fffffffd2b0 --> 0x7ffff737f698 --> 0x0 
0056| 0x7fffffffd2b8 --> 0x7ffff737f688 --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
_dl_close (_map=0x3) at dl-close.c:809
809	dl-close.c: No such file or directory.
gdb-peda$ bt
```

----------
components: ctypes
messages: 326668
nosy: shuoz
priority: normal
severity: normal
status: open
title: dlopen() error with no error message from dlerror()
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34840>
_______________________________________

From report at bugs.python.org  Sat Sep 29 03:09:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 29 Sep 2018 07:09:30 +0000
Subject: [issue34812] support.args_from_interpreter_flags() doesn't inherit -I
 (isolated) flag
In-Reply-To: <1537978023.88.0.545547206417.issue34812@psf.upfronthosting.co.za>
Message-ID: <1538204970.66.0.545547206417.issue34812@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Victor for the details. Can this be classified as an easy issue? I guess the fix will be as below : 

1. Add an entry for '-I' at https://github.com/python/cpython/blob/4b430e5f6954ef4b248e95bfb4087635dcdefc6d/Lib/subprocess.py#L260

2. Add a test for '-I' at https://github.com/python/cpython/blob/4b430e5f6954ef4b248e95bfb4087635dcdefc6d/Lib/test/test_support.py#L472. 
The only thing here is that '-I' returns '-s -E -I' unlike other options where args can be used for comparison logic in check_options. check_options should be changed so that this can take given args and the expected args for comparison to accommodate -I. Maybe there is a better way?

Off topic : I don't know why '-I' is not documented as sys.flags.isolated at https://docs.python.org/3.7/library/sys.html#sys.flags . Maybe I will open up a separate issue for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34812>
_______________________________________

From report at bugs.python.org  Sat Sep 29 03:14:57 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 29 Sep 2018 07:14:57 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1538205297.32.0.545547206417.issue28655@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess this can be safely closed as fixed since 3.6 changes were merged and I verified the PR changes locally at msg326477. The issue regarding using -I along with -j0 is tracked at issue34812 .

Thanks Serhiy and Victor for the fixes :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Sat Sep 29 03:18:58 2018
From: report at bugs.python.org (Simon Sapin)
Date: Sat, 29 Sep 2018 07:18:58 +0000
Subject: [issue33698] `._pth` does not allow to populate `sys.path` with empty
 entry
In-Reply-To: <1527700361.05.0.682650639539.issue33698@psf.upfronthosting.co.za>
Message-ID: <1538205538.62.0.545547206417.issue33698@psf.upfronthosting.co.za>


Change by Simon Sapin <simon.sapin at exyr.org>:


----------
nosy: +ssapin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33698>
_______________________________________

From report at bugs.python.org  Sat Sep 29 03:49:04 2018
From: report at bugs.python.org (Simon Sapin)
Date: Sat, 29 Sep 2018 07:49:04 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
Message-ID: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>


New submission from Simon Sapin <simon.sapin at exyr.org>:

https://docs.python.org/3/library/sys.html#sys.path documents:

> As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter.

On Windows with an embeddable zip file distribution, this does not happen.

Steps to reproduce:

* Create a foo.py file that contains `import bar`
* Create an empty bar.py file
* With your usual Python installed from the "normal" executable installer, check that `python foo.py` runs without output or error
* Download and extract https://www.python.org/ftp/python/3.7.0/python-3.7.0-embed-amd64.zip
* Run `..\python-3.7.0-embed-amd64\python foo.py`

Expected result:

The script runs again without output or error.

Actual result:

Traceback (most recent call last):
  File "foo.py", line 1, in <module>
    import bar
ModuleNotFoundError: No module named 'bar'


This might be an occurrence of https://bugs.python.org/issue33698, since the embeddable distribution has a python37._pth file that contains "python37.zip" and "."

print(sys.path) shows [
  'C:\\Users\\example\\python-3.7.0-embed-amd64\\python37.zip',
  'C:\\Users\\example\\python-3.7.0-embed-amd64'
]

This StackOverflow question describes the same issue: https://stackoverflow.com/q/51403126/1162888

----------
messages: 326671
nosy: ssapin
priority: normal
severity: normal
status: open
title: Script?s directory not in sys.path with embeddable Windows distribution
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34841>
_______________________________________

From report at bugs.python.org  Sat Sep 29 04:59:25 2018
From: report at bugs.python.org (hongweipeng)
Date: Sat, 29 Sep 2018 08:59:25 +0000
Subject: [issue32291] Value error for string shared memory in multiprocessing
In-Reply-To: <1513098036.37.0.213398074469.issue32291@psf.upfronthosting.co.za>
Message-ID: <1538211565.69.0.545547206417.issue32291@psf.upfronthosting.co.za>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
nosy: +hongweipeng

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32291>
_______________________________________

From report at bugs.python.org  Sat Sep 29 05:29:49 2018
From: report at bugs.python.org (Dan Snider)
Date: Sat, 29 Sep 2018 09:29:49 +0000
Subject: [issue34842] Incorrect error messages in bisect
Message-ID: <1538213389.56.0.545547206417.issue34842@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

internal_bisect_left and internal_bisect_right use PySequence_Size when a "hi" argument wasn't provided, which causes this silly error message:

    >>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object of type 'dict' has no len()

They could use PyObject_Size and let PySequence_GetItem in the loop catch the error:

    >>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'dict' object does not support indexing

Since that actually makes sense and is more efficient / less verbose than adding a PySequence_Check.

----------
components: Interpreter Core
messages: 326672
nosy: bup
priority: normal
severity: normal
status: open
title: Incorrect error messages in bisect
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34842>
_______________________________________

From report at bugs.python.org  Sat Sep 29 05:36:59 2018
From: report at bugs.python.org (hongweipeng)
Date: Sat, 29 Sep 2018 09:36:59 +0000
Subject: [issue32291] Value error for string shared memory in multiprocessing
In-Reply-To: <1513098036.37.0.213398074469.issue32291@psf.upfronthosting.co.za>
Message-ID: <1538213819.27.0.545547206417.issue32291@psf.upfronthosting.co.za>


hongweipeng <hongweichen8888 at sina.com> added the comment:

This problem seems to be support for str.

import multiprocessing
import ctypes

def child_process_fun(share):
    share.value = 'bb'

if __name__ == '__main__':
    share = multiprocessing.Value(ctypes.c_wchar_p, 'aa')
    process = multiprocessing.Process(target=child_process_fun, args=(share, ))
    process.start()
    process.join()
    print(share.value)

It also raises ValueError.When use c_double or c_int, it works well.

Test in python3.7 and 3.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32291>
_______________________________________

From report at bugs.python.org  Sat Sep 29 06:24:57 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Sep 2018 10:24:57 +0000
Subject: [issue34609] Importing certain modules while debugging raises an
 exception
In-Reply-To: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>
Message-ID: <1538216697.95.0.545547206417.issue34609@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think pperry nailed it above:

> Pdb fails because it is attempting to import the readline module every time its `trace_dispatch` is called, and the import implementation is not reentrant in that way.

More precisely, _ModuleLock.acquire() in https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py#L101 is not reentrant.  If pdb steps into that function and tries to call it again by making an "import" call, `_blocking_on[tid]` will be overwritten and then deleted inside the nested call, so `del _blocking_on` in the enclosing call will raise a KeyError.

I think the solution would be either one of:
1) pdb avoids doing anything import-related as part of its step function
2) pdb avoids stepping inside importlib internals (e.g. by blacklisting importlib modules)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34609>
_______________________________________

From report at bugs.python.org  Sat Sep 29 08:19:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 29 Sep 2018 12:19:03 +0000
Subject: [issue34842] Incorrect error messages in bisect
In-Reply-To: <1538213389.56.0.545547206417.issue34842@psf.upfronthosting.co.za>
Message-ID: <1538223543.61.0.545547206417.issue34842@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was fixed in issue32500. This is a new feature and it was not backported.

>>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dict is not a sequence
>>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dict is not a sequence

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34842>
_______________________________________

From report at bugs.python.org  Sat Sep 29 09:28:22 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 13:28:22 +0000
Subject: [issue34843] logging cookbook docs: remove 'recent' when referring to
 multiprocessing
Message-ID: <1538227702.53.0.545547206417.issue34843@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In the logging cookbook docs, the word 'recent' is used to describe versions of Python containing the multiprocessing module.  Since multiprocessing is 10 years old, I think it may be safe to remove the word 'recent'.

----------
assignee: docs at python
components: Documentation
messages: 326676
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: logging cookbook docs: remove 'recent' when referring to multiprocessing
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34843>
_______________________________________

From report at bugs.python.org  Sat Sep 29 09:30:46 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 13:30:46 +0000
Subject: [issue34843] logging cookbook docs: remove 'recent' when referring to
 multiprocessing
In-Reply-To: <1538227702.53.0.545547206417.issue34843@psf.upfronthosting.co.za>
Message-ID: <1538227846.96.0.545547206417.issue34843@psf.upfronthosting.co.za>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +9028
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34843>
_______________________________________

From report at bugs.python.org  Sat Sep 29 09:52:54 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 13:52:54 +0000
Subject: [issue34835] Multiprocessing module update fails with pip3
In-Reply-To: <1538152000.15.0.545547206417.issue34835@psf.upfronthosting.co.za>
Message-ID: <1538229174.54.0.545547206417.issue34835@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

As Steven said,
> In Python 2.6+ multiprocessing is a std lib module

This means that multiprocessing will be current with the version of Python 3 that you have installed.  If you're currently on 3.7.0, when 3.7.1 is released and you install it, you will get all the updates to multiprocessing (if there were any).

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34835>
_______________________________________

From report at bugs.python.org  Sat Sep 29 10:00:50 2018
From: report at bugs.python.org (Simon Sapin)
Date: Sat, 29 Sep 2018 14:00:50 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1538229650.79.0.545547206417.issue34841@psf.upfronthosting.co.za>


Simon Sapin <simon.sapin at exyr.org> added the comment:

Removing python37._pth restores the documented behavior, I don?t know if it has adverse effects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34841>
_______________________________________

From report at bugs.python.org  Sat Sep 29 10:25:22 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Sep 2018 14:25:22 +0000
Subject: [issue34833] [CI] Azure Pipeline: Initialize Agent failed
In-Reply-To: <1538140188.61.0.545547206417.issue34833@psf.upfronthosting.co.za>
Message-ID: <1538231122.59.0.545547206417.issue34833@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I'll pass it along in case someone is collecting statistics on the team, but unless it's consistently broken for us (e.g. as apt-get was recently) there's not much value in opening a bug. Transient failures occur, ultimately, and nobody needs encouragement to add the "re-run check" feature besides GitHub (and their response is to use the new UI, which is also a top priority for Pipelines right now).

Victor, if you'd like your account enabled to be able to restart builds though the Azure DevOps page, send me your Microsoft Account email(live.com/hotmail.com/etc) and I'll happily add you. But I'm still not sure whether that hooks up properly with GitHub's checks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34833>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:05:02 2018
From: report at bugs.python.org (Felipe Rodrigues)
Date: Sat, 29 Sep 2018 16:05:02 +0000
Subject: [issue34832] "Short circuiting" in base64's b64decode, decode,
 decodebytes
In-Reply-To: <1538137213.36.0.545547206417.issue34832@psf.upfronthosting.co.za>
Message-ID: <1538237102.91.0.545547206417.issue34832@psf.upfronthosting.co.za>


Felipe Rodrigues <felipe at felipevr.com> added the comment:

For reference in future discussions, Python's base64 module implements RFC 3548 (https://tools.ietf.org/html/rfc3548) whose section 2.3 (https://tools.ietf.org/html/rfc3548#section-2.3) discusses about "Interpretation of non-alphabet characters in encoded data".

The section's content is:

   Base encodings use a specific, reduced, alphabet to encode binary
   data.  Non alphabet characters could exist within base encoded data,
   caused by data corruption or by design.  Non alphabet characters may
   be exploited as a "covert channel", where non-protocol data can be
   sent for nefarious purposes.  Non alphabet characters might also be
   sent in order to exploit implementation errors leading to, e.g.,
   buffer overflow attacks.

   Implementations MUST reject the encoding if it contains characters
   outside the base alphabet when interpreting base encoded data, unless
   the specification referring to this document explicitly states
   otherwise.  Such specifications may, as MIME does, instead state that
   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").
   Note that this means that any CRLF constitute "non alphabet
   characters" and are ignored.  Furthermore, such specifications may
   consider the pad character, "=", as not part of the base alphabet
   until the end of the string.  If more than the allowed number of pad
   characters are found at the end of the string, e.g., a base 64 string
   terminated with "===", the excess pad characters could be ignored.

In my opinion, the RFC is rather permissive about strange characters in the encoded data. The RFC refers to the MIME specification that ignores the data and hints the possibility of rejecting the pad symbol '=' unless it is found in the end of the string.

I think that our best option if we would like to address this issue is to add an 'errors' argument whose default value will keep the current behavior for backwards compatibility but will accept more options in order to both ignore the strange characters and carry on with the processing - like bytes.decode's errors=ignore flag - and to raise an error in such situations, like bytes.decode's errors=strict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34832>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:07:19 2018
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 Sep 2018 16:07:19 +0000
Subject: [issue31370] Remove support for threads-less builds
In-Reply-To: <1504732249.83.0.180664230366.issue31370@psf.upfronthosting.co.za>
Message-ID: <1538237239.37.0.545547206417.issue31370@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:


New changeset eef059657d6b10babdb4831e1148d60cc644ee9a by Brian Curtin (Zackery Spytz) in branch 'master':
bpo-31370: Remove references to threadless builds (#8805)
https://github.com/python/cpython/commit/eef059657d6b10babdb4831e1148d60cc644ee9a


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31370>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:09:33 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 16:09:33 +0000
Subject: [issue32606] Email Header Injection Protection Bypass
In-Reply-To: <1516513252.62.0.467229070634.issue32606@psf.upfronthosting.co.za>
Message-ID: <1538237373.58.0.545547206417.issue32606@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Should this be closed as 'not a bug'?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32606>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:16:00 2018
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 Sep 2018 16:16:00 +0000
Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed
 fileobject
In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za>
Message-ID: <1538237760.32.0.545547206417.issue27351@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:


New changeset e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f by Brian Curtin (Zackery Spytz) in branch 'master':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27351>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:16:10 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Sep 2018 16:16:10 +0000
Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed
 fileobject
In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za>
Message-ID: <1538237770.55.0.545547206417.issue27351@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9029

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27351>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:16:16 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Sep 2018 16:16:16 +0000
Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed
 fileobject
In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za>
Message-ID: <1538237776.84.0.545547206417.issue27351@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9030

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27351>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:30:29 2018
From: report at bugs.python.org (mattip)
Date: Sat, 29 Sep 2018 16:30:29 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1538238629.07.0.545547206417.issue34778@psf.upfronthosting.co.za>


mattip <matti.picus at gmail.com> added the comment:

Sorry, I meant a "strides" keyword. "shape" is already a valid keyword

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:33:09 2018
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 Sep 2018 16:33:09 +0000
Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed
 fileobject
In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za>
Message-ID: <1538238789.02.0.545547206417.issue27351@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:


New changeset b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89 by Brian Curtin (Miss Islington (bot)) in branch '3.7':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27351>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:39:42 2018
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 Sep 2018 16:39:42 +0000
Subject: [issue27351] Unexpected ConfigParser.read() behavior when passed
 fileobject
In-Reply-To: <1466311827.21.0.0107030173129.issue27351@psf.upfronthosting.co.za>
Message-ID: <1538239182.41.0.545547206417.issue27351@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:


New changeset 3cd5e8e83c9785d9f505138903c7a50dc964101e by Brian Curtin (Miss Islington (bot)) in branch '3.6':
bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)
https://github.com/python/cpython/commit/3cd5e8e83c9785d9f505138903c7a50dc964101e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27351>
_______________________________________

From report at bugs.python.org  Sat Sep 29 12:57:39 2018
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 Sep 2018 16:57:39 +0000
Subject: [issue13407] tarfile doesn't support multistream bzipped tar files
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1538240259.28.0.545547206417.issue13407@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:


New changeset 8d3b0f49021e6cd25030a1eb979218cfceb44061 by Brian Curtin (Andr?s Delfino) in branch '2.7':
[2.7] bpo-13407: Mention that bz2/tarfile doesn't support multi-stream bzip2 files (GH-8428)
https://github.com/python/cpython/commit/8d3b0f49021e6cd25030a1eb979218cfceb44061


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Sat Sep 29 13:09:03 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Sep 2018 17:09:03 +0000
Subject: [issue34842] Incorrect error messages in bisect
In-Reply-To: <1538213389.56.0.545547206417.issue34842@psf.upfronthosting.co.za>
Message-ID: <1538240943.35.0.545547206417.issue34842@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Dan, thanks for the suggestion.  Changing to PyObject_Size() would have been the right thing to do if the error message had not been fixed.  But since the new error message "TypeError: dict is not a sequence" is more helpful than "TypeError: 'dict' object does not support indexing", we should leave the code as-is.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34842>
_______________________________________

From report at bugs.python.org  Sat Sep 29 13:34:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 29 Sep 2018 17:34:52 +0000
Subject: [issue34842] Incorrect error messages in bisect
In-Reply-To: <1538213389.56.0.545547206417.issue34842@psf.upfronthosting.co.za>
Message-ID: <1538242492.24.0.545547206417.issue34842@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution: not a bug -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34842>
_______________________________________

From report at bugs.python.org  Sat Sep 29 15:13:16 2018
From: report at bugs.python.org (Laurent Gautier)
Date: Sat, 29 Sep 2018 19:13:16 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1538248396.83.0.545547206417.issue34778@psf.upfronthosting.co.za>


Laurent Gautier <lgautier at gmail.com> added the comment:

Wouldn't a contiguity argument ('C' or 'F') be simpler ?
 
(Independently, an argument strides is likely also missing from "cast").

Do you know what are the next possible steps here ? Bring this to the python-dev list ? Submit a patch ?

----------
components: +Extension Modules, Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Sat Sep 29 16:17:10 2018
From: report at bugs.python.org (Luna Chen)
Date: Sat, 29 Sep 2018 20:17:10 +0000
Subject: [issue34844] logging.Formatter enhancement - Checking on style and
Message-ID: <1538252230.83.0.545547206417.issue34844@psf.upfronthosting.co.za>


New submission from Luna Chen <luna at bnmetrics.com>:

Issue: Currently logging.Formatter does not check if the format passed in is valid style or if the field is valid when creating the logging.Formatter object. It would be nice to have such check in the constructor of the logging.Formatter.

Here are 2 scenarios:

Scenario 1: Passing in invalid `fmt` when creating the logging.Formatter.
Example:
    import logging
    logger = logging.getLogger('my_logger')
    handler = logging.StreamHandler()

    fmt = logging.Formatter("blah-blah", style="{")
    handler.setFormatter(fmt)

    logger.addHandler(handler)
    logger.setLevel(logging.DEBUG)

    logger.info('This is my logging message.')

The above example would output the fmt string("blah-blah") whenever a logging operation is performed, such as `logging.info`, `logging.warning`.
And this goes the same for mismatching style and fmt, like so:
    fmt = logging.Formatter("{asctime}-{message}", style="%")


Scenario 2: Passing in invalid fields to logging.Formatter

    import logging
    logger = logging.getLogger('my_logger')
    handler = logging.StreamHandler()

    fmt = logging.Formatter("%(FuncName)s-%(message)s")
    handler.setFormatter(fmt)

    logger.addHandler(handler)
    logger.setLevel(logging.DEBUG)

    logger.info('This is my logging message.'
)
As you can see from the above example, the "%(FuncName)s" field is misspelled with a capital "F", which should have been a lowercase "f". In this scenario, we would get an interesting stacktrace:

--- Logging error ---
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 992, in emit
    msg = self.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 838, in format
    return fmt.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 578, in format
    s = self.formatMessage(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 547, in formatMessage
    return self._style.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 391, in format
    return self._fmt % record.__dict__
KeyError: 'FuncName'
Call stack:
  File "<stdin>", line 1, in <module>
Message: 'This is my logging message.'
Arguments: ()

Personally, I think the "KeyError" here can be misleading and confusing to some. 



Proposal:

I would like to make a PR with the following changes:
- Checking fmt to match the style in the constructor of logging.Formatting
- When calling log message functions such as "logger.info()", an "extra" key word arg can be passed for custom format fields, 
  for example:
  fmt = logging.Formatter("{cpuUsage} - {message}", style="{") # In this case, cpuUsage would be custom
  logger.info("my logging message", extra={"cpuUsage": "my_cpu_usage"})

  - I would like to have custom fields passed in as an additional (optional) argument into the constructor for logging.Formatter
  - Another option is to have an additional member method for adding additional fields
  - I think we could essentially have both options
  - With this, we can remove the "extra" argument in Logger.makeRecord()


Draw Backs:

- This change might essentially break some existing code where someone might use the "extra" argument in log message functions, as we would do the check on logging.Formatter level



Please let me know your thoughts, and I thought it would be nice to get some new ideas and areas I haven't thought about before I make this PR.


Best regards,
Luna Chen (BNMetrics)

----------
components: Library (Lib)
messages: 326690
nosy: BNMetrics, gvanrossum
priority: normal
severity: normal
status: open
title: logging.Formatter enhancement - Checking on style and
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34844>
_______________________________________

From report at bugs.python.org  Sat Sep 29 16:17:33 2018
From: report at bugs.python.org (Luna Chen)
Date: Sat, 29 Sep 2018 20:17:33 +0000
Subject: [issue34844] logging.Formatter enhancement - Checking on style and
 fmt fields
In-Reply-To: <1538252230.83.0.545547206417.issue34844@psf.upfronthosting.co.za>
Message-ID: <1538252253.78.0.545547206417.issue34844@psf.upfronthosting.co.za>


Change by Luna Chen <luna at bnmetrics.com>:


----------
title: logging.Formatter enhancement - Checking on style and -> logging.Formatter enhancement - Checking on style and fmt fields

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34844>
_______________________________________

From report at bugs.python.org  Sat Sep 29 18:02:27 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 29 Sep 2018 22:02:27 +0000
Subject: [issue34844] logging.Formatter enhancement - Checking on style and
 fmt fields
In-Reply-To: <1538252230.83.0.545547206417.issue34844@psf.upfronthosting.co.za>
Message-ID: <1538258547.03.0.545547206417.issue34844@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Moving to Python 3.8 because this is a feature proposal. Adding Vinay to nosy list because this is about logging.

----------
nosy: +vinay.sajip
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34844>
_______________________________________

From report at bugs.python.org  Sat Sep 29 18:05:23 2018
From: report at bugs.python.org (thautwarm)
Date: Sat, 29 Sep 2018 22:05:23 +0000
Subject: [issue34845] allow exprlist as the iterators of comprehensions to be
 consistent with for statements
Message-ID: <1538258723.92.0.545547206417.issue34845@psf.upfronthosting.co.za>


New submission from thautwarm <yaoxiansamma at gmail.com>:

Currently we can use `exprlist` as the iterator in a `for` 
statement:

  ```
  for i in 1, 2,:
     print(i)

  1
  2
  ```

  However, when it comes to comprehension expressions:

  ```
  [i for i in 1, 2]

  SyntaxError: invalid syntax
  ```

  I know there might be some reason that leads to the absence of the consistency between `for` expression and statement, but IMO until now it could be better to allow `exprlist` to be the iterator of comprehensions. I'm not sure whether our community has noticed this problem so I'm to propose it here.

  A crucial benefit from this change is that we can avoid the ambiguity when a comprehension is accepted as function parameter.

  ```
  f(for i in [1, 2, 3], 1, 2)
  ```
  We now get a SyntaxError when writing such codes, but people who know this syntax might think the parameters can be distinguished from each other, but it's still not allowed. 
  
  Allowing `exprlist` to be the iterator slot of a comprehension would be a rational solution. If `f(for i in [1, 2, 3], 1, 2)` is equivalent to `f(for i ([1, 2, 3], 1, 2))`, it will be natural to restrict the number of parameters to be just 1 when the parameter is a comprehension.

  You can slightly accept this workaround and try following examples:
  ```
  f(for i in 1,)
  f(for i in 1, for j in 2, 3,)
  f(for i in 1, 2 if cond(i) for j in 3, for k in 4,)
  ```
  Obviously, in each of above cases, the number of parameters is 1,
just because a `exprlist` could the iterator of a comprehension.

  The disadvantage of this change is, there is not too many related use cases, for any `[expr for target in iter_elem1, iter_elem2, ...]` could be altered as `[expr for target in (iter_elem1, iter_elem2, ...)]`. Meanwhile, that might not be true when it comes to someone works frequently with interactive python.
 
  
  Finally, I have finished this implementation at https://github.com/thautwarm/cpython/tree/exprlist-in-comprehensions, and I do want to make contributions to cpython projects. If most of you feel comfortable with this change, may I make a PR next?

----------
messages: 326692
nosy: gvanrossum, serhiy.storchaka, thautwarm, yselivanov
priority: normal
severity: normal
status: open
title: allow exprlist as the iterators of comprehensions to be consistent with for statements

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34845>
_______________________________________

From report at bugs.python.org  Sat Sep 29 18:06:30 2018
From: report at bugs.python.org (thautwarm)
Date: Sat, 29 Sep 2018 22:06:30 +0000
Subject: [issue34845] allow exprlist as the iterators of comprehensions to be
 consistent with for statements
In-Reply-To: <1538258723.92.0.545547206417.issue34845@psf.upfronthosting.co.za>
Message-ID: <1538258790.55.0.545547206417.issue34845@psf.upfronthosting.co.za>


Change by thautwarm <yaoxiansamma at gmail.com>:


----------
components: +Interpreter Core
type:  -> behavior
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34845>
_______________________________________

From report at bugs.python.org  Sat Sep 29 18:15:19 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 29 Sep 2018 22:15:19 +0000
Subject: [issue34845] allow exprlist as the iterators of comprehensions to be
 consistent with for statements
In-Reply-To: <1538258723.92.0.545547206417.issue34845@psf.upfronthosting.co.za>
Message-ID: <1538259319.7.0.545547206417.issue34845@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This is intentional. We don't want people accidentally writing e.g.

[i for i in range(10), j for j in range(10)]

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34845>
_______________________________________

From report at bugs.python.org  Sat Sep 29 18:26:38 2018
From: report at bugs.python.org (thautwarm)
Date: Sat, 29 Sep 2018 22:26:38 +0000
Subject: [issue34845] allow exprlist as the iterators of comprehensions to be
 consistent with for statements
In-Reply-To: <1538258723.92.0.545547206417.issue34845@psf.upfronthosting.co.za>
Message-ID: <1538259998.31.0.545547206417.issue34845@psf.upfronthosting.co.za>


thautwarm <yaoxiansamma at gmail.com> added the comment:

Well, sorry for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34845>
_______________________________________

From report at bugs.python.org  Sat Sep 29 19:09:21 2018
From: report at bugs.python.org (Martin Panter)
Date: Sat, 29 Sep 2018 23:09:21 +0000
Subject: [issue34785] pty.spawn -- auto-termination after child process is
 dead (a zombie)
In-Reply-To: <1537773919.52.0.956365154283.issue34785@psf.upfronthosting.co.za>
Message-ID: <1538262561.94.0.545547206417.issue34785@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Is this to get ?spawn? working on a non-Linux platform like a recent Free BSD, OS X, or Solaris? If so, see Issue 26228.

If not, you might have to explain your use case better. Polling for the child exiting is going to race with handling the child?s output, and if there are other processes writing to the terminal after the child exits this will change the behaviour.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34785>
_______________________________________

From report at bugs.python.org  Sat Sep 29 22:03:50 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sun, 30 Sep 2018 02:03:50 +0000
Subject: [issue13407] tarfile doesn't support multistream bzipped tar files
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1538273030.85.0.545547206417.issue13407@psf.upfronthosting.co.za>


Andr?s Delfino <adelfino at gmail.com> added the comment:

I believe this can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Sat Sep 29 22:04:09 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sun, 30 Sep 2018 02:04:09 +0000
Subject: [issue13407] tarfile doesn't support multistream bzipped tar files
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1538273049.87.0.545547206417.issue13407@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13407>
_______________________________________

From report at bugs.python.org  Sat Sep 29 22:15:16 2018
From: report at bugs.python.org (Satheesh Thomas)
Date: Sun, 30 Sep 2018 02:15:16 +0000
Subject: [issue34846] Runtime failure with Failed to import site module
Message-ID: <1538273716.55.0.545547206417.issue34846@psf.upfronthosting.co.za>


New submission from Satheesh Thomas <sat.tho at gmail.com>:

Run time failure to execute python scripts. It was running for long time without any issue . But sometimes get this error which stops the entire execution. Looks like some .pyc file got corrupted .

----------
components: Build
files: Python error1.png
messages: 326697
nosy: sat.tho at gmail.com
priority: normal
severity: normal
status: open
title: Runtime failure with Failed to import site module
type: crash
versions: Python 3.5
Added file: https://bugs.python.org/file47837/Python error1.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34846>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:22:21 2018
From: report at bugs.python.org (hongweipeng)
Date: Sun, 30 Sep 2018 03:22:21 +0000
Subject: [issue32291] Value error for string shared memory in multiprocessing
In-Reply-To: <1513098036.37.0.213398074469.issue32291@psf.upfronthosting.co.za>
Message-ID: <1538277741.76.0.545547206417.issue32291@psf.upfronthosting.co.za>


hongweipeng <hongweichen8888 at sina.com> added the comment:

I think I know the reason. `c_wchar_p` corresponds to the string pointer `wchar_t *`.It's not a good idea to pass pointers between processes. As quoted from `multiprocessing` docs:

Note Although it is possible to store a pointer in shared memory remember that this will refer to a location in the address space of a specific process. However, the pointer is quite likely to be invalid in the context of a second process and trying to dereference the pointer from the second process may cause a crash.

https://docs.python.org/3.6/library/multiprocessing.html?#module-multiprocessing.sharedctypes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32291>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:24:53 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Sep 2018 03:24:53 +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: <1538277893.16.0.545547206417.issue32756@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32756>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:40:20 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Sep 2018 03:40:20 +0000
Subject: [issue32833] argparse doesn't recognise two option aliases as equal
In-Reply-To: <1518448195.82.0.467229070634.issue32833@psf.upfronthosting.co.za>
Message-ID: <1538278820.67.0.545547206417.issue32833@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

I'm going to close this issue.  The current behavior is a logical consequence of how option_strings and abbreviations are handled.  Handling this particular case differently would be require adding a special test, as opposed to a minor tweak to the current code.

It could be reopened if some one wrote a clever and complete patch (and/or made a compelling case that it is needed).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32833>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:52:14 2018
From: report at bugs.python.org (Fantix King)
Date: Sun, 30 Sep 2018 03:52:14 +0000
Subject: [issue34847] asyncio: Add PHA for TLS 1.3
Message-ID: <1538279534.68.0.545547206417.issue34847@psf.upfronthosting.co.za>


New submission from Fantix King <fantix.king at gmail.com>:

This was raised in GH-9460 where the same post handshake authentication (PHA) was added to the ssl module. It should be added to asyncio too. This issue is to discuss the design of PHA API in asyncio, and implement it in Python 3.8.

One approach is to add _SSLProtocolTransport.verify_client_post_handshake(), but an additional new transport mixin type to asyncio/transports.py would be needed (Yury).

Yury also proposed another option to use get_extra_info() API to get something like an "SSLExtra" object with additional APIs.

----------
components: asyncio
messages: 326700
nosy: asvetlov, fantix, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Add PHA for TLS 1.3
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34847>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:54:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 30 Sep 2018 03:54:16 +0000
Subject: [issue34847] asyncio: Add PHA for TLS 1.3
In-Reply-To: <1538279534.68.0.545547206417.issue34847@psf.upfronthosting.co.za>
Message-ID: <1538279656.36.0.545547206417.issue34847@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +9031
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34847>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:55:38 2018
From: report at bugs.python.org (Dan Snider)
Date: Sun, 30 Sep 2018 03:55:38 +0000
Subject: [issue34848] range.index only takes one argument when it's documented
 as taking the usual 3
Message-ID: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Unfortunately, it looks like there's no requirement for an abc.Sequence to implement the 3 argument form of seq.index, so I suppose this is technically just a documentation bug...

>>> range(5).index(2, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: index() takes exactly one argument (2 given)

>>> help(range.index)
Help on method_descriptor:

index(...)
    rangeobject.index(value, [start, [stop]]) -> integer -- return index of value.
    Raise ValueError if the value is not present.

----------
assignee: docs at python
components: Argument Clinic, Documentation
messages: 326701
nosy: bup, docs at python, larry
priority: normal
severity: normal
status: open
title: range.index only takes one argument when it's documented as taking the usual 3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34848>
_______________________________________

From report at bugs.python.org  Sat Sep 29 23:57:02 2018
From: report at bugs.python.org (Fantix King)
Date: Sun, 30 Sep 2018 03:57:02 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1538279822.92.0.545547206417.issue34745@psf.upfronthosting.co.za>


Change by Fantix King <fantix.king at gmail.com>:


----------
nosy: +fantix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Sun Sep 30 01:04:51 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 05:04:51 +0000
Subject: [issue34849] Drop logging when asyncio waits in selector.select()
Message-ID: <1538283891.7.0.545547206417.issue34849@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The waiting is the pretty normal case: no IO is performed and no immediate activities are scheduled.

Therefore logging such cases is just a noise.

----------
components: asyncio
messages: 326702
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Drop logging when asyncio waits in selector.select()
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34849>
_______________________________________

From report at bugs.python.org  Sun Sep 30 01:10:59 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 05:10:59 +0000
Subject: [issue34849] Drop logging when asyncio waits in selector.select()
In-Reply-To: <1538283891.7.0.545547206417.issue34849@psf.upfronthosting.co.za>
Message-ID: <1538284259.04.0.545547206417.issue34849@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +9032
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34849>
_______________________________________

From report at bugs.python.org  Sun Sep 30 01:28:44 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 05:28:44 +0000
Subject: [issue34849] Drop logging when asyncio waits in selector.select()
In-Reply-To: <1538283891.7.0.545547206417.issue34849@psf.upfronthosting.co.za>
Message-ID: <1538285324.21.0.545547206417.issue34849@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d5bd036138881bb90a803397d992870a46fbdc2d by Miss Islington (bot) (Andrew Svetlov) in branch 'master':
bpo-34849: Don't log wating for selector.select in asyncio loop iteration (GH-9641)
https://github.com/python/cpython/commit/d5bd036138881bb90a803397d992870a46fbdc2d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34849>
_______________________________________

From report at bugs.python.org  Sun Sep 30 02:02:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 06:02:51 +0000
Subject: [issue34848] range.index only takes one argument when it's documented
 as taking the usual 3
In-Reply-To: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>
Message-ID: <1538287371.87.0.545547206417.issue34848@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report Dan. It is easy to fix a docstring.

Related issues are issue28197 and issue31942.

----------
components:  -Argument Clinic
keywords: +easy (C)
nosy: +rhettinger, serhiy.storchaka -larry
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34848>
_______________________________________

From report at bugs.python.org  Sun Sep 30 02:15:41 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Sep 2018 06:15:41 +0000
Subject: [issue32552] Improve text for file arguments in
 argparse.ArgumentDefaultsHelpFormatter class
In-Reply-To: <1515976536.21.0.467229070634.issue32552@psf.upfronthosting.co.za>
Message-ID: <1538288141.67.0.545547206417.issue32552@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

https://bugs.python.org/issue28742
argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable

is asking for something similar - the ability to override the automatic `%(default)s` in certain cases.

The proposed fix is to look for a string that is already displaying a default, such as '(default:'.

    if '%(default)' not in action.help and '(default:' not in action.help:

----------
resolution: rejected -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32552>
_______________________________________

From report at bugs.python.org  Sun Sep 30 02:26:47 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 06:26:47 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538288807.06.0.545547206417.issue34476@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

`asyncio.sleep()` always pauses the current task and switches execution to another one.
`asyncio.sleep(0)` has no special meaning (but it has internal optimization for the case).

Basically the same as `time.sleep(0)` for multithreaded program.

I doubt if we need to blow the documentation with all possible related details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Sun Sep 30 02:45:52 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Sep 2018 06:45:52 +0000
Subject: [issue34744] New %(flag)s format specifier for argparse.add_argument
 help string
In-Reply-To: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>
Message-ID: <1538289952.59.0.545547206417.issue34744@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

https://bugs.python.org/issue13280, argparse should use the new Formatter class

Raymond Hettinger argued against making such a switch.

However there may be some value in allowing its use in parallel with the '%' style of formatting.  That is, if the 'help' string has '%(...)' use the '%' formatting, if it has '{}' compatible formats use the '.format' expression.  I think that can be done transparently; but I haven't tested it.

The reason I bring it up here, is that I think `.format' can provide the functionality this issue is asking for.

If I define an Action like:

    a1 = parser.add_argument('--foo', '-f', default='foobar'.
       help='help for {dest} or {option_strings[0]}, default is {default}'  

Then:

    a1.help.format(**vars(a1))                                                                                    

produces:

    'help for foo or --foo, default is foobar'

So if there is another reason to add new style formatting to help lines, it's worth keeping this issue in mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34744>
_______________________________________

From report at bugs.python.org  Sun Sep 30 02:50:24 2018
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Sep 2018 06:50:24 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1538290224.27.0.545547206417.issue13280@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

Thinking about https://bugs.python.org/issue34744, I realized that the new style formatting could provide some added flexibility to the help lines.

I think new style formatting could be added in parallel with the existing style, as an alternative, not as a replacement.

With that option a help line like:

'help for {dest} or {option_strings[0]} default is {default}'  

could be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Sun Sep 30 02:58:10 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 30 Sep 2018 06:58:10 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538290690.92.0.545547206417.issue34476@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

The issue is because the current documentation *doesn't* say that "`asyncio.sleep()` always pauses the current task and switches execution to another one", it just says that it "blocks for _delay_ seconds".

With that description a perfectly valid implementation could be further optimized with:

    async def sleep(delay):
        if delay <= 0:
            return
        ...

In which case `await sleep(0)` would *not* cause a task switch. And this is not an unreasonable thing to expect because there are many other potentially-switching situations in asyncio that sometimes don't cause a switch, such as await `queue.get()` from a non-empty queue or await `await stream.readline()` from a socket stream that has a line to provide.

The user who wants to implement a "yield control to event loop" has to look at the source to find out how delay==0 is handled, and then they have to wonder if it's an implementation detail. https://github.com/python/asyncio/issues/284 states that the behavior is explicit and here to stay, but that promise has never made it into the actual documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Sun Sep 30 03:14:00 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Sep 2018 07:14:00 +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: <1538291640.53.0.545547206417.issue30672@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Putting back to normal, as the difference between the C locale and the POSIX locale is that you never get the latter by default - you have to explicitly request it.

The underlying fix for this is in the PR for bpo-34589.

----------
dependencies: +Py_Initialize() and Py_Main() should not enable C locale coercion
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30672>
_______________________________________

From report at bugs.python.org  Sun Sep 30 03:14:09 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 30 Sep 2018 07:14:09 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1538291649.0.0.545547206417.issue32892@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

As a point of information, this did in fact break pylint/astroid: https://github.com/PyCQA/astroid/issues/617

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Sun Sep 30 03:22:56 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 30 Sep 2018 07:22:56 +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: <1538292176.24.0.545547206417.issue30672@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch
pull_requests: +9033
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30672>
_______________________________________

From report at bugs.python.org  Sun Sep 30 03:31:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 07:31:25 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1538292685.88.0.545547206417.issue32892@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yesterday I submitted a PR that should fix astroid in Python 3.8: https://github.com/PyCQA/astroid/issues/616

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Sun Sep 30 03:46:33 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 07:46:33 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538293593.43.0.545547206417.issue34476@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Adding "`asyncio.sleep()` always pauses the current task and switches execution to another one" sounds totally reasonable to me (without mentioning zero `delay` special case).

Would you make a pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Sun Sep 30 04:15:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 08:15:19 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
Message-ID: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Gregory have noticed that the "is" and "is not" operator sometimes is used with string and numerical literals. This code "works" on CPython by accident, because of caching on different levels (small integers and strings caches, interned strings, deduplicating constants at compile time). But it shouldn't work on other implementations, and can not work even on early or future CPython versions.

https://discuss.python.org/t/demoting-the-is-operator-to-avoid-an-identity-crisis/86

I think that the adequate solution of this issue is not demoting the "is" operator, but emitting a syntax warning. In general, this is a work for third-party checkers. But many people don't use checkers for their one-time scripts, using "is" with a literal is always a mistake, and it is easy to add a check for this in the compiler.

Currently the compiler emits SyntaxWarning only for parenthesis in assert: `assert(x, "msg")`. But in earlier versions there were more warnings (they are errors). In 3.8 yet one SyntaxWarning will be added instead of DeprecationWarning for unknown escape sequences in string literals.

The proposed PR makes the compiler emitting a SyntaxWarning when the "is" or "is not" operators are used with a constant (except singletons None, False, True and ...). A warning will be replaced with a SyntaxError if the warnings system is configured to raise errors. This is because SyntaxError contains more information and provides better traceback. The same change was made for "assert(...)". Added tests, including tests for "assert(...)".

Barry have noted that using the "==" operator with None can be also classified as an error. But I think that in this case there may be legal uses of this, and the compiler should not complain. It is a work for third-party checkers, which can provide configuration options for enabling and disabling particular kinds of checks.

----------
components: Interpreter Core
messages: 326714
nosy: barry, gregory.p.smith, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Emit a syntax warning for "is" with a literal
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 04:30:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 08:30:50 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538296250.28.0.545547206417.issue34850@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +9034
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 04:32:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 08:32:27 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538296347.88.0.545547206417.issue34850@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It also fixes an incorrect use of "is" with an empty string in IDLE.

----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 04:37:44 2018
From: report at bugs.python.org (Bnaya)
Date: Sun, 30 Sep 2018 08:37:44 +0000
Subject: [issue34851] re.error - for the search function in the re module
Message-ID: <1538296664.11.0.545547206417.issue34851@psf.upfronthosting.co.za>


New submission from Bnaya <bnaya.honig at gmail.com>:

I was writing the following:
re.search('([+-*])', "54  *  83")

And I got the following runtime error:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\re.py", line 183, in search
    return _compile(pattern, flags).search(string)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\re.py", line 286, in _compile
    p = sre_compile.compile(pattern, flags)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_compile.py", line 764, in compile
    p = sre_parse.parse(p, flags)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 930, in parse
    p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 426, in _parse_sub
    not nested and not items))
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 816, in _parse
    p = _parse_sub(source, state, sub_verbose, nested + 1)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 426, in _parse_sub
    not nested and not items))
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 580, in _parse
    raise source.error(msg, len(this) + 1 + len(that))
re.error: bad character range +-* at position 2

Note that for different operators order, such as:
re.search('([+*-])', "54  *  83")
or
re.search('([*+-])', "54  *  83")
the function worked just fine.

----------
components: Regular Expressions
messages: 326716
nosy: Bnaya, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.error - for the search function in the re module
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34851>
_______________________________________

From report at bugs.python.org  Sun Sep 30 04:45:54 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Sep 2018 08:45:54 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538297154.58.0.545547206417.issue34476@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +9035
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Sun Sep 30 04:49:31 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 30 Sep 2018 08:49:31 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538297371.15.0.545547206417.issue34476@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Agreed about the special case. Minor change suggestion:

    ``sleep()` always suspends the current task, allowing other tasks to run.

That is, replace "switches execution to another [task]" because there might not be other tasks or they might not be executable - the idea is to allow them to run. Also, replace "pause" with "suspend" (because when delay<=0 there is not really a discernible pause).

https://github.com/python/cpython/pull/9643

If you'd still prefer the previous wording, I'll amend the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Sun Sep 30 05:29:01 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 30 Sep 2018 09:29:01 +0000
Subject: [issue34851] re.error - for the search function in the re module
In-Reply-To: <1538296664.11.0.545547206417.issue34851@psf.upfronthosting.co.za>
Message-ID: <1538299741.6.0.545547206417.issue34851@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is not a bug. You are searching for the character range from "+" to "*", which is an invalid range because "+" > "*".

----------
nosy: +ronaldoussoren
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34851>
_______________________________________

From report at bugs.python.org  Sun Sep 30 06:20:06 2018
From: report at bugs.python.org (Kurt Roeckx)
Date: Sun, 30 Sep 2018 10:20:06 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1538302806.68.0.545547206417.issue32947@psf.upfronthosting.co.za>


Kurt Roeckx <kurt at roeckx.be> added the comment:

Do you have any idea when the next release will be? I think python is currently our biggest blocker for getting OpenSSL 1.1.1 in Debian testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Sun Sep 30 07:00:34 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 30 Sep 2018 11:00:34 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1538305234.89.0.545547206417.issue32947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The release candidates came out a couple of days ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Sun Sep 30 08:28:58 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 30 Sep 2018 12:28:58 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538310538.2.0.545547206417.issue34850@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I like this solution of a syntax warning for `is <literal>` and I agree that `== None` should not be a warning.

(And for what its worth, I strongly disagree with making `is` a hybrid sometimes-check-identity-sometimes-check-equality operator.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 08:45:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 12:45:20 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538311520.57.0.545547206417.issue34850@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Suggestions about the wording of the warning message are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 09:39:21 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 30 Sep 2018 13:39:21 +0000
Subject: [issue32808] subprocess.check_output opens an unwanted command line
 window after fall creator update
In-Reply-To: <1518173531.96.0.467229070634.issue32808@psf.upfronthosting.co.za>
Message-ID: <1538314761.06.0.545547206417.issue32808@psf.upfronthosting.co.za>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@Christian Heigele  Any additional information re: msg312034?  Thanks!

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32808>
_______________________________________

From report at bugs.python.org  Sun Sep 30 09:50:09 2018
From: report at bugs.python.org (Aymeric Augustin)
Date: Sun, 30 Sep 2018 13:50:09 +0000
Subject: [issue33727] Server.wait_closed() doesn't always wait for its
 transports to fihish
In-Reply-To: <1527829909.37.0.682650639539.issue33727@psf.upfronthosting.co.za>
Message-ID: <1538315409.25.0.545547206417.issue33727@psf.upfronthosting.co.za>


Aymeric Augustin <aymeric.augustin at m4x.org> added the comment:

I believe this is by design: the documentation says:

> The sockets that represent existing incoming client connections are left open.

`Server` doesn't keep track of active transports serving requests.

(That said, I haven't figured out what _waiters is here so I could be wrong.)

----------
nosy: +aymeric.augustin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33727>
_______________________________________

From report at bugs.python.org  Sun Sep 30 10:16:34 2018
From: report at bugs.python.org (Aymeric Augustin)
Date: Sun, 30 Sep 2018 14:16:34 +0000
Subject: [issue34852] Counter-intuitive behavior of Server.close() /
 wait_closed()
Message-ID: <1538316994.45.0.545547206417.issue34852@psf.upfronthosting.co.za>


New submission from Aymeric Augustin <aymeric.augustin at m4x.org>:

**Summary**

1. Is it correct for `Server.wait_closed()` (as implemented in asyncio) to be a no-op after `Server.close()`?
2. How can I tell that all incoming connections have been received by `connection_made()` after `Server.close()`?

**Details**

After calling `Server.close()`, `_sockets is None`, which makes `Server.wait_closed()` a no-op: it returns immediately without doing anything (as mentioned in https://bugs.python.org/issue33727).

I'm not sure why the docs suggest to call `wait_closed()` after `close()` if it's a no-op. My best guess is: "this design supports third-party event loops that requires an asynchronous API for closing servers, but the built-in event loops don't need that". Does someone know?

I wrote a very simple server that merely accepts connections. I ran experiments where I saturate the server with incoming client connections and close it. I checked what happens around `close()` (and `wait_closed()` -- but as it doesn't do anything after `close()` I'll just say `close()` from now on.)

The current implementation appears to work as documented, assuming an rather low level interpretation of the docs of `Server.close()`.

> Stop serving: close listening sockets and set the sockets attribute to None.

Correct -- I'm not seeing any `accept` calls in `BaseSelectorEventLoop._accept_connection` after `close()`.

> The sockets that represent existing incoming client connections are left open.

Correct -- if "existing incoming client connections" is interpreted as "client connections that have gone through `accept`".

> The server is closed asynchronously, use the wait_closed() coroutine to wait until the server is closed.
 
I'm seeing calls to `connection_made()` _after_ `close()` because `BaseSelectorEventLoop._accept_connection2` triggers `connection_made()` asynchronously with `call_soon()`.

This is surprising for someone approaching asyncio from the public API rather than the internal implementation. `connection_made()` is the first contact with new connections. The concept of "an existing incoming client connection for which `connection_made()` wasn't called yet" is unexpected.

This has practical consequences.

Consider a server that keeps track of established connections via `connection_made` and `connection_lost`. If this server calls `Server.close()`, awaits `Server.wait_closed()`, makes a list of established connections and terminates them, there's no guarantee that all connections will be closed. Indeed, new connections may appear and call `connection_made()` after `close()` and `wait_closed()` returned!

`wait_closed()` seems ineffective for this use case.

----------
components: asyncio
messages: 326725
nosy: asvetlov, aymeric.augustin, yselivanov
priority: normal
severity: normal
status: open
title: Counter-intuitive behavior of Server.close() / wait_closed()
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34852>
_______________________________________

From report at bugs.python.org  Sun Sep 30 10:45:48 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 30 Sep 2018 14:45:48 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538318748.38.0.545547206417.issue12782@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +9036

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Sun Sep 30 10:50:10 2018
From: report at bugs.python.org (Anel Hodzic)
Date: Sun, 30 Sep 2018 14:50:10 +0000
Subject: [issue34853] Python django cors
Message-ID: <1538319010.84.0.545547206417.issue34853@psf.upfronthosting.co.za>


New submission from Anel Hodzic <programeranel at gmail.com>:

API call gives the desired response when trying through browser or postman. 

from rest_framework import generics
from django.shortcuts import get_object_or_404
from .jsonserializer import GroupSerializer, SubgroupSerializer, ProductsSerializer
from .models import pGroups, pSubgroups, Products
from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/Group/")
# @cross_origin()

# Create your views here.

class GroupList(generics.ListCreateAPIView):
    queryset = pGroups.objects.all()
    serializer_class = GroupSerializer

But when i try to make that call using JQuery

let dropdown = $('#locality-dropdown');

dropdown.empty();

dropdown.append('<option selected="true" disabled>Choose product group</option>');
dropdown.prop('selectedIndex', 0);

const url = 'http://127.0.0.1:8000/Group/';

// Populate dropdown with list of provinces
$.getJSON(url, function (data) {
  $.each(data, function (key, entry) {
    console.log(entry.name);
    dropdown.append($('<option></option>').attr('value', entry.abbreviation).text(entry.name));
  })
});

I get the output :

Failed to load http://127.0.0.1:8000/Group/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Trying to set up the FLASK-CORS https://flask-cors.readthedocs.io/en/latest/

Im complete beginner in web programming

----------
messages: 326726
nosy: Anel Hodzic
priority: normal
severity: normal
status: open
title: Python django cors

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34853>
_______________________________________

From report at bugs.python.org  Sun Sep 30 10:50:42 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 30 Sep 2018 14:50:42 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538319042.1.0.545547206417.issue12782@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests:  -9036

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Sun Sep 30 10:52:25 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 30 Sep 2018 14:52:25 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1538319145.94.0.545547206417.issue12782@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Now that I think about this a bit better, this may be actually a problem as:

         with (yield something) as x:

is a more than valid use case that will be broken with the simple grammar rule :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Sun Sep 30 10:54:02 2018
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 30 Sep 2018 14:54:02 +0000
Subject: [issue34853] Python django cors
In-Reply-To: <1538319010.84.0.545547206417.issue34853@psf.upfronthosting.co.za>
Message-ID: <1538319242.24.0.545547206417.issue34853@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Hey Anel, this bug tracker is for issues with the Python language itself, not its libraries or usage.

Try the flask-cors issue tracker or stackoverflow for more help-oriented questions:

https://github.com/corydolphin/flask-cors

https://stackoverflow.com/

----------
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34853>
_______________________________________

From report at bugs.python.org  Sun Sep 30 11:33:55 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 30 Sep 2018 15:33:55 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538321635.96.0.545547206417.issue34850@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I have catched using `is` to do string equality check in our codebase by linters before. Not all my colleagues know what's not suitable here.

The only common and suitable case I can think of is programmers are exploring CPython internals, like what stackoverflow Q&As and some Python blogs.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 12:25:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 16:25:00 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
Message-ID: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Compiling a string annotation containing a lambda with keyword-only argument without default value causes a crash.

from __future__ import annotations
def f() -> (lambda *, x: x): pass

The following PR fixes this crash. It also fixes other errors:

* Removes a space between "lambda" and ":" in the representation of lambda without argument.

* Removes the final "*" (it is incorrect syntax) in the representation of lambda without *args and keyword-only arguments when compile from AST.

----------
components: Interpreter Core
messages: 326730
nosy: gvanrossum, lukasz.langa, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Crash in string annotations in lambda with keyword-only argument without default value
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 12:26:30 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 30 Sep 2018 16:26:30 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538324790.0.0.545547206417.issue34850@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The problem with a SyntaxWarning is that the wrong people will see it. It gets in the way of users of applications that happen to be written in Python.

scenarios:

(a) A Python interpreter gets upgraded, and suddenly the _users_ of an application start seeing nasty warnings when they invoke the tool that happens to be implemented in Python. Warnings that they have no power to do anything about.

(b) A developer installs the shiny new version of Python with the warning feature, then pip install's all of the dependencies for the application they are working on.  Some of those contain "is" problems so they're left in a situation where they either have to figure out how to fix code from N different transitive dependencies libraries that they are not the author of - or not use that Python version to ship their code.  Keep in mind that it is common for deps to be pinned to ranges of versions instead of "always the latest" so even when deps fix their code, many people won't see it for a long time.

These scenarios are real, this is exactly what happened with the DeprecationWarning added to the old md5.py and sha.py modules.

A warning raised at import time isn't even one that can be meaningfully caught in a well structured application.  Doing so requires importing the warnings module first thing and setting up warning filters before any other imports.  This is ugly boilerplate for anyone to need to resort to.

As much as I want us to do something to ameliorate this anti-pattern in code, I don't think a SyntaxWarning is a great way to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 12:29:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 16:29:33 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
In-Reply-To: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>
Message-ID: <1538324973.41.0.545547206417.issue34854@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +9037
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 12:35:38 2018
From: report at bugs.python.org (Aymeric Augustin)
Date: Sun, 30 Sep 2018 16:35:38 +0000
Subject: [issue34852] Counter-intuitive behavior of Server.close() /
 wait_closed()
In-Reply-To: <1538316994.45.0.545547206417.issue34852@psf.upfronthosting.co.za>
Message-ID: <1538325338.68.0.545547206417.issue34852@psf.upfronthosting.co.za>


Aymeric Augustin <aymeric.augustin at m4x.org> added the comment:

For now I will use the following hack:

    server.close()
    await server.wait_closed()

    # Workaround for wait_closed() not quite doing
    # what I want.
    await asyncio.sleep(0)

    # I believe that all accepted connections have reached
    # connection_made() at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34852>
_______________________________________

From report at bugs.python.org  Sun Sep 30 12:48:21 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 30 Sep 2018 16:48:21 +0000
Subject: [issue34851] re.error - for the search function in the re module
In-Reply-To: <1538296664.11.0.545547206417.issue34851@psf.upfronthosting.co.za>
Message-ID: <1538326101.99.0.545547206417.issue34851@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Perhaps we could improve that error message. If Ronald hand't pointed out the actual problem, it would have taken me a while to figure it out, too.

Maybe "bad character range +-* at position 2: starting character is after ending character"? Although I'll admit I haven't looked at the code to see if it knows enough to produce that kind of message without some serious refactoring.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34851>
_______________________________________

From report at bugs.python.org  Sun Sep 30 13:02:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 17:02:10 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538326930.23.0.545547206417.issue34850@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is a large difference with the DeprecationWarning in the md5 and sha modules.

A SyntaxWarning is emitted when the compiler compiles Python sources to bytecode. Since bytecode is cached in pyc files, you will see it at most once at first run of the application. If the application compiles Python files at install time, warnings will be emitted at that time, and will be not emitted when run the application. If the application is distributed with precompiled pyc files, the user will not see warnings at all. If the developer installs dependencies that contain this error, his will see a warning only once, and can either ignore it (taking the current state), or report a bug. Warnings will not annoy him when he debug his code.

In contrary, the DeprecationWarning was emitted every time when you import the md5 or sha modules.

Professional applications likely already use checkers which caught this error. This warning will help non-professional applications distributed as a single script or handful of scripts. Users of such application often seat near its author. In many cases the only user is its author.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 13:30:19 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Sun, 30 Sep 2018 17:30:19 +0000
Subject: [issue21165] Optimize str.translate() for replacement with substrings
 and non-ASCII strings
In-Reply-To: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za>
Message-ID: <1538328619.08.0.545547206417.issue21165@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
nosy: +sir-sigurd

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21165>
_______________________________________

From report at bugs.python.org  Sun Sep 30 13:55:56 2018
From: report at bugs.python.org (Eric Lindblad)
Date: Sun, 30 Sep 2018 17:55:56 +0000
Subject: [issue34855] batch file variables
Message-ID: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>


New submission from Eric Lindblad <lindblad at gmx.com>:

The development version code can set the variable EXTERNALS_DIR in two .bat files, but nowhere in a .bat file is set the variable EXTERNAL_DIR, the latter appearing in find_python.bat. I am not a Powershell user and so cannot interpret the content of the file .azure-pipelines/windows-steps.yml, where the variable EXTERNAL_DIR likewise appears, but, being familiar solely with .bat files would question whether a misprint had occurred in the below commit, as "%EXTERNAL_DIR%" rather than "%EXTERNALS_DIR%"?

https://github.com/python/cpython/commit/68d663cf85d1ac5eaf83482eed39c0a6f8093601#diff-60f6a0e6e49e5990c3ad465771fff9cd

committed on GitHub Jul 17, 2017

----------
components: Build
messages: 326735
nosy: lindblad
priority: normal
severity: normal
status: open
title: batch file variables
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Sun Sep 30 13:59:59 2018
From: report at bugs.python.org (Dr_Zaszus)
Date: Sun, 30 Sep 2018 17:59:59 +0000
Subject: [issue34835] Multiprocessing module update fails with pip3
In-Reply-To: <1538152000.15.0.545547206417.issue34835@psf.upfronthosting.co.za>
Message-ID: <1538330399.45.0.545547206417.issue34835@psf.upfronthosting.co.za>


Dr_Zaszus <asserov at gmail.com> added the comment:

Thank you! It's clear now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34835>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:07:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 18:07:10 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
In-Reply-To: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>
Message-ID: <1538330830.49.0.545547206417.issue34854@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2a2940e5c3e6d92f4fac5e9d361a1e224bb2f12e by Serhiy Storchaka in branch 'master':
bpo-34854: Fix compiling string annotations containing lambdas. (GH-9645)
https://github.com/python/cpython/commit/2a2940e5c3e6d92f4fac5e9d361a1e224bb2f12e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:07:22 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 18:07:22 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
In-Reply-To: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>
Message-ID: <1538330842.08.0.545547206417.issue34854@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9038

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:14:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 18:14:23 +0000
Subject: [issue34856] Make the repr of lambda containing the signature and
 body expression.
Message-ID: <1538331263.14.0.545547206417.issue34856@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

>>> f = lambda x, y=1: x+y
>>> f
<lambda x, y=1: x + y at 0x7f437cd27890>

Currently it is less informative: "<function <lambda> at 0x7f437cd27890>".

----------
components: Interpreter Core
messages: 326738
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make the repr of lambda containing the signature and body expression.
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34856>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:19:20 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 18:19:20 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
In-Reply-To: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>
Message-ID: <1538331560.67.0.545547206417.issue34854@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0f161b307969f86b4f8f31baf38f53f5462a9874 by Miss Islington (bot) in branch '3.7':
bpo-34854: Fix compiling string annotations containing lambdas. (GH-9645)
https://github.com/python/cpython/commit/0f161b307969f86b4f8f31baf38f53f5462a9874


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:22:03 2018
From: report at bugs.python.org (Frank Schaefer)
Date: Sun, 30 Sep 2018 18:22:03 +0000
Subject: [issue34771] test_ctypes failing on Linux SPARC64
In-Reply-To: <1537638972.94.0.956365154283.issue34771@psf.upfronthosting.co.za>
Message-ID: <1538331723.2.0.545547206417.issue34771@psf.upfronthosting.co.za>


Frank Schaefer <kelledin at gmail.com> added the comment:

Well, after perusing the ctypes callproc.c code, I found the hacks referenced by martin.panter and tried activating them with some SPARC64 #ifdefs:

--- python3.6-3.6.6.orig/Modules/_ctypes/callproc.c
+++ python3.6-3.6.6/Modules/_ctypes/callproc.c
@@ -1041,6 +1041,7 @@ GetComError(HRESULT errcode, GUID *riid,
 #endif
 
 #if (defined(__x86_64__) && (defined(__MINGW64__) || defined(__CYGWIN__))) || \
+    (defined(__sparc_v9__) || (defined(__sparc__) && defined(__arch64__))) || \
     defined(__aarch64__)
 #define CTYPES_PASS_BY_REF_HACK
 #define POW2(x) (((x & ~(x - 1)) == x) ? x : 0)


This is based on #ifdef checks in libffi, but somewhat more generalized.  The good news is, this appears to resolve all test_ctypes failures.  So I'm guessing this is necessary on Linux/SPARC64, though I can't tell if it's necessary for Solaris/SPARC64.  I don't even know what built-in compiler defines get turned on for Solaris, though someone else might.

It might also be advisable to backport this to Python 2.7, but obviously we should also backport the additional ctypes tests if we do that.

My biggest concern is, do these hacks have a purely performance-centric impact, or do they potentially degrade functionality as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34771>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:28:54 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 30 Sep 2018 18:28:54 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538332134.78.0.545547206417.issue34850@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This is a nice approach to the problem.  I completely agree that we cannot change `is` semantics.  I'm okay with leaving it to checkers to catch `== None`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:31:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 18:31:16 +0000
Subject: [issue34856] Make the repr of lambda containing the signature and
 body expression.
In-Reply-To: <1538331263.14.0.545547206417.issue34856@psf.upfronthosting.co.za>
Message-ID: <1538332276.75.0.545547206417.issue34856@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +9039
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34856>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:33:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 18:33:39 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
In-Reply-To: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>
Message-ID: <1538332419.16.0.545547206417.issue34854@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

These bugs was found when working on issue34856.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:41:05 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 30 Sep 2018 18:41:05 +0000
Subject: [issue34854] Crash in string annotations in lambda with keyword-only
 argument without default value
In-Reply-To: <1538324973.45.0.668975606942.issue34854@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKtM7ZXhindpNacupDRFff-TLSQOVR+cQQZvc-ObZFP4Q@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Should go to @ambv.

On Sun, Sep 30, 2018 at 9:29 AM Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:
>
>
> ----------
> keywords: +patch
> pull_requests: +9037
> stage:  -> patch review
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34854>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34854>
_______________________________________

From report at bugs.python.org  Sun Sep 30 14:41:05 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 30 Sep 2018 18:41:05 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538326930.23.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+Xq9uSu5Wz9QbovJosKarsF5V4P70ZmEL+OqZHkymgMQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yet, Greg?s point is that this only works if the developer tests their code
with the new Python version.

I?m not sure that his proposal is better though. I think static checkers
are the better remedy.

On Sun, Sep 30, 2018 at 10:02 AM Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> There is a large difference with the DeprecationWarning in the md5 and sha
> modules.
>
> A SyntaxWarning is emitted when the compiler compiles Python sources to
> bytecode. Since bytecode is cached in pyc files, you will see it at most
> once at first run of the application. If the application compiles Python
> files at install time, warnings will be emitted at that time, and will be
> not emitted when run the application. If the application is distributed
> with precompiled pyc files, the user will not see warnings at all. If the
> developer installs dependencies that contain this error, his will see a
> warning only once, and can either ignore it (taking the current state), or
> report a bug. Warnings will not annoy him when he debug his code.
>
> In contrary, the DeprecationWarning was emitted every time when you import
> the md5 or sha modules.
>
> Professional applications likely already use checkers which caught this
> error. This warning will help non-professional applications distributed as
> a single script or handful of scripts. Users of such application often seat
> near its author. In many cases the only user is its author.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34850>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 16:10:30 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 30 Sep 2018 20:10:30 +0000
Subject: [issue34857] IDLE: SyntaxWarning not handled properly
Message-ID: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 3.6.6, """compile("assert (0, 'bad')", '', 'single')""" in Python or IDLE emits "SyntaxWarning: assertion is always true, perhaps remove parentheses?".

In Python,
>>> assert (0, 'bad')
<stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?

In IDLE's Shell, the same statement is effectively treated as incomplete in that newlines are echoed and IDLE waits for input until something is entered.  KeyboardInterrupt (^C) or any text terminate the loop.  In the latter case, "SyntaxError: multiple statements found while compiling a single statement" is printed.

In a file, the statement has no effect, but the warning should be printed in the shell.

----------
assignee: terry.reedy
components: IDLE
messages: 326745
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: SyntaxWarning not handled properly
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34857>
_______________________________________

From report at bugs.python.org  Sun Sep 30 16:38:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 30 Sep 2018 20:38:24 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538339904.47.0.545547206417.issue34850@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +9040

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 16:54:25 2018
From: report at bugs.python.org (Dan Snider)
Date: Sun, 30 Sep 2018 20:54:25 +0000
Subject: [issue34848] range.index only takes one argument when it's documented
 as taking the usual 3
In-Reply-To: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>
Message-ID: <1538340865.05.0.545547206417.issue34848@psf.upfronthosting.co.za>


Dan Snider <mr.assume.away at gmail.com> added the comment:

So I also just happened to notice that the "documentation is wrong" for list, tuple, and collections.deque. They use use _PyEval_SliceIndexNotNone whch causes this:

>>> s = 'abcde'
>>> s.index('d', 0, None)
3
>>> [*s].index('d', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    [*s].index('d', None)
TypeError: slice indices must be integers or have an __index__ method

In 3.6.0, that error message is:
    TypeError: slice indices must be integers or None or have an __index__ method

which means someone else was aware of this behavior and switched from _PyEval_SliceIndex to _PyEval_SliceIndexNotNone but didn't think these inconsistencies were inappropriate?

Anyway, I'll go ahead fix the docs later for accuracy's sake, but I'd much rather update operator.indexOf to use a new abstract api function: "PySequence_IndexOf" or some such, which is also capable of handling starting from the tail like str.rindex. 

If that's something that could be done, after I finish the Python prototype of this sequence ChainMap analog and rewrite it in C, I'll have made my own abstract sequence index function which I'd happily share.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34848>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:04:08 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 30 Sep 2018 21:04:08 +0000
Subject: [issue34856] Make the repr of lambda containing the signature and
 body expression.
In-Reply-To: <1538332276.79.0.668975606942.issue34856@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+vy+=i9T9dWiC=oLynHbk1KN+HqdMnydGaMV284UwtQg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

OTOH the current repr is bounded. Some people write very long lambdas.

On Sun, Sep 30, 2018 at 11:31 AM Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:
>
>
> ----------
> keywords: +patch
> pull_requests: +9039
> stage:  -> patch review
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34856>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34856>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:13:35 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 30 Sep 2018 21:13:35 +0000
Subject: [issue33533] Provide an async-generator version of as_completed
In-Reply-To: <1526453333.0.0.682650639539.issue33533@psf.upfronthosting.co.za>
Message-ID: <1538342015.66.0.545547206417.issue33533@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

If there is interest in this, I'd like to attempt a PR for a sync/async variant of as_completed.

Note that the new docs are *much* clearer, so the first (documentation) problem from the description is now fixed. Although the documentation is still brief, it now contains the key pieces of information: 1) that the futures are actually run in parallel, and 2) that each yielded future produces the next result that becomes available. Neither was actually stated in the old docs (!), so this is a marked improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33533>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:17:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 30 Sep 2018 21:17:21 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538342241.85.0.545547206417.issue34850@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 5fa247d60d4f3f2b8c8ae8cb57363aca234344c2 by Terry Jan Reedy in branch 'master':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/5fa247d60d4f3f2b8c8ae8cb57363aca234344c2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:17:30 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 21:17:30 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538342250.2.0.545547206417.issue34850@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9041

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:17:37 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 21:17:37 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538342257.06.0.545547206417.issue34850@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +9042

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:23:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 30 Sep 2018 21:23:18 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538342598.85.0.545547206417.issue34850@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To me, this issue is about unnecessary dependence on implementation details, with the particular example being 'is' versus '=='.  Perhaps PEP8, Programming Recommendations, should have a new subsection 'Implementation Dependencies' to recommend against such dependency when not necessary.

Although IDLE depends on CPython's tkinter, I agree that it should follow this principle.  I extracted the idlelib change to PR9649 to be applied and backported regardless of the fate of Serhiy's main proposal.

At least on Windows, "assert (0, 'bad')" raises SyntaxWarning in freshly compiled 3.6.7+ but not in 3.7.1+ or 3.8.

[A separate issue (#34857): the warning is not displayed in IDLE and the warning in the Shell causes looping.]

----------
assignee: terry.reedy -> serhiy.storchaka
components:  -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:35:57 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 21:35:57 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538343357.63.0.545547206417.issue34850@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 214c0b3d153c4bad14086888b9de0826a7abc083 by Miss Islington (bot) in branch '3.7':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/214c0b3d153c4bad14086888b9de0826a7abc083


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:41:00 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Sep 2018 21:41:00 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538343660.04.0.545547206417.issue34850@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cb0bec37dd8279555bc01fa03a259eaf7dbb6d5d by Miss Islington (bot) in branch '3.6':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/cb0bec37dd8279555bc01fa03a259eaf7dbb6d5d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 17:46:39 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 30 Sep 2018 21:46:39 +0000
Subject: [issue34751] Hash collisions for tuples
In-Reply-To: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>
Message-ID: <1538343999.3.0.545547206417.issue34751@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

An "aha!" moment for me:  I noted before that replacing the tuple hash loop with

    Py_uhash_t t = (Py_uhash_t)y;
    t ^= t << 1;
    x = (x * mult) + t;

does OK (64-bit build):  most tests had no collisions, but the original tuple test had 24 (a modest failure) and the new one 6.

Horrible results with a different scheme prompted me to add one line before the shift-xor:

    t = (t >> 3) | (t << 61);

That is, merely rotate the input right by 3 bits first.  Disaster!  Almost all tests suffered major collisions, and the old test 235424 and the new one 344919.

What's going on?  With hindsight, it's obvious:  multiplication is a horrible "mixer" _in this context_.  Because nearly all the tests are slinging little integers, almost all the input variation is in the last handful of bits.  Multiplication is great for spreading low-order bits around.  But rotate them to the high end, and multiplication is next to useless:  it only propagates them "to the left", and they're already at the left end then.  This part has virtually nothing to do with whether + or ^ is used, or with whether multiplication is done before or after.  It's actually the multiplication that's the weakness, and has nothing to do with which multiplier is used.

This isn't a problem with FNV or DJB when used _as intended_, because their output is much wider than their inputs.  The high-order bit of an input for them is still a lower-order bit to their much wider multiplication, and eventually propagates.  It isn't a problem for "multiplicative hashing" algorithms either, because those use a double-width multiply and only retain the _high_ half of a double-width product.  We're only retaining the _lower_ half.

I also noted before that replacing the shift-xor with the frozenset hash's input scrambler:

    t = ((t ^ 89869747UL) ^ (t << 16)) * 3644798167UL;

worked great.  But it's equally a disaster if the inputs are rotated right by 3 first.  Same reason:  it too only propagates "to the left".

So almost all tuple hash schemes on the table, both current and various experiments here, are systematic disasters if input hashes vary mostly in the high-order bits.  We haven't noticed because the current string hashes vary about the same in all bit positions, while contiguous ranges of not-huge ints have hashes that vary in the low-order bits.

The only schemes in all these messages that are "obviously immune" are those that used a (any) flavor of FNV or DJB as intended, treating each input hash as a sequence of unsigned bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34751>
_______________________________________

From report at bugs.python.org  Sun Sep 30 18:24:41 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 30 Sep 2018 22:24:41 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538346281.49.0.545547206417.issue34850@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Would it make sense to implement a "chaos" mode (that e.g. testing tools could enable unconditionally), that disables the small integer and small string caches?

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 21:39:36 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 01 Oct 2018 01:39:36 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538357976.94.0.545547206417.issue34850@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

If we were to ship a "chaos" mode in the CPython interpreter itself, I assume you envision an interpreter flag and/or env var?  If it required someone compiling the interpreter a special way I don't think it would be widely adopted within continuous integration testing systems.

I was actually pondering doing a "chaos" mode of sorts at work because I have the power to cause everyone's tests to be run that way mode by default.  (I'd basically just disable interning and str/int singletons)  But while it's a nice idea, it's low on my work priorities.  While we had thousands of is literal comparisons that we're about to fix en-masse, they are only a tiny fraction of all literal comparisons in our codebase.  And pylint is now more widely used which should help prevent new ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 21:56:32 2018
From: report at bugs.python.org (Michael Smith)
Date: Mon, 01 Oct 2018 01:56:32 +0000
Subject: [issue34858] MappingProxy objects should JSON serialize just like a
 dictionary
Message-ID: <1538358992.7.0.545547206417.issue34858@psf.upfronthosting.co.za>


New submission from Michael Smith <michael at smith-li.com>:

If a mappingproxy object is a read-only proxy to a mapping, would it make sense for them to JSON serialize just like the mapping they come from? Currently, json.dumps throws the "I don't know how to serialize this" error:

$ python -c 'import json
> import types
> json.dumps(types.MappingProxyType({}))'
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "/usr/lib64/python3.6/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/usr/lib64/python3.6/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib64/python3.6/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/usr/lib64/python3.6/json/encoder.py", line 180, in default
    o.__class__.__name__)
TypeError: Object of type 'mappingproxy' is not JSON serializable

----------
components: Library (Lib)
messages: 326756
nosy: Michael Smith2
priority: normal
severity: normal
status: open
title: MappingProxy objects should JSON serialize just like a dictionary
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/issue34858>
_______________________________________

From report at bugs.python.org  Sun Sep 30 22:09:04 2018
From: report at bugs.python.org (ppperry)
Date: Mon, 01 Oct 2018 02:09:04 +0000
Subject: [issue33065] IDLE debugger: failure stepping through module loading
In-Reply-To: <1520917336.65.0.467229070634.issue33065@psf.upfronthosting.co.za>
Message-ID: <1538359744.8.0.545547206417.issue33065@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

Line 59 isn't actually executed; the error comes from the trace event that gets fired before line 59, which is the first `line` event in the frame containing the uninitialized _ModuleLock.

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33065>
_______________________________________

From report at bugs.python.org  Sun Sep 30 22:26:28 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Oct 2018 02:26:28 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1538360788.93.0.545547206417.issue34313@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since this was opened, I have opened files in the editor, without incident with both installed 3.7.0 and 3.7.1rc1 (64 bit).  Should this still stay open?  Does anyony have any problems with the current release candidates?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Sun Sep 30 22:32:44 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 01 Oct 2018 02:32:44 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1538361164.38.0.545547206417.issue34850@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Yeah, something like that. Or sys.enable_chaos_mode(), that pytest or whoever could call before running tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sun Sep 30 22:33:52 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Oct 2018 02:33:52 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1538361232.31.0.545547206417.issue34370@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I just installed 3.7.1rc on current High Sierra and observed same as Vlad.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Sun Sep 30 23:26:23 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Oct 2018 03:26:23 +0000
Subject: [issue34858] MappingProxy objects should JSON serialize just like a
 dictionary
In-Reply-To: <1538358992.7.0.545547206417.issue34858@psf.upfronthosting.co.za>
Message-ID: <1538364383.68.0.545547206417.issue34858@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

IIRC, there was an early decision to handle only exact types and their subclasses (plus tuples).  For example, os.environ and instances of collections.ChainMap are not JSON serializable.

I believe the reason was that it made encoding faster, more predictable, and more likely to match round-trip expectations.  For those wanting more generality, there are at least two options.  The simplest option is to coerce the input to supported type.  A more complete solution is to write a subclass of JSONEncoder to pass into json.dump() as the *cls* argument (there are examples of how to do this in the docs).

For the specific case of mappingproxy, there is another issue.  Multiple components of a class dict are not all JSON serializable, so you have the same problem yet again with getset_descriptor objects, member objects, and various slot wrappers.

----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito, rhettinger
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34858>
_______________________________________

From report at bugs.python.org  Sun Sep 30 23:49:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Oct 2018 03:49:27 +0000
Subject: [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1538365767.29.0.545547206417.issue34804@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Though stylistically odd, the repeated text is correct.  If Andrew feels like amending it, that would be nice; otherwise, I don't think it is worth the micro-edit.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34804>
_______________________________________