[issue34282] Enum._convert shadows members named _convert

[orlnub123]

orlnub123  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34562] cannot install versions 3.6.5+ on Windows

[Zyg]

New submission from Zyg :

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/file4/Python 3.7.0 
(32-bit)_20180901123914.log

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34499] Extend registering of single-dispatch functions to parametrized generic pseudo-types

[Ivan Levkivskyi]

Ivan Levkivskyi  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to false assumptions

[Michael Felt]

Michael Felt  added the comment:

On 28/08/2018 23:14, STINNER Victor wrote:
> STINNER Victor  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 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34200] importlib: python -m test test_pkg -m test_7 fails randomly

[Lorenz Mende]

Lorenz Mende  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34563] invalid assert on big output of multiprocessing.Process

[Oleksandr Buchkovskyi]

New submission from Oleksandr Buchkovskyi :

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34563] invalid assert on big output of multiprocessing.Process

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34563] invalid assert on big output of multiprocessing.Process

[Oleksandr Buchkovskyi]

Change by Oleksandr Buchkovskyi :


--
pull_requests: +8493

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34563] invalid assert on big output of multiprocessing.Process

[Oleksandr Buchkovskyi]

Change by Oleksandr Buchkovskyi :


--
pull_requests: +8494

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34282] Enum._convert shadows members named _convert

[Ethan Furman]

Ethan Furman  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34200] importlib: python -m test test_pkg -m test_7 fails randomly

[Brett Cannon]

Brett Cannon  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34561] Replace list sorting merge_collapse()?

[Tim Peters]

Tim Peters  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34555] AF_VSOCK not unset because of wrong nesting

[Benjamin Peterson]

Benjamin Peterson  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34555] AF_VSOCK not unset because of wrong nesting

[miss-islington]

Change by miss-islington :


--
pull_requests: +8495

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34555] AF_VSOCK not unset because of wrong nesting

[miss-islington]

miss-islington  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34282] Enum._convert shadows members named _convert

[orlnub123]

orlnub123  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34282] Enum._convert shadows members named _convert

[Ethan Furman]

Ethan Furman  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com