[issue41892] use both "for in" and "ElementTree.remove" has a index bug

[Stefan Behnel]

Change by Stefan Behnel :


--
versions: +Python 3.10, Python 3.9

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> it's totally clear to me what @total_ordering should do 
> -- it should define __le__, __gt__ and __ge__ in terms 
> of __lt__, and leave __lt__ alone, for some subclass to 
> implement.

+1

--

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Tom Karzes]

Tom Karzes  added the comment:

Thanks Tim and Terry.  Stackless Python sounds interesting.  It's nice to know 
that others had the same idea I did, although I tend to shy away from exotic 
variants since they tend to be less well-supported.  Any chance that CPython 
will go stackless at some point in the future?

By the way, I saw that I can increase the process stack limit from within a 
Python app:

resource.setrlimit(resource.RLIMIT_STACK, (resource.RLIM_INFINITY,
   resource.RLIM_INFINITY))

I tried it, and it works (on my Linux system), but of course is unavailable on 
Windows systems.

--

___
Python tracker 

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

[issue41887] ast.literal_eval does not accept strings with leading whitespaces

[Guido van Rossum]

Guido van Rossum  added the comment:

[Terry]
> But why should not parsing remove indents for 'eval' mode?

I dunno, but it's been doing this since 1992, so I think it would be fragile to 
change. The best thing therefore is to make ast.literal_eval() match it exactly.

--

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Guido van Rossum]

Guido van Rossum  added the comment:

I still like to have a helper that recalculates the abstractness status of a 
class after adding some new methods (or deleting some).

I would prefer the isinstance(cls, ABCMeta) check to be inside that helper, so 
that you could call it unconditionally after adding/deleting methods: 
abc.update_abstractmethods(cls).  (It doesn't really need a comment saying 
"Update abstract methods" either. :-)

In fact, its signature makes the helper feasible as a class decorator itself, 
so that users who are using a mixin class decorator that doesn't update 
abstractness can add it conveniently themselvs. E.g. suppose @total_ordering 
didn't make this call itself, then the user could write

@abc.update_abstractmethods
@functools.total_ordering
class MyClass(SomeAbstractBaseClass):
def __lt__(self, other):
whatever

But I think it would be nice if @total_ordering and @dataclass did include this 
call.

However, I don't see why @total_ordering needs to be changed to also override 
abstract methods *defined in the decorated class*.  If I write

@functools.total_ordering
class MyAbstractClass(abc.ABC):
@abc.abstractmethod
def __lt__(self, other):
return NotImplemented

it's totally clear to me what @total_ordering should do -- it should define 
__le__, __gt__ and __ge__ in terms of __lt__, and leave __lt__ alone, for some 
subclass to implement.

With these two amendments, the changes to dataclasses.py and functools.py are 
limited to two lines (adding the call to abc.update_abstractmethod(cls)), plus 
an import change.

--

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I'm going to ignore this issue until you two have reached agreement.
> I recommend using some example code.

That won't be necessary.  I now understand what the OP is trying to do and am 
going to recommend against it.  

Guido, this really a decision for you to make.  Formerly ABC logic existed 
independent of any other class logic.  Nothing else in the standard library or 
in third-party tooling was required to take it into account.  A developer could 
leave or take it if they pleased.

The OP is proposing much tighter coupling and interdependence.  Effectively, he 
wants two new general rules to apply pervasively to existing tooling that 
previously had no reason to interact with ABCs at all.

1) When checking to see if a method exists, perhaps by using hasattr(), it 
should exclude abstract methods as determined by a follow-up getattr() call.

2) If a tool dynamically adds a method, it has duty to call 
update_abstractmethods() if even a slim possibility exists that ABCs are being 
used.

Presumably, none of this is unique to the total_ordering() decorator and it 
would apply to anything that dynamically inspects or updates classes whether by 
direct call, by class decorator, or by metaclass.

My recommendation is to not go down this path.  In the particular case of 
total_ordering(), the value add is slightly above zero.  In the decade long 
history of ABCs and the total_ordering() decorator, the need for this has 
arisen zero times.

P.S.  In the standard library, only the numbers module has ABCs with abstract 
rich comparison methods.  Typically, these would be used by registering the ABC 
rather than by inheriting from it.  That may be one reason why this hasn't come 
up.

--

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Tim Peters]

Tim Peters  added the comment:

Right, generators played no essential role here. Just one way of piling up a 
tall tower of C stack frames.

Search the web for "stackless Python" for the history of attempts to divorce 
the CPython implementation from the platform C stack.

There are ways to increase the main thread's stack size on Windows too using 
MSVC, but unless someone is extremely knowledgeable and willing to write some 
assembler to help out, they need to change it via a Windows linker option when 
the .exe is built, or via the EDITBIN developer tool (to modify the .exe file).

--

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Another "We are not responsible, proceed at your own risk" operation is 
importing ctypes, which allows one to overwrite bytes in the running python.

--
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> 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

[issue41911] Language reference incorrectly says comparison expressions return boolean values

[Terry J. Reedy]

Terry J. Reedy  added the comment:

For rich comparisons, a proper explanation is given in the rich comparison 
entry in the datamodel section ( #41910) 

"A rich comparison method may return the singleton NotImplemented if it does 
not implement the operation for a given pair of arguments. By convention, False 
and True are returned for a successful comparison. However, these methods can 
return any value, so if the comparison operator is used in a Boolean context 
(e.g., in the condition of an if statement), Python will call bool() on the 
value to determine if the result is true or false."

bool(x) calls x.__bool__ and requires that the latter return False or True.

As for the other two comparisons, x is y always returns False or True for a 
proper implementation because int == int always does.  If y.__contains__(x) 
does not raise, x in y returns bool(y.__contains__(x)), clamping aberrant 
implementations of __contains__.

A replacement text might be 

"Comparisons normally yield boolean values: True or False.  But rich 
comparisons not in a Boolean context may yield anything."

Possibly link 'rich comparisons' to the datamodel section.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue41915] unittest.mock.create_autospec(Obj, instance=True) has self keyword in _spec_signature if Obj implements __call__

[Ethan Tang US]

New submission from Ethan Tang US :

When an `unittest.mock.create_autospec(Obj, instance=True)` is used, and said 
Obj implements the `__call__(self, ...)` function, the mocked instance of it 
will take the full function signature including the `self` argument.

This will then cause an issue when `assert_called_once_with()` or 
`assert_called_with()` is used. Those two assertions will fail regardless if 
the arguments used were correct or not. The error message will contain the 
error: `TypeError: missing a required argument: 'self'`

Here an example of this issue happening

```
from unittest import mock

def Foo(object):

def __call__(self, a):
pass

def bar(self, b):
```This is to just compare it with a regular function.```
pass

foo_mock = mock.create_autospec(Foo, instance=True)
foo_mock(a=1)

foo_mock.assert_called_once_with(a=1)
```

In the example above, the assertion will then fail and raise an error even 
though the assertion should be correct.

upon inspecting further to understand the issue, this is because 
`foo_mock._spec_signature` will be ``.

The existence of `self` in `foo_mock._spec_signature` will cause this error.

As compared to the method `foo_mock.bar._spec_signature`, it will only be 
``.

The reason for me posting this issue is that development with the Keras library 
heavily uses __call__ in their API and therefore it is hard to mock the APIs if 
such issue exists. One work around would be iterating through its 
`called_args_list`.

--
components: Library (Lib)
messages: 377846
nosy: ettang
priority: normal
severity: normal
status: open
title: unittest.mock.create_autospec(Obj, instance=True) has self keyword in 
_spec_signature if Obj implements __call__
versions: Python 3.6

___
Python tracker 

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

[issue41910] Document that object.__eq__ implements `a is b`

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The word 'object' in this section is a bit confusing because it refers to any 
Python object, not to base class 'object' or an instance thereof.  I suspect 
that this usage predates the introduction of the latter in 2.2.

This interpretation is required for sentences like "By default, __ne__() 
delegates to __eq__() and inverts the result unless it is NotImplemented." and 
"If a class does not define an __eq__() method ..." (in the __hash__ entry) to 
make sense.  I think that the meaning of 'object' should be stipulated at the 
top of the section and mention the existence of base class 'object', and maybe 
list which of the following methods it has, and that they are inherited by 
subclasses.

The base class __eq__ implementation is implied in this paragraph in the 
__hash__ entry.

"User-defined classes have __eq__() and __hash__() methods by default; with 
them, all objects compare unequal (except with themselves) and x.__hash__() 
returns an appropriate value such that x == y implies both that x is y and 
hash(x) == hash(y)."

I think it worthwhile explaining that user classes get these defaults by 
inheriting them (and others) from 'object', and that the implication follows 
from inheriting a particular base class implementation of __eq__.  To put it 
another way, I believe the quoted paragraph makes the  definition a Python 
requirement rather than just a CPython implementation detail.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue41913] EnvBuilder.install_scripts should use explicit permissions

[Johan Herland]

Change by Johan Herland :


--
nosy: +jherland

___
Python tracker 

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

[issue41908] Make IDLE Start Menu entry more descriptive

[Eryk Sun]

Eryk Sun  added the comment:

> maybe we should consider moving the bitness to the folder title 
> (so the folder becomes "Python 3.8 64-bit")?

Splitting up the start-menu entries into separate "Python 3.9 (32-bit)" and 
"Python 3.9 (64-bit)" folders would reduce clutter in the folder when browsing 
the start menu. But the link names have to retain the bitness. If you type 
"idle" in the start menu, all you get is the link name, not the folder context, 
so the link name has to distinguish 32-bit vs 64-bit. Also, link names without 
bitness are already used by the Python store app distribution.

> On Windows, we could go for something, like
> Shell-Editor (3.9 64-bit)

Then searching for "idle" no longer works, which may be a practical trade-off 
considering novices are probably unfamiliar with IDLE.

With or without "IDLE" in the name, this only works well for novices that 
browse the start menu. It's not discoverable if the user just taps the WIN key 
and types "python". That search will return links to python.exe, which uses a 
system console session instead of the IDLE shell. If IDLE should be preferred, 
then maybe the name should be "Python 3.9 Shell+Editor (64-bit)".

--
nosy: +eryksun

___
Python tracker 

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

[issue41887] ast.literal_eval does not accept strings with leading whitespaces

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The doc for literal_eval says "evaluate ... a string containing a Python 
literal or container display."  To me, ' 1' qualifies, just as it does as an 
expression for eval().

The exception comes from parsing raising IndentationError with leading 
whitespace even when the mode is 'eval' rather than 'exec'.  This surprised me. 
Eval() gets strips the beginning of the string before it is parsed.  If parsing 
remains as is, I agree that doing the same for literal_eval strings.  But why 
should not parsing remove indents for 'eval' mode?

--
nosy: +terry.reedy
versions: +Python 3.10 -Python 3.6, Python 3.7

___
Python tracker 

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

[issue41584] Clarify documentation for binary arithmetic operation subclass __r*__ precedence

[Brett Cannon]

Change by Brett Cannon :


--
stage: patch review -> commit review

___
Python tracker 

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

[issue33533] Provide an async iterator version of as_completed

[Justin Arthur]

Change by Justin Arthur :


--
title: Provide an async-generator version of as_completed -> Provide an async 
iterator version of as_completed

___
Python tracker 

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

[issue41584] Clarify documentation for binary arithmetic operation subclass __r*__ precedence

[Brett Cannon]

Change by Brett Cannon :


--
keywords: +patch
pull_requests: +21516
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22505

___
Python tracker 

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

[issue41878] python3 fails to use custom mapping object as symbols in eval()

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Robert, this tracker is for patching CPython, not for debugging user code.  If, 
as it appears, you are not suggesting the former, please close this.  For the 
latter, python-list and stackoverflow.com are appropriate forums.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue41877] Check against misspellings of assert etc. in mock

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Vedran, you explained why many use pytest instead of unittest. But we have the 
latter and a stability policy.

I am not familiar with the existing mock code, but one already invented 
solution for misspelling tolerance without enumeration is the soundex 
algorithm.  I have not read the details for over a decade, but I belive 
soundex() = 'asrt' for all examples given here.  Perhaps it 
could be used to broaden the test.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue33533] Provide an async-generator version of as_completed

[Justin Arthur]

Justin Arthur  added the comment:

Thanks, Hrvoje. I've updated the patch to match this bug's suggested format and 
have updated the documentation and What's New.

The one quirk that comes with the benefit of getting the same futures back is 
that we still allow both coroutines and futures to be passed in. Coroutines 
will not be yielded back in their original form, but instead a new task.

--

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Guido van Rossum]

Guido van Rossum  added the comment:

I'm going to ignore this issue until you two have reached agreement. I 
recommend using some example code.

--

___
Python tracker 

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

[issue41866] Document error in chinese version of contextlib.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +mdk

___
Python tracker 

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

[issue18228] AIX locale parsing failure

[Irit Katriel]

Irit Katriel  added the comment:

Looks like this can be closed.

--
nosy: +iritkatriel
status: pending -> open

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Tom Karzes]

Tom Karzes  added the comment:

I tested this some more, and one thing became clear that I hadn't realized 
before:  This bug has nothing to do specifically with generators (as I had 
thought), but is in fact due purely to the recursion limit.

I created a recursive test program that doesn't use generators at all, and ran 
into the exact same problem (at only a slightly higher recursion level).  I am 
attaching that test case as recurse_bug4.py.  Here's a sample failing 
invocation:

% ./recurse_bug4.py 2
Segmentation fault (core dumped)
% 

On my system, the cutoff point for this one seems to be around 17600, roughly 
1100 higher than for the generator example.

What surprises me about this is the Python implementation uses recursion to 
implement recursion in Python apps.  I would have thought that it would use 
heap memory for something like this, and as a result only require a fixed 
amount of stack.  That would clearly have major advantages, since it would 
decouple recursion limits in Python code from stack limits on the platform.

On the other hand, now that I understand that this is in fact the result of a 
system limit, I was *very* easily able to work around the problem!  I simply 
disabled the stack limit.  From csh:

% unlimit stacksize
%

Then:

% ./gen_bug3.py 10
10
%

and:

% ./recurse_bug4.py 10
10
%

So you were right, this was due solely to the default stack limit on my system, 
and not a bug in the Python implementation.  And it was also very easy to 
remove that limit.  Hopefully something similar can be done on Windows (which I 
know very little about).

Thank you for your help!

--
Added file: https://bugs.python.org/file49487/recurse_bug4.py

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Tim Peters]

Tim Peters  added the comment:

There is no way in portable ANSI C to deduce a "safe" limit. The limits that 
exist were picked by hand across platforms, to be conservative guesses at what 
would "never" break.

You're allowed to increase the limit if you think you know better - and you 
may! No two platforms are the same. But - again - you do so at your own risk.  
There is no bug here unless you can provoke a crash _without_ overriding the 
default limit.

I was there when the limit was introduced. It was introduced precisely to avoid 
the vast array of strange system failures that can occur when the C stack 
overflows - and, again, there is no portable way to detect that "it's getting 
close" in ANSI C.  Stack sizes provided by platform C implementations are all 
over the place, from kilobytes to megabytes, and can also be different yet 
again for threads, and there is no portable way in C to find out what they are.

"""
For my friend using Windows, a value as low as 4000 suffices, which I don't 
think anyone would argue is unreasonably high.
"""

For the defaults provided by Microsoft's Visual C compiler (which CPython 
uses), it is unreasonably high - the C stack overflows.  In fact, under the 
released Python 3.8.5 on my 64-bit Windows, the largest value for which your 
program isn't obviously broken is about 2512.  If I don't override the default 
recursion limit on Windows, I cannot provoke a problem with your program on 
Windows (instead it dies - as designed and intended - with a `RecursionError` 
exception instead).

--

___
Python tracker 

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

[issue41914] test_pdb fails

[Sumagna Das]

Change by Sumagna Das :


--
title: test_pdb fails wit -> test_pdb fails

___
Python tracker 

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

[issue41914] test_pdb fails wit

[Sumagna Das]

New submission from Sumagna Das :

I was thinking about contributing to cpython so i cloned it and followed the 
tests mentioned on devguide.python.org. When i ran my tests, it failed on two 
of them: test_pdb and test_ssl. test_ssl had an issue already as i found here. 
test_pdb failure was the one which i didn't find here. It failed with the 
following message:

== CPython 3.10.0a0 (heads/master:a937ab45d6, Oct 3 2020, 00:16:29) [GCC 9.3.0]
== Linux-5.4.0-48-generic-x86_64-with-glibc2.31 little-endian
== cwd: /mnt/sda2/github/cpython/build/test_python_21809æ
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 1.52 Run tests in parallel using 2 child processes
0:00:06 load avg: 1.48 [1/1/1] test_pdb failed
test_blocks_at_first_code_line (test.test_pdb.PdbTestCase) ... ok
test_breakpoint (test.test_pdb.PdbTestCase) ... ok
test_errors_in_command (test.test_pdb.PdbTestCase) ... FAIL
test_find_function_empty_file (test.test_pdb.PdbTestCase) ... ok
test_find_function_found (test.test_pdb.PdbTestCase) ... ok
test_find_function_found_with_bom (test.test_pdb.PdbTestCase) ... ok
test_find_function_found_with_encoding_cookie (test.test_pdb.PdbTestCase) ... ok
test_header (test.test_pdb.PdbTestCase) ... ok
test_issue13120 (test.test_pdb.PdbTestCase) ... ok
test_issue13183 (test.test_pdb.PdbTestCase) ... ok
test_issue16180 (test.test_pdb.PdbTestCase) ... ok
test_issue36250 (test.test_pdb.PdbTestCase) ... ok
test_issue7964 (test.test_pdb.PdbTestCase) ... ok
test_module_is_run_as_main (test.test_pdb.PdbTestCase) ... ok
test_module_without_a_main (test.test_pdb.PdbTestCase) ... ok
test_readrc_homedir (test.test_pdb.PdbTestCase) ... ok
test_readrc_kwarg (test.test_pdb.PdbTestCase) ... ok
test_relative_imports (test.test_pdb.PdbTestCase) ... ok
test_relative_imports_on_plain_module (test.test_pdb.PdbTestCase) ... ok
test_run_module (test.test_pdb.PdbTestCase) ... ok
test_run_pdb_with_pdb (test.test_pdb.PdbTestCase) ... ok
test_list_commands (test.test_pdb)
Doctest: test.test_pdb.test_list_commands ... ok
test_next_until_return_at_return_event (test.test_pdb)
Doctest: test.test_pdb.test_next_until_return_at_return_event ... ok
test_pdb_basic_commands (test.test_pdb)
Doctest: test.test_pdb.test_pdb_basic_commands ... ok
test_pdb_breakpoint_commands (test.test_pdb)
Doctest: test.test_pdb.test_pdb_breakpoint_commands ... ok
test_pdb_continue_in_bottomframe (test.test_pdb)
Doctest: test.test_pdb.test_pdb_continue_in_bottomframe ... ok
test_pdb_displayhook (test.test_pdb)
Doctest: test.test_pdb.test_pdb_displayhook ... ok
test_pdb_issue_20766 (test.test_pdb)
Doctest: test.test_pdb.test_pdb_issue_20766 ... ok
test_pdb_next_command_for_asyncgen (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_asyncgen ... ok
test_pdb_next_command_for_coroutine (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_coroutine ... ok
test_pdb_next_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_for_generator ... ok
test_pdb_next_command_in_generator_for_loop (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_in_generator_for_loop ... ok
test_pdb_next_command_subiterator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_next_command_subiterator ... ok
test_pdb_return_command_for_coroutine (test.test_pdb)
Doctest: test.test_pdb.test_pdb_return_command_for_coroutine ... ok
test_pdb_return_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_return_command_for_generator ... ok
test_pdb_run_with_code_object (test.test_pdb)
Doctest: test.test_pdb.test_pdb_run_with_code_object ... ok
test_pdb_run_with_incorrect_argument (test.test_pdb)
Doctest: test.test_pdb.test_pdb_run_with_incorrect_argument ... ok
test_pdb_skip_modules (test.test_pdb)
Doctest: test.test_pdb.test_pdb_skip_modules ... ok
test_pdb_skip_modules_with_callback (test.test_pdb)
Doctest: test.test_pdb.test_pdb_skip_modules_with_callback ... ok
test_pdb_until_command_for_coroutine (test.test_pdb)
Doctest: test.test_pdb.test_pdb_until_command_for_coroutine ... ok
test_pdb_until_command_for_generator (test.test_pdb)
Doctest: test.test_pdb.test_pdb_until_command_for_generator ... ok
test_pdb_whatis_command (test.test_pdb)
Doctest: test.test_pdb.test_pdb_whatis_command ... ok
test_post_mortem (test.test_pdb)
Doctest: test.test_pdb.test_post_mortem ... ok

==
FAIL: test_errors_in_command (test.test_pdb.PdbTestCase)
--
Traceback (most recent call last):
  File "/mnt/sda2/github/cpython/Lib/test/test_pdb.py", line 1650, in 
test_errors_in_command
self.assertEqual(stdout.splitlines()[1:], [
AssertionError: Lists differ: ['(Pd[283 chars]efined", 'LEAVING RECURSIVE 
DEBUGGER', '(Pdb) ', '\x1b[?1034h'] != ['(Pd[283 chars]efined", 'LEAVING 
RECURSIVE DEBUGGER', '(Pdb) ']

First list contains 1 additional elements.
First extra element 9:
'\x1b[?1034h'

  ['(Pdb) *** 

[issue41912] Long generator chain causes segmentation fault

[Tom Karzes]

Tom Karzes  added the comment:

That is a good point, except I don't believe the value needed to expose this 
bug is a "too-high limit" (as the documentation calls it).  I set it to 100100 
for convenience, but in practice even a value of 17000 is more than enough to 
expose the bug on my system (it occurs at around 16500).  For my friend using 
Windows, a value as low as 4000 suffices, which I don't think anyone would 
argue is unreasonably high.

The default value of 1000 is extremely low, and is intended to catch recursion 
bugs in programs that are not expected to recurse very deeply.  For a program 
that genuinely needs recursion, I don't think a value of 2, or even 10, 
is unreasonable given today's typical memory sizes (and when I run my failing 
case, the memory usage is so low as to be inconsequential).  By my 
interpretation, these limits should be well within the range that Python can 
handle.

It seems likely to me that in this case, the problem isn't due to any kind of 
system limit, but is rather the result of a logical error in the implementation 
which is somehow exposed by this test.  Hopefully a developer will take 
advantage of this test case to fix what I believe is a serious bug.

--

___
Python tracker 

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

[issue36094] When using an SMTP SSL connection,, get ValueError.

[Alice Bevan-McGregor]

Alice Bevan-McGregor  added the comment:

Howdy!  One of my projects, Marrow Mailer (formerly TurboMail) has received a 
bit of a flood of reports and erroneous pull requests attempting to correct 
this bug in the invocation of smtplib by Mailer.

https://github.com/marrow/mailer/issues/83 is our own tracking issue, with 
https://github.com/marrow/mailer/pull/91 as the most "successful" pull request 
with more detailed (contextualized) traceback, comparison, and links to 
official documentation. (Also, yay, worked around the problem here by 
recovering my "native" issue tracker account rather than trying to sign in with 
GitHub.)

This appears to be a clear regression. The particular reason why I'm unwilling 
to accept these patches to Mailer is that passing a hostname at SMTP_SSL 
instantiation time will cause the connection to be initiated from within 
__init__ itself, prior to any ability to set the diagnostic logging level, 
which is boo, hiss. Initializers actually doing things is un-good, beyond 
diagnostic logging not being an optional keyword argument.  (Instantiation != 
procedural invocation.)

--
nosy: +amcgregor

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Tim Peters]

Tim Peters  added the comment:

The docs are already clear about that you play with `setrecursionlimit()` at 
your own risk:

"""
Set the maximum depth of the Python interpreter stack to limit. This limit 
prevents infinite recursion from causing an overflow of the C stack and 
crashing Python.

The highest possible limit is platform-dependent. A user may need to set the 
limit higher when they have a program that requires deep recursion and a 
platform that supports a higher limit. This should be done with care, because a 
too-high limit can lead to a crash.
"""

If you see a crash instead of a `RecursionError` exception when you _don't_ 
shoot yourself in the foot this way, that might be interesting. But, as is, 
you're deliberately overriding a mechanism designed to prevent these kinds of 
crashes.

--
nosy: +tim.peters

___
Python tracker 

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

[issue41906] logging.config.dictConfig does not work with callable filters

[Vinay Sajip]

Vinay Sajip  added the comment:

You make reasonable points. I won't close this issue, and get to those updates 
when I can/as time allows. Meanwhile, if you or someone else proposes specific 
changes by way of a pull request, I'll look at that too. And thanks for your 
kind words about the logging docs.

--

___
Python tracker 

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

[issue39710] "will be returned as unicode" reminiscent from Python 2

[Sumagna Das]

Sumagna Das  added the comment:

Can i take on this issue? If yes, what am I supposed to do except for removing 
those lines which are mentioned?

--
nosy: +sumagnadas

___
Python tracker 

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

[issue41913] EnvBuilder.install_scripts should use explicit permissions

[Frederik Rietdijk]

Frederik Rietdijk  added the comment:

Nixpkgs issue https://github.com/NixOS/nixpkgs/issues/99156.

--

___
Python tracker 

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

[issue41913] EnvBuilder.install_scripts should use explicit permissions

[Frederik Rietdijk]

New submission from Frederik Rietdijk :

Creating a venv with `python3 -m venv foo` and then reinitializing it with 
`python3 -m venv foo` fails with a `Error: [Errno 13] Permission denied: 
'/path/to/cwd/foo/bin/activate.fish'` with the CPython interpreters from 
Nixpkgs.

The method `EnvBuilder.install_scripts` that is responsible for copying the 
files, copies the permissions, instead of explicitly stating what permissions 
are needed. This fails with the Nixpkgs builds of CPython because in Nixpkgs 
the entire store is made read-only.

Files that need to be copied from the installation during run-time should be 
explicit about the permissions they require, instead of depending on their 
current permissions.

--
messages: 377828
nosy: Frederik Rietdijk
priority: normal
severity: normal
status: open
title: EnvBuilder.install_scripts should use explicit permissions
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue40391] io.FileIO.mode doesn't comply with the docs

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is a duplicate of issue25341.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> File mode wb+ appears as rb+

___
Python tracker 

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

[issue41912] Long generator chain causes segmentation fault

[Tom Karzes]

New submission from Tom Karzes :

If I create a sufficiently long chain of generators, I encounter a segmentation 
fault.  For example, the following works as expected:

% ./gen_bug3.py 1
1
%

But for sufficiently larger chain lengths, it seg faults:

% ./gen_bug3.py 2
Segmentation fault (core dumped)
%

and:

% ./gen_bug3.py 10
Segmentation fault (core dumped)
%

The exact point where it seg faults seems to vary slightly between different 
invocations of Python, but the range is very narrow for a given Python 
installation.  I believe the difference is due to slight variations in used 
memory upon startup.

I can't see any reason why this should happen, and in any case, if there is 
some limit that I'm exceeding, it should raise an exception rather than core 
dump.

I'm using:

3.6.9 (default, Jul 17 2020, 12:50:27)
[GCC 8.4.0]

on a 64-bit Ubuntu Linux system.

Additional info:  A friend of mine is running 3.7.9 on a Windows system.  In 
his case, the symptom is that the program produces no output for a sufficiently 
long generator chain (presumably it's silently crashing).  Additionally, he 
encounters the problem with much shorter generator chains than I do.  I suspect 
it's the same underlying problem.

--
components: Interpreter Core
files: gen_bug3.py
messages: 377826
nosy: karzes
priority: normal
severity: normal
status: open
title: Long generator chain causes segmentation fault
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file49486/gen_bug3.py

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Larry Hastings]

Larry Hastings  added the comment:

FWIW: I think David's cited behavior proves that the GIL is de facto a 
scheduler.  And, in case you missed it, scheduling is a hard problem, and not a 
solved problem.  There are increasingly complicated schedulers with new 
approaches and heuristics.  They're getting better and better... as well as 
more and more complex.  BFS is an example of that trend from ten years ago.  
But the Linux kernel has been shy about merging it, not sure why (technical 
deficiency? licensing problem? personality conflict? the name?).

I think Python's current thread scheduling approach is almost certainly too 
simple.  My suspicion is that we should have a much more elaborate 
scheduler--which hopefully would fix most (but not all!) of these sorts of 
pathological performance regressions.  But that's going to be a big patch, and 
it's going to need a champion, and that champion would have to be more educated 
about it than I am, so I don't think it's gonna be me.

--

___
Python tracker 

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

[issue41907] Regression in IntFlag behaviour in f-string

[Ethan Furman]

Change by Ethan Furman :


--
components: +Library (Lib) -Interpreter Core

___
Python tracker 

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

[issue41907] Regression in IntFlag behaviour in f-string

[Ethan Furman]

Change by Ethan Furman :


--
keywords: +patch
pull_requests: +21515
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22497

___
Python tracker 

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

[issue40391] io.FileIO.mode doesn't comply with the docs

[Irit Katriel]

Irit Katriel  added the comment:

The mode string is calculated here: 
https://github.com/python/cpython/blob/master/Modules/_io/fileio.c#L1055

and is based on these four values in the fileio struct:

unsigned int created : 1;
unsigned int readable : 1;
unsigned int writable : 1;
unsigned int appending : 1;

This is not enough information to distinguish between r+ and w+. That 
distinction was lost in _io_FileIO___init___impl, where it specified the flags 
that went into creating fd, but these flags are not saved.

The bit fields in this struct add up to 7 bits, so it seems possible to fix 
this if another bit is allocated for this purpose.

If it's not worth it, then the documentation needs to change a little.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[miss-islington]

miss-islington  added the comment:


New changeset 6dc8e0eb9b471f6665f841216a6b2d83741b3973 by Miss Islington (bot) 
in branch '3.9':
bpo-41802: Document 'PyDict_DelItem' can raise a 'KeyError' (GH-22291)
https://github.com/python/cpython/commit/6dc8e0eb9b471f6665f841216a6b2d83741b3973


--

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Ben Avrahami]

Ben Avrahami  added the comment:

This is a behavior that the PR changes. total_ordering should be able to 
override/implement abstract methods (in my opinion). If this ends up a 
strickling point then we can exclude total_ordering from this issue.

Regardless, I think that this behavior is extremely unintuitive.

--

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[miss-islington]

miss-islington  added the comment:


New changeset ab32ea8d79d6bfb6580d35bfc4aa42d2729c0bcf by Miss Islington (bot) 
in branch '3.8':
bpo-41802: Document 'PyDict_DelItem' can raise a 'KeyError' (GH-22291)
https://github.com/python/cpython/commit/ab32ea8d79d6bfb6580d35bfc4aa42d2729c0bcf


--

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Raymond Hettinger]

Raymond Hettinger  added the comment:

You might be misunderstanding what @total_ordering does.  It can't be used by 
subclasses to override abstract methods.

>>> from abc import abstractmethod, ABC
>>> from functools import total_ordering

>>> class X(ABC):
@abstractmethod
def __lt__(self, other):
raise RuntimeError('abstract called')

>>> @total_ordering
class Y(X):
def __le__(self, other):
return True

>>> sorted(vars(Y))# note that __lt__ is missing and Y() won't instantiate
['__abstractmethods__', '__doc__', '__ge__', '__gt__', '__le__', '__module__', 
'_abc_impl']

--

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +21513
pull_request: https://github.com/python/cpython/pull/22493

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[miss-islington]

Change by miss-islington :


--
pull_requests: +21514
pull_request: https://github.com/python/cpython/pull/22494

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 20ce62f00957d11f24f6449cd5c0ef5dd67174d4 by Campbell Barton in 
branch 'master':
bpo-41802: Document 'PyDict_DelItem' can raise a 'KeyError' (GH-22291)
https://github.com/python/cpython/commit/20ce62f00957d11f24f6449cd5c0ef5dd67174d4


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue41908] Make IDLE Start Menu entry more descriptive

[E. Paine]

E. Paine  added the comment:

Do we need to include the bitness (IDLE doesn't care)? On Windows, it will also 
be included in the Python start-menu folder, so maybe we should consider moving 
the bitness to the folder title (so the folder becomes "Python 3.8 64-bit")?


However, I also want to propose something a little more controversial: do we 
really need to have the word "IDLE" in the entry? The example that comes to 
mind immediately is Nautilus (a GNOME application), which in all graphical 
places (like the menu) is referred to simply as "Files". Internally and on the 
CLI it is known by Nautilus but, similar to "IDLE", seeing a menu entry for 
Nautilus wouldn't mean anything to a beginner.

On Windows, we could go for something, like
  Shell-Editor (3.9 64-bit)
Once in IDLE, we can use that name (and obviously internally), but from the 
outside I propose we avoid using it (this would also affect the right-click 
entry, for example).

I think this could cause more confusion than it avoids, but wanted to put the 
idea out there.

--
nosy: +epaine

___
Python tracker 

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

[issue41802] Missing documentation for 'PyDict_DelItem' behavior

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
nosy: +iritkatriel
nosy_count: 1.0 -> 2.0
pull_requests: +21512
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22291

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue41911] Language reference incorrectly says comparison expressions return boolean values

[Brett Cannon]

New submission from Brett Cannon :

https://docs.python.org/3/reference/expressions.html#comparisons claims that 
"Comparisons yield boolean values: True or False." But that's not necessarily 
true:

```python
>>> class Spam: 
...  def __eq__(self, _): return 42
... 
>>> Spam() == object()
42
```

That really only happens when an expressions is used in a boolean context like 
an `if` statements guard expression.

--
assignee: brett.cannon
components: Documentation
messages: 377817
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Language reference incorrectly says comparison expressions return 
boolean values
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue41910] Document that object.__eq__ implements `a is b`

[Brett Cannon]

Change by Brett Cannon :


--
assignee: docs@python -> brett.cannon

___
Python tracker 

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

[issue41910] Document that object.__eq__ implements `a is b`

[Brett Cannon]

New submission from Brett Cannon :

If you look at the data model `for object.__eq__` 
(https://docs.python.org/3.8/reference/datamodel.html#object.__eq__) you will 
see that it doesn't mention any actual implementation (unlike for __ne__). But 
https://github.com/python/cpython/blob/v3.8.3/Objects/typeobject.c#L3834-L3880 
shows that object.__eq__ actually does have an implementation of `a is 
b`/`id(a) == id(b)`.

--
assignee: docs@python
components: Documentation
messages: 377816
nosy: brett.cannon, docs@python
priority: low
severity: normal
status: open
title: Document that object.__eq__ implements `a is b`
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue40455] GCC 10 compiler warnings

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

[issue41902] Micro optimization for range.index if step is 1

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

[issue41901] Added some explaining to pickle errors.

[Marco Sulla]

Marco Sulla  added the comment:

I closed it for this reason:

https://github.com/python/cpython/pull/22438#issuecomment-702794261

--
stage:  -> 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

[issue41906] logging.config.dictConfig does not work with callable filters

[raybb]

raybb  added the comment:

Thank you for the clarification.

I think I was most confused by the docs on this page (which I should have 
included in my initial post): https://docs.python.org/3/howto/logging.html

It says: 

"In Python 3.2, a new means of configuring logging has been introduced, using 
dictionaries to hold configuration information. This provides a superset of the 
functionality of the config-file-based approach outlined above, and is the 
recommended configuration method for new applications and deployments."


Since it is the recommended configuration method I had naively assumed that it 
would be compatible with the feature of just using callables instead which was 
mentioned here https://docs.python.org/3/library/logging.html. 


I think it would be a nice enhancement long term to be able too support 
callables in dictconfigs.

In the short term do you think it is reasonable to update the first page 
mentioned in this comment to clarify that even though dictConfig is recommended 
it is not a feature parity with the object oriented api?

It would also be nice to clarify this on the second page to say that callables 
don't work if using dictConfig.


I understand it does say a factory is required on the page you linked. I think 
anyone who reads the docs as well as they should will find it. But I think 
adding information about this too other parts of the docs will make it much 
easier for newer folks to catch the difference early on.


Thanks for your work on the logging parts of the api in python. I've read many 
of your docs and they are very helpful.

--

___
Python tracker 

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

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think that the backport to 3.8 may have some unintended consequences in the 
last patch release as venv created with 3.8 now exhibit the pip regression 
(https://github.com/pypa/pip/issues/8695.).

Steve, would you be ok if we bump all branches (master, 3.9 and 3.8) to 20.2.3?

--
nosy: +pablogsal

___
Python tracker 

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

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[László Kiss Kollár]

László Kiss Kollár  added the comment:

pip 20.2.1 contains a regression which breaks `--system-site-package` 
integration: https://github.com/pypa/pip/issues/8695. It would be nice to 
include the latest patch version (20.2.3 at the moment) which fixes this and a 
few other issues.

--
nosy: +lkollar

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

[Joshua Bronson]

Change by Joshua Bronson :


--
nosy: +jab

___
Python tracker 

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

[issue41894] UnicodeDecodeError during load failure in non-UTF-8 locale

[Tal Einat]

Change by Tal Einat :


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

___
Python tracker 

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

[issue41907] Regression in IntFlag behaviour in f-string

[Ethan Furman]

Ethan Furman  added the comment:

Thank you for the bug report.

Another solution would be to subclass IntFlag and specify the `__format__` 
method:


from enum import IntFlag as _IntFlag
class IntFlag(_IntFlag):
def __format__(self, spec):
return format(self.value, spec)

--
assignee:  -> ethan.furman
stage:  -> needs patch
versions: +Python 3.10, Python 3.9

___
Python tracker 

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

[issue41909] Segfault on __getattr__ infinite recursion on certain attribute accesses

[Florian Bruhin]

Change by Florian Bruhin :


--
nosy: +The Compiler

___
Python tracker 

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

[issue41692] Deprecate immortal interned strings: PyUnicode_InternImmortal()

[STINNER Victor]

STINNER Victor  added the comment:

The function is now deprecated. Thanks for the review INADA-san, I close the 
issue. Let's meet in Python 3.12 to remove it ;-)

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

[issue41692] Deprecate immortal interned strings: PyUnicode_InternImmortal()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 583ee5a5b1971a18ebeb877948ce6264da0cc8aa by Victor Stinner in 
branch 'master':
bpo-41692: Deprecate PyUnicode_InternImmortal() (GH-22486)
https://github.com/python/cpython/commit/583ee5a5b1971a18ebeb877948ce6264da0cc8aa


--

___
Python tracker 

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

[issue40643] Improve doc-strings for datetime.strftime & strptime

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +21510
pull_request: https://github.com/python/cpython/pull/22477

___
Python tracker 

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

[issue41909] Segfault on __getattr__ infinite recursion on certain attribute accesses

[Ran Benita]

Change by Ran Benita :


--
type:  -> crash

___
Python tracker 

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

[issue41909] Segfault on __getattr__ infinite recursion on certain attribute accesses

[Ran Benita]

New submission from Ran Benita :

The following program crashes with a segfault:

class Segfault:
def __getattr__(self, name):
self.unknown_attribute

instance = Segfault()
issubclass(instance, int)  # int doesn't matter

Tested with Python 3.7, 3.8, 3.9rc2, and master in debug mode (commit 
497126f7ea955ee005e78f2cdd61f175d4fcdbb2).

The program is odd, but this affects pytest (see 
https://github.com/pytest-dev/pytest/issues/2330).
The class is buggy user code, pytest does the issubclass check.
In pytest there are other code paths which trigger it besides issubclass, but 
that's the one I am able to quickly reproduce standalone.

Here is the backtrace with python master:

ran@ran:~/src/cpython$ gdb --args ./python segfault.py
Reading symbols from ./python...
(gdb) r
Starting program: /home/ran/src/cpython/python segfault.py

Program received signal SIGSEGV, Segmentation fault.
0x556bc55e in PyGILState_Check () at Python/pystate.c:1353
1353if (!PyThread_tss_is_created(>autoTSSkey)) {


(gdb) bt 29
#0  0x556bc55e in PyGILState_Check () at Python/pystate.c:1353
#1  0x555fc117 in _PyMem_DebugCheckGIL (func=0x5581b330 
<__func__.10> "_PyMem_DebugMalloc") at Objects/obmalloc.c:2329
#2  _PyMem_DebugMalloc (ctx=0x5593b140 <_PyMem_Debug+96>, nbytes=185) at 
Objects/obmalloc.c:2329
#3  0x555fcee8 in PyObject_Malloc (size=) at 
Objects/obmalloc.c:685
#4  0x5562d6f3 in PyUnicode_New (size=136, maxchar=) at 
Objects/unicodeobject.c:1455
#5  0x556556e7 in _PyUnicodeWriter_PrepareInternal 
(writer=writer@entry=0x7f7ff0c0, length=length@entry=1, maxchar=, maxchar@entry=127)
at Objects/unicodeobject.c:14004
#6  0x55658439 in _PyUnicodeWriter_WriteASCIIString 
(writer=writer@entry=0x7f7ff0c0, ascii=ascii@entry=0x558196c8 "'%.50s' 
object has no attribute '%U'", 
len=1) at Objects/unicodeobject.c:14174
#7  0x5565a18d in PyUnicode_FromFormatV 
(format=format@entry=0x558196c8 "'%.50s' object has no attribute '%U'", 
vargs=vargs@entry=0x7f7ff170)
at Objects/unicodeobject.c:3114
#8  0x5569646b in _PyErr_FormatV (tstate=0x559aa300, 
exception=, 
format=format@entry=0x558196c8 "'%.50s' object has no attribute '%U'", 
vargs=vargs@entry=0x7f7ff170) at Python/errors.c:1029
#9  0x55696ff3 in PyErr_Format (exception=, 
format=format@entry=0x558196c8 "'%.50s' object has no attribute '%U'") at 
Python/errors.c:1071
#10 0x555fa4a5 in _PyObject_GenericGetAttrWithDict 
(obj=obj@entry=, 
name=name@entry='unknown_attribute', dict=, 
dict@entry=0x0, suppress=suppress@entry=0) at Objects/object.c:1268
#11 0x555fa96f in PyObject_GenericGetAttr (obj=obj@entry=, name=name@entry='unknown_attribute') at 
Objects/object.c:1281
#12 0x5561c3f8 in slot_tp_getattr_hook (self=, name='unknown_attribute') at Objects/typeobject.c:6805
#13 0x555f68c2 in PyObject_GetAttr (v=v@entry=, name=) at Objects/object.c:891
#14 0x5567c254 in _PyEval_EvalFrameDefault (tstate=0x559aa300, 
f=Frame 0x771cc3b0, for file /home/ran/src/cpython/segfault.py, line 3, 
in __getattr__ (self=, 
name='unknown_attribute'), 
throwflag=) at Python/ceval.c:3036
#15 0x555b9d1d in _PyEval_EvalFrame (throwflag=0, 
f=Frame 0x771cc3b0, for file /home/ran/src/cpython/segfault.py, line 3, 
in __getattr__ (self=, 
name='unknown_attribute'), 
tstate=0x559aa300) at ./Include/internal/pycore_ceval.h:40
#16 function_code_fastcall (tstate=0x559aa300, co=, 
args=0x7f7ff590, nargs=2, globals=) at Objects/call.c:329
#17 0x555ba67b in _PyFunction_Vectorcall (func=, 
stack=, nargsf=, kwnames=) at 
Objects/call.c:366
#18 0x5576c2d4 in _PyObject_VectorcallTstate (tstate=0x559aa300, 
callable=, args=0x7f7ff580, nargsf=2, 
kwnames=0x0)
at ./Include/cpython/abstract.h:114
#19 0x5576cb87 in method_vectorcall (method=, 
args=0x7f7ff588, nargsf=, kwnames=0x0) at 
Objects/classobject.c:53
#20 0x556109ac in _PyObject_VectorcallTstate (kwnames=0x0, 
nargsf=9223372036854775809, args=0x7f7ff588, callable=, 
tstate=0x559aa300) at ./Include/cpython/abstract.h:114
#21 PyObject_CallOneArg (arg='unknown_attribute', func=) at ./Include/cpython/abstract.h:184
#22 call_attribute (self=self@entry=, 
attr=, attr@entry=, 
name=name@entry='unknown_attribute') at Objects/typeobject.c:6771
#23 0x5561c44a in slot_tp_getattr_hook (self=, name='unknown_attribute') at Objects/typeobject.c:6813
#24 0x555f68c2 in PyObject_GetAttr (v=v@entry=, name=) at Objects/object.c:891
#25 0x5567c254 in _PyEval_EvalFrameDefault (tstate=0x559aa300, 
f=Frame 0x771cc200, for file /home/ran/src/cpython/segfault.py, line 3, 
in __getattr__ (self=, 
name='unknown_attribute'), 
throwflag=) at Python/ceval.c:3036
#26 0x555b9d1d in _PyEval_EvalFrame (throwflag=0, 
f=Frame 0x771cc200, for 

[issue41902] Micro optimization for range.index if step is 1

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I would need to carefully look at the PRs to estimate the maintenance cost, but 
it seems to me initially that all these operations happen very rarely in 
regular code and probably will have no impact on macro benchmarks. In general, 
I dislike branches because they quickly can become the source of slight 
different semantics.

--

___
Python tracker 

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

[issue41908] Make IDLE Start Menu entry more descriptive

[Terry J. Reedy]

New submission from Terry J. Reedy :

A current python-list thread "Problem" is about the difficulties beginners have 
getting started immediately after installation.  I believe it started with 
another beginner asking about getting the modify/repair note.  One other thing 
that came up is that "IDLE", by itself, means nothing to someone who does not 
know what it is.  So one suggestion was to replace the current
  IDLE (Python 3.9 64 bit)
with something more descriptive.

The current longest entry is
  Python 3.9 Module Docs (64-bit)
which appears to be about as long as possible that fits in the space allowed 
without being truncated with ... (like "Microsoft Visual Studio 2010 Express"). 
 (The font is proportional, I believe, so a char count does not give an exact 
measure.)

I propose a new entry for IDLE that is slightly shorter that the apparent 
maximum.
  IDLE Shell-Editor (3.9 64-bit)

The menu entry is also the initial filename for a desktop shortcut.  For me, 
after editing is complete, it displays as either


IDLE
Shell-Edit...
(inactive, 2 lines only) or

  IDLE
Shell-Editor
(3.9 64-bit)
(active, full 3 lines)

I checked that the future '3.10' will not cause a problem.
The popup shortcut comment
"Launches IDLE, the interactive environment for Python 3.9."
nicely complements the proposed title, tying 'IDLE' to 'Python'.
For a taskbar icon, the menu entry is the popup description.
---

macOS: The equivalent of 'Python 3.9' on the start menu is the 'Python 3.9' 
folder in Finder.  The equivalent of the 'IDLE (Python 3.9 64 bit)' entry is 
the Python app icon labelled simply 'IDLE' for the IDLE.app startup file. Ned, 
what would you think of the longer name "IDLE Shell-Editor.app'?  (And maybe 
add 3.9 somewhere -- I have 3.8 and 3.9 loaded and on the (taskbar) I only know 
which is which by position.)

--
assignee: terry.reedy
components: IDLE, Installation, Windows
messages: 377805
nosy: ned.deily, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Make IDLE Start Menu entry more descriptive
type: enhancement
versions: Python 3.10

___
Python tracker 

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

[issue41907] Regression in IntFlag behaviour in f-string

[Dominic Davis-Foster]

Dominic Davis-Foster  added the comment:

I believe the regression is due to GH-14545 which "fixed" bpo-37479. The news 
entry states:

"When `Enum.__str__` is overridden in a derived class, the override will be 
used by `Enum.__format__` regardless of whether mixin classes are present."

.

The change is in the __format__ method of Enum. It now checks if 
type(self).__str__ != Enum.__str__ and if True calls str(self). Because Flag 
defines its own __str__ method, the expression evaluates to True. I do not 
think this is the indented behaviour.

In 3.8.5 str(self) was only called if _member_type_ is object.

--
nosy: +dom1310df

___
Python tracker 

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

[issue33533] Provide an async-generator version of as_completed

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

Hi, thanks for providing a PR. One thing I noticed is that the implementation 
in the PR yields results of the futures from the generator. This issue proposes 
a generator that instead yields the futures passed to as_completed. This is 
needed not just for consistency with concurrent.futures.as_completed, but also 
to allow associating results with the requests that produced them, which is an 
important use case for as_completed.

An example of how this is useful is the snippet at 
https://docs.python.org/3/library/concurrent.futures.html#threadpoolexecutor-example
 which you cannot implement with an as_completed that doesn't yield the 
original futures. The StackOverflow question at [1] inquires about that issue, 
and would be easily resolved by yielding the futures as 
concurrent.futures.as_completed does.

As far as I can tell, the needed change is simple: just yield `f` instead of 
`f.result()` from `_wait_for_one` when invoked from __anext__. (It must still 
return f.result() when called from __next__ for backward compatibility.)

[1] 
https://stackoverflow.com/questions/50028465/python-get-reference-to-original-task-after-ordering-tasks-by-completion

--

___
Python tracker 

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

[issue41905] add update_abstractmethods function to update an ABC's abstract methods

[Ben Avrahami]

Ben Avrahami  added the comment:

Good points all, that I will try to address one by one:

Firstly, this function is by no means mandatory for "post-creation mixins". 
Such tools can still be used without calling it (and remain ABC unaware), with 
absolutely no change in functionality. Indeed, the function itself can be used 
as a decorator for just such cases, where a tool is ABC unaware (either from 
deciding that ABC aren't a use case for them, or from simply not considering 
that possibility), but the user wants to also subclass an ABC. The problem is 
that, right now, post-creation tools simply can't be ABC aware.

The thought that few tools are ABC aware is not, I think, a good reason to 
neglect tools that would like to be. Just as dispatch and type-routing tools 
might not be ABC aware to use `abc.get_cache_token()`, but it is still added 
for tools that want to be ABC aware and sidestep this confusing behavior.

As for not occurring in practice: a simple github search reveals many instances 
of comparison operators being abstract, and while likely few of them likely use 
dataclasses, that is a possibility that I believe should be addressed (of 
course, we could decide that this is desired behavior, and scrap this whole 
issue).

Finally, total_ordering: I originally added it to the issue because it was the 
other decorator mixin in the standard library, after I rand into this behavior 
using dataclasses. If total_ordering proves to be a barrier, we can remove it 
from the PR (and perhaps re-introduce it later if that is deemed necessary). I 
will only remark that I find total_ordering used in many hand-rolled classes 
where users would sacrifice some performance for cleaner code and an assertion 
that total order is enforced.

Sorry for the scroll and thanks for the scrutiny :-)

--

___
Python tracker 

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

[issue41907] Regression in IntFlag behaviour in f-string

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue29127] Incorrect reference names in asyncio.subprocess documentation

[Kyle Stanley]

Kyle Stanley  added the comment:

I can confirm that both on the latest version of the docs (for 3.8) and for the 
version mentioned in the issue (3.6), the issue mentioned with 
asyncio.subprocess.PIPE is no longer present. (It was likely fixed in the 
asyncio documentation overhaul that happened within the last couple of years).

As a result, I'll proceed with closing this issue. Thanks for checking, Carl.

--
nosy: +aeros
resolution:  -> fixed
stage:  -> 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

[issue41906] logging.config.dictConfig does not work with callable filters

[Vinay Sajip]

Vinay Sajip  added the comment:

The value of the '()' key should be a factory - something that returns a filter 
(either something that has a filter method or a callable). That returned 
callable, or the filter method, will be called with a LogRecord and its return 
value used to determine whether the event should be processed. An example of 
using factories is here:

https://docs.python.org/3/library/logging.config.html#user-defined-objects

In your first example, you're passing the filter where you need to pass the 
factory. If you change it to e.g. return a lambda that does the filtering, it 
should work as expected.

At the moment you can't directly pass a filter callable in the config 
dictionary - only a factory that returns a filter. I'll look at this as a 
possible enhancement.

--
type: behavior -> enhancement
versions: +Python 3.10

___
Python tracker 

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

[issue17490] Improve ast.literal_eval test suite coverage

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> rejected
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

[issue17490] Improve ast.literal_eval test suite coverage

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -21504

___
Python tracker 

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

[issue41902] Micro optimization for range.index if step is 1

[Dong-hee Na]

Dong-hee Na  added the comment:

@vstinner @pablo @mark

On my local machine (without cpu isolation),
PR 22480 does not affect performance issues.

import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench long divide",
  stmt="""
for i in range(1, 256):
a = 1 // i
""")

but I think that my benchmark does not cover the worst case.

I need to set up the CPU isolation environment but my resource is limited.
(I need a Linux machine with sufficient permission but not)


PR 22479 and PR 22480 has two sides of assumption.

PR 22479: PyNumber_FloorDivide is a heavy operation if the user thinks that 
this is an unnecessary operation it should be avoided.
(In this case divide by one)
PR 22480: PyNumber_FloorDivide should process handle unnecessary operations 
smartly.


In conclusion, I'd like to +1 on mark's decision.
- PR 22480: even though the divisor value is one, if the dividend is not 
qualified from PyLong_CheckExact it will not get an optimization path.
So it will not cover all the 'divide by one' case and it can cause performance 
issues.
- PR 22480: Always optimized if the user does not set a specific step value and 
this will be same effect on PR 22492.

--

___
Python tracker 

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