[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

Re: How to handle a dictionary value that is a list

[Python]

On Fri, Oct 02, 2020 at 09:25:58PM +0100, Shaozhong SHI wrote:
> Hi, All,
> 
> I was trying to handle the value of  "personRoles" in a part of json
> dictionary.
> 
> Can anyone tell me various ways to handle this?

I'm not sure if I understand what you're asking, but if I do, then...
you handle it just as you would handle any other list.  The only
difference is that instead of something like "my_list", the name of
the list is d['regulatedActivities']['contacts']['personRoles'].

  https://docs.python.org/3/tutorial/datastructures.html
 
Then:

> f = d['regulatedActivities']['contacts']['personRoles']

After this executes, you have an alias for that list called "f" that
refers to the same list object instance...  So you can do all the
things you can do to a list, and refer to it either as f or as
d['regulatedActivities']['contacts']['personRoles'] when you do so.
It is an alias, not a copy, so if you change one, you change the
other.

HTH.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Error 0xc000007b on opening python

[Eryk Sun]

On 10/2/20, Nipur Gupta  wrote:
> I've downloaded python 3.6.0 64 bits but whenever I try to open idle, it

Python 3.8 supports Windows 8.1, so, unless otherwise required, you
should install the latest release of 64-bit Python 3.8, which is
currently 3.8.6:

https://www.python.org/ftp/python/3.8.6/python-3.8.6-amd64.exe

The 3.6 branch is no longer maintained. If 3.6 is required, you should
install 3.6.8, the last build that was released for Windows about two
years ago:

https://www.python.org/ftp/python/3.6.8/python-3.6.8-amd64.exe

> doesn't open and displays error 0xc07b.

STATUS_INVALID_IMAGE_FORMAT (0xC07B or -1073741701) is an NTSTATUS
code from the native NT system beneath the Windows (Win32) API.
Low-level status codes are observed for critical failures such as
failing to initialize a process or an unhandled OS exception.

STATUS_INVALID_IMAGE_FORMAT is from the system loader during process
initialization. The executable file or a dependent DLL could be
corrupt. Or the loader might be trying to load a 32-bit DLL in a
64-bit process, or vice versa.

If the error persists after removing 3.6.0 and installing a newer
release, then I would resolve the problem by running python.exe under
a debugger with "loader snaps" enabled, which will show detailed debug
messages from the loader.
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: List of All Error Menssages

[Luis Gustavo Araujo]

Hi Kyle,

Thanks!

Att,


Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Em sex., 2 de out. de 2020 às 18:03, Kyle Stanley 
escreveu:

> Hi Luis,
>
> There is not a maintained list of every possible combination of exception
> type and message because they're continuously being added within the Python
> standard library, and exception messages are considered an implementation
> detail that are subject to change. While there are many that have remained
> the same for many years and likely will continue to, we do periodically
> adjust some to add additional information, make formatting fixes, and/or
> improve grammar. Documenting exception messages formally would essentially
> remove them from being implementation details (meaning that they can't as
> easily be adjusted); not to mention the long term cost of continuously
> updating that list each time a new exception message is written somewhere
> within the standard library. It would not be very sustainable, even more so
> if you consider that CPython development is mostly volunteer-driven efforts.
>
> Regards,
> Kyle Stanley
>
> On Thu, Oct 1, 2020 at 3:18 PM Luis Gustavo Araujo <
> luisaraujo.i...@gmail.com> wrote:
>
>>   Hi,
>> Is it possible to get the list of all error messages that display in
>> Python? I want the full message -> type error: additional message.
>>
>> Examples:
>> NameError: name 'x' is not defined
>> IndentationError: unindent does not match any outer indentation level
>>
>> In this webpage (ttps://docs.python.org/3/library/exceptions.html) I only
>> can check the type error.
>>
>> []s
>>
>>
>> Em qui., 1 de out. de 2020 às 15:59, Luis Gustavo Araujo <
>> luisaraujo.i...@gmail.com> escreveu:
>>
>> > Hi,
>> > Is it possible to get the list of all error messages that display in
>> > Python? I want the full message -> type error: additional message.
>> >
>> > Examples:
>> > NameError: name 'x' is not defined
>> > IndentationError: unindent does not match any outer indentation level
>> >
>> > In this webpage (ttps://docs.python.org/3/library/exceptions.html) I
>> only
>> > can check the type error.
>> >
>> > []s
>> >
>> >
>> > --
>> >
>> > [image: Prefeitura Municipal de Amélia Rodrigues]
>> > 
>> >
>> > LUIS GUSTAVO ARAUJO
>> > *Amélia Rodrigues Prefecture - Brazil  (*
>> >
>> > *Teacher of Computer Science) UNIFACS - Laureate International
>> > Universities (Professor Assistant I)*
>> >
>> > Degree in Computer Science (IFBA) - 2015
>> > Master Degrees in Computer Applied (UEFS) - 2018
>> > PhD  Student in Computer Science (UFBA)
>> > *http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
>> > *
>> >
>> > [image: Twitter]   [image:
>> Facebook]
>> >  [image: Github]
>> > 
>> >
>> >
>> >
>> >
>> > <
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> Livre
>> > de vírus. www.avast.com
>> > <
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>> >.
>> > <#m_-2814426795322638799_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> >
>>
>>
>> --
>>
>> [image: Prefeitura Municipal de Amélia Rodrigues]
>> 
>>
>> LUIS GUSTAVO ARAUJO
>> *Amélia Rodrigues Prefecture - Brazil  (*
>>
>> *Teacher of Computer Science) UNIFACS - Laureate International
>> Universities
>> (Professor Assistant I)*
>>
>> Degree in Computer Science (IFBA) - 2015
>> Master Degrees in Computer Applied (UEFS) - 2018
>> PhD  Student in Computer Science (UFBA)
>> *http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
>> *
>>
>> [image: Twitter]   [image: Facebook]
>>  [image: Github]
>> 
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>

-- 

[image: Prefeitura Municipal de Amélia Rodrigues]


LUIS GUSTAVO ARAUJO
*Amélia Rodrigues Prefecture - Brazil  (*

*Teacher of Computer Science) UNIFACS - Laureate International Universities
(Professor Assistant I)*

Degree in Computer Science (IFBA) - 2015
Master Degrees in Computer Applied (UEFS) - 2018
PhD  Student in Computer Science (UFBA)
*http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
*

[image: Twitter]   [image: Facebook]
 [image: Github]

[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

Re: List of All Error Menssages

[Kyle Stanley]

Hi Luis,

There is not a maintained list of every possible combination of exception
type and message because they're continuously being added within the Python
standard library, and exception messages are considered an implementation
detail that are subject to change. While there are many that have remained
the same for many years and likely will continue to, we do periodically
adjust some to add additional information, make formatting fixes, and/or
improve grammar. Documenting exception messages formally would essentially
remove them from being implementation details (meaning that they can't as
easily be adjusted); not to mention the long term cost of continuously
updating that list each time a new exception message is written somewhere
within the standard library. It would not be very sustainable, even more so
if you consider that CPython development is mostly volunteer-driven efforts.

Regards,
Kyle Stanley

On Thu, Oct 1, 2020 at 3:18 PM Luis Gustavo Araujo <
luisaraujo.i...@gmail.com> wrote:

>   Hi,
> Is it possible to get the list of all error messages that display in
> Python? I want the full message -> type error: additional message.
>
> Examples:
> NameError: name 'x' is not defined
> IndentationError: unindent does not match any outer indentation level
>
> In this webpage (ttps://docs.python.org/3/library/exceptions.html) I only
> can check the type error.
>
> []s
>
>
> Em qui., 1 de out. de 2020 às 15:59, Luis Gustavo Araujo <
> luisaraujo.i...@gmail.com> escreveu:
>
> > Hi,
> > Is it possible to get the list of all error messages that display in
> > Python? I want the full message -> type error: additional message.
> >
> > Examples:
> > NameError: name 'x' is not defined
> > IndentationError: unindent does not match any outer indentation level
> >
> > In this webpage (ttps://docs.python.org/3/library/exceptions.html) I
> only
> > can check the type error.
> >
> > []s
> >
> >
> > --
> >
> > [image: Prefeitura Municipal de Amélia Rodrigues]
> > 
> >
> > LUIS GUSTAVO ARAUJO
> > *Amélia Rodrigues Prefecture - Brazil  (*
> >
> > *Teacher of Computer Science) UNIFACS - Laureate International
> > Universities (Professor Assistant I)*
> >
> > Degree in Computer Science (IFBA) - 2015
> > Master Degrees in Computer Applied (UEFS) - 2018
> > PhD  Student in Computer Science (UFBA)
> > *http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
> > *
> >
> > [image: Twitter]   [image: Facebook]
> >  [image: Github]
> > 
> >
> >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Livre
> > de vírus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >.
> > <#m_-2814426795322638799_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
>
>
> --
>
> [image: Prefeitura Municipal de Amélia Rodrigues]
> 
>
> LUIS GUSTAVO ARAUJO
> *Amélia Rodrigues Prefecture - Brazil  (*
>
> *Teacher of Computer Science) UNIFACS - Laureate International Universities
> (Professor Assistant I)*
>
> Degree in Computer Science (IFBA) - 2015
> Master Degrees in Computer Applied (UEFS) - 2018
> PhD  Student in Computer Science (UFBA)
> *http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
> *
>
> [image: Twitter]   [image: Facebook]
>  [image: Github]
> 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[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) *** 

How to handle a dictionary value that is a list

[Shaozhong SHI]

Hi, All,

I was trying to handle the value of  "personRoles" in a part of json
dictionary.

Can anyone tell me various ways to handle this?

Regards,

Shao

"regulatedActivities": [
{
  "name": "Accommodation for persons who require nursing or personal
care",
  "code": "RA2",
  "contacts": [
{
  "personTitle": "Mr",
  "personGivenName": "Steven",
  "personFamilyName": "Great",
  "personRoles": [
"Registered Manager"
  ]

e,f = [],[]
for result in d['regulatedActivities']:
e.append(result['name'])
    for s in result['contacts']['personRoles']:
    t = (list)
  print s ###f.append(s)
f = d['regulatedActivities']['contacts']['personRoles']
df1 = pd.DataFrame([e,f]).T
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Problem

[Mirko via Python-list]

Am 02.10.2020 um 11:58 schrieb Terry Reedy:
> On 10/1/2020 4:09 PM, Mirko via Python-list wrote:
> 
>> Renaming "IDLE" to "Python IDE" (or similar) might also.
> "IDLE" intentionally echoes 'Idle', as in Eric Idle of Monty
> Python.  It stands for "Integrated Development and Learning
> Environment".  It is *a* Python IDE aimed especially at beginners
> (the 'Learning' part).  (I should probably revised the doc a bit.)
> 
> Changing a name in use around the world, in books and web sites and
> discussion posts and a Stackoverflow tag ('python-idle') is a bad
> idea. And, as Chris said, implying that it is *the* Python IDE is
> not a good idea either.
> 
> I think changing the start menu entry
> "IDLE (Python 3.9 64 bit)"
> to something more descriptive, as suggested by Mirko, *is* a good idea.
> 
> The current longest entry under "Python 3.9" is
> "Python 3.9 Module Docs (64-bit)"
> So
> "IDLE Shell/Editor (3.9 64-bit)"
> would fit.  I opened a bpo issue with more discussion.
> https://bugs.python.org/issue41908
> Bpo users with an opinion should express it there.
> 
> Terry Jan Reedy
> 

(Sorry for the mail from the other wrong account again, need to
change that)

Thanks!

Sorry, I have been a bit unclear in my second post. I never meant to
rename IDLE itself. Only the entries in the Startmenu, the possible
desktop icons and such.

If I had a say in all this, I would do:

- Rename the MSI as suggested by Eryk Sun.

- Add a folder named "Python.org " (or similar) to the
desktop with shortcuts to Python, IDLE and the CHM.

- Add a checkbox (default enabled) like "Start the IDLE Python
Editor/Shell" at the end of the installation procedure.

- Add a button like "Start the IDLE Python Editor/Shell" to the
Repair/Modify/Remove Dialog.


For all I know, the points 2 and 3 are very common with installation
procedures on Windows (and therefore likely expected by the users).

And no, this will not solve all problems. There will always be some
people who just don't get it. But I would be very surprised, if that
doesn't cut down the number of these beginner troubles by one or two
orders of magnitude.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem

[Hexamorph]

Am 02.10.2020 um 11:58 schrieb Terry Reedy:
> On 10/1/2020 4:09 PM, Mirko via Python-list wrote:
>
>> Renaming "IDLE" to "Python IDE" (or similar) might also.
> "IDLE" intentionally echoes 'Idle', as in Eric Idle of Monty
> Python.  It stands for "Integrated Development and Learning
> Environment".  It is *a* Python IDE aimed especially at beginners
> (the 'Learning' part).  (I should probably revised the doc a bit.)
>
> Changing a name in use around the world, in books and web sites and
> discussion posts and a Stackoverflow tag ('python-idle') is a bad
> idea. And, as Chris said, implying that it is *the* Python IDE is
> not a good idea either.
>
> I think changing the start menu entry
> "IDLE (Python 3.9 64 bit)"
> to something more descriptive, as suggested by Mirko, *is* a good idea.
>
> The current longest entry under "Python 3.9" is
> "Python 3.9 Module Docs (64-bit)"
> So
> "IDLE Shell/Editor (3.9 64-bit)"
> would fit.  I opened a bpo issue with more discussion.
> https://bugs.python.org/issue41908
> Bpo users with an opinion should express it there.
>
> Terry Jan Reedy
>

Thanks!

Sorry, I have been a bit unclear in my second post. I never meant to
rename IDLE itself. Only the entries in the Startmenu, the possible
desktop icons and such.

If I had a say in all this, I would do:

- Rename the MSI as suggested by Eryk Sun.

- Add a folder named "Python.org " (or similar) to the
desktop with shortcuts to Python, IDLE and the CHM.

- Add a checkbox (default enabled) like "Start the IDLE Python
Editor/Shell" at the end of the installation procedure.

- Add a button like "Start the IDLE Python Editor/Shell" to the
Repair/Modify/Remove Dialog.


For all I know, the points 2 and 3 are very common with installation
procedures on Windows (and therefore likely expected by the users).

And no, this will not solve all problems. There will always be some
people who just don't get it. But I would be very surprised, if that
doesn't cut down the number of these beginner troubles by one or two
orders of magnitude.
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: List of All Error Menssages

[Dieter Maurer]

Luis Gustavo Araujo wrote at 2020-10-1 16:06 -0300:
>Is it possible to get the list of all error messages that display in
>Python? I want the full message -> type error: additional message.
>
>Examples:
>NameError: name 'x' is not defined
>IndentationError: unindent does not match any outer indentation level

Some systems indicates errors with an error code (often a number).
If they in addition do not include an error description, you
need a list mapping codes to description.

Python indicates errors via exceptions, documented in the Python
documentation (as far as used by Python; applications may define/derive
further exceptions). In addition, error reports are usually
made descriptive.
An example is `NameError: name 'x' is not defined`: it informs
you about a problem with the name `x`. In addition, you usually
get a traceback - which tells you where in the code the problem
was detected and the (function call) context that led to the problem.
This wealth of direct information removes the need to have
an error list.

In addition: the additional information (beside the exception type)
depends on the concrete situation: it is impossible to list
it beforehand.

>In this webpage (https://docs.python.org/3/library/exceptions.html) I only
>can check the type error.

`exceptions.html` describes Python's exception type hierarchy
(note: Python is object oriented and exceptions are organized into
a class hierarchy) and the exception types used by Python itself.

As you have found out, this describes only the exception types.
When an exception occurs, the type is usally enhanced by
a speaking error description, often including information
about your application entities involved in the exception,
e.g.
>>> open("abc")
Traceback (most recent call last):
  File "", line 1, in 
FileNotFoundError: [Errno 2] No such file or directory: 'abc'
```
It tells you clearly (and without the need for any list):
the problem was that a file could not have been opened
and that this file was named 'abc'.

Read error messages carefully -- they are usually "speaking".
Should you get a message you do not understand, ask here.
Otherwise, forget about lists of error messages.


-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Error 0xc000007b on opening python

[Mats Wichmann]

On 10/2/20 4:15 AM, Nipur Gupta wrote:
> I've downloaded python 3.6.0 64 bits but whenever I try to open idle, it
> doesn't open and displays error 0xc07b. I've tried everything from
> reinstalling to updating windows and visual c++ but it's still the same. I
> downloaded python earlier also it worked that time but opening after few
> days it showed this error, since then it's not working. I'm using windows
> 8.1 64 bit...Please help me in this regard
> 

Something like this, when a program worked, and then stops working,
usually indicates some kind of corruption - or some change you made. Did
you install another version of Python later?  Try using Microsoft's
tools for validating and repairing the system and the image that backs
it up.  Beyond the scope of this list to describe that, but you can look
for articles that describe that. For example:

https://support.microsoft.com/en-us/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system

Are you able to open Python itself, or does it show the same issue?

You should not be using Python 3.6.0.  If you have something that tells
you you must use 3.6.0 (which probably is not a real requirement
anyway), then at the very least select the latest installer in the 3.6
series, which has all the released bugfixes - I believe that is 3.6.8.
That's unlikely to have an effect on your problem, but don't continue
trying to use 3.6.0.
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Error 0xc000007b on opening python

[J.O. Aho]

On 02/10/2020 12:15, Nipur Gupta wrote:

I've downloaded python 3.6.0 64 bits but whenever I try to open idle, it
doesn't open and displays error 0xc07b. I've tried everything from
reinstalling to updating windows and visual c++ but it's still the same.


There seems to be quite many things that can cause this, you can try to 
reinstall driectx and .net frameworks, just see to install the right 
version, don't use a 32bit version of the packages on your 64bit 
microsoft windows installation.





I'm using windows 8.1 64 bit...Please help me in this regard


There is always the option of upgrading, go and visit 
https://distrowatch.com and install the flavor you thinks fit your best.



--

 //Aho
--
https://mail.python.org/mailman/listinfo/python-list

[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

Error 0xc000007b on opening python

[Nipur Gupta]

I've downloaded python 3.6.0 64 bits but whenever I try to open idle, it
doesn't open and displays error 0xc07b. I've tried everything from
reinstalling to updating windows and visual c++ but it's still the same. I
downloaded python earlier also it worked that time but opening after few
days it showed this error, since then it's not working. I'm using windows
8.1 64 bit...Please help me in this regard
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem

[Terry Reedy]

On 10/1/2020 4:09 PM, Mirko via Python-list wrote:


Renaming "IDLE" to "Python IDE" (or similar) might also.
"IDLE" intentionally echoes 'Idle', as in Eric Idle of Monty Python.  It 
stands for "Integrated Development and Learning Environment".  It is *a* 
Python IDE aimed especially at beginners (the 'Learning' part).  (I 
should probably revised the doc a bit.)


Changing a name in use around the world, in books and web sites and 
discussion posts and a Stackoverflow tag ('python-idle') is a bad idea. 
And, as Chris said, implying that it is *the* Python IDE is not a good 
idea either.


I think changing the start menu entry
"IDLE (Python 3.9 64 bit)"
to something more descriptive, as suggested by Mirko, *is* a good idea.

The current longest entry under "Python 3.9" is
"Python 3.9 Module Docs (64-bit)"
So
"IDLE Shell/Editor (3.9 64-bit)"
would fit.  I opened a bpo issue with more discussion.
https://bugs.python.org/issue41908
Bpo users with an opinion should express it there.

Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

ValueError: arrays must all be same length

[Shaozhong SHI]

Hello,

I got a json response from an API and tried to use pandas to put data into
a dataframe.

However, I kept getting this ValueError: arrays must all be same length.

Can anyone help?

The following is the json text.  Regards, Shao

{
  "locationId": "1-1004508435",
  "providerId": "1-101641521",
  "organisationType": "Location",
  "type": "Social Care Org",
  "name": "Meadow Rose Nursing Home",
  "brandId": "BD510",
  "brandName": "BRAND MACC Care",
  "onspdCcgCode": "E38000220",
  "onspdCcgName": "NHS Birmingham and Solihull CCG",
  "odsCode": "VM4G9",
  "uprn": "100070537642",
  "registrationStatus": "Registered",
  "registrationDate": "2013-12-16",
  "dormancy": "N",
  "numberOfBeds": 56,
  "postalAddressLine1": "96 The Roundabout",
  "postalAddressTownCity": "Birmingham",
  "postalAddressCounty": "West Midlands",
  "region": "West Midlands",
  "postalCode": "B31 2TX",
  "onspdLatitude": 52.399843,
  "onspdLongitude": -1.989241,
  "careHome": "Y",
  "inspectionDirectorate": "Adult social care",
  "mainPhoneNumber": "01214769808",
  "constituency": "Birmingham, Northfield",
  "localAuthority": "Birmingham",
  "lastInspection": {
"date": "2020-06-24"
  },
  "lastReport": {
"publicationDate": "2020-10-01"
  },
  "relationships": [

  ],
  "locationTypes": [

  ],
  "regulatedActivities": [
{
  "name": "Accommodation for persons who require nursing or personal care",
  "code": "RA2",
  "contacts": [
{
  "personTitle": "Mr",
  "personGivenName": "Steven",
  "personFamilyName": "Kazembe",
  "personRoles": [
"Registered Manager"
  ]
}
  ]
},
{
  "name": "Treatment of disease, disorder or injury",
  "code": "RA5",
  "contacts": [
{
  "personTitle": "Mr",
  "personGivenName": "Steven",
  "personFamilyName": "Kazembe",
  "personRoles": [
"Registered Manager"
  ]
}
  ]
}
  ],
  "gacServiceTypes": [
{
  "name": "Nursing homes",
  "description": "Care home service with nursing"
}
  ],
  "inspectionCategories": [
{
  "code": "S1",
  "primary": "true",
  "name": "Residential social care"
}
  ],
  "specialisms": [
{
  "name": "Caring for adults over 65 yrs"
},
{
  "name": "Caring for adults under 65 yrs"
},
{
  "name": "Dementia"
},
{
  "name": "Physical disabilities"
}
  ],
  "inspectionAreas": [

  ],
  "currentRatings": {
"overall": {
  "rating": "Requires improvement",
  "reportDate": "2020-10-01",
  "reportLinkId": "1157c975-c2f1-423e-a2b4-66901779e014",
  "useOfResources": {

  },
  "keyQuestionRatings": [
{
  "name": "Safe",
  "rating": "Requires improvement",
  "reportDate": "2020-10-01",
  "reportLinkId": "1157c975-c2f1-423e-a2b4-66901779e014"
},
{
  "name": "Well-led",
  "rating": "Requires improvement",
  "reportDate": "2020-10-01",
  "reportLinkId": "1157c975-c2f1-423e-a2b4-66901779e014"
},
{
  "name": "Caring",
  "rating": "Good",
  "reportDate": "2019-10-04",
  "reportLinkId": "63ff05ec-4d31-406e-83de-49a271cfdc43"
},
{
  "name": "Responsive",
  "rating": "Good",
  "reportDate": "2019-10-04",
  "reportLinkId": "63ff05ec-4d31-406e-83de-49a271cfdc43"
},
{
  "name": "Effective",
  "rating": "Requires improvement",
  "reportDate": "2019-10-04",
  "reportLinkId": "63ff05ec-4d31-406e-83de-49a271cfdc43"
}
  ]
},
"reportDate": "2020-10-01"
  },
  "historicRatings": [
{
  "reportLinkId": "63ff05ec-4d31-406e-83de-49a271cfdc43",
  "reportDate": "2019-10-04",
  "overall": {
"rating": "Requires improvement",
"keyQuestionRatings": [
  {
"name": "Safe",
"rating": "Requires improvement"
  },
  {
"name": "Well-led",
"rating": "Requires improvement"
  }
]
  }
},
{
  "reportLinkId": "4f20da40-89a4-4c45-a7f9-bfd52b48f286",
  "reportDate": "2017-09-08",
  "overall": {
"rating": "Good",
"keyQuestionRatings": [
  {
"name": "Safe",
"rating": "Good"
  },
  {
"name": "Well-led",
"rating": "Good"
  },
  {
"name": "Caring",
"rating": "Good"
  },
  {
"name": "Responsive",
"rating": "Good"
  },
  {
"name": "Effective",
"rating": "Requires improvement"
  }
]
  }
},
{
  "reportLinkId": "0cc4226b-401e-4f0f-ba35-062cbadffa8f",
  "reportDate": "2016-06-11",
  "overall": {
"rating": "Requires 

[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

Re: Python 3.8.5 Not Launching

[Eryk Sun]

On 10/2/20, Gertjan Klein  wrote:
> Eryk Sun wrote:
>
>> If .py files are associated with py.exe or python.exe, then running a
>> .py script either inherits or allocates a console and attaches to it.
>
> Is it possible to determine, from within Python, whether Python
> allocated or inherited the console?

If a console session isn't headless (i.e. it's not a pseudoconsole)
and has a window (i.e. not allocated with CREATE_NO_WINDOW), then the
effective owner of the window is initially the process that allocated
the console session, as long as it's still running and attached. For
example, with "python.exe" (not a launcher) executed from Explorer:

>>> hwnd = win32console.GetConsoleWindow()
>>> tid, pid = win32process.GetWindowThreadProcessId(hwnd)
>>> pid == os.getpid()
True

A problem is the case of a launcher such as "py.exe", or the
"python.exe" launcher used by venv virtual environments. A venv
launcher can be detected by comparing sys.executable with
sys._base_executable. For example, with a venv launcher executed from
Explorer:

>>> hwnd = win32console.GetConsoleWindow()
>>> tid, pid = win32process.GetWindowThreadProcessId(hwnd)

The current process doesn't own the console, but the parent does:

>>> pid == os.getpid()
False
>>> pid == os.getppid()
True

Check whether the parent is a venv launcher:

>>> print(sys.executable)
C:\Temp\env\test38\Scripts\python.exe
>>> print(sys._base_executable)
C:\Program Files\Python38\python.exe

Double check that the parent is the venv launcher:

>>> access = win32con.PROCESS_QUERY_LIMITED_INFORMATION
>>> hproc = win32api.OpenProcess(access, False, pid)
>>> executable = win32process.GetModuleFileNameEx(hproc, None)
>>> os.path.samefile(executable, sys.executable)
True
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Python 3.8.5 Not Launching

[Chris Angelico]

On Fri, Oct 2, 2020 at 7:51 PM Gertjan Klein  wrote:
>
> Eryk Sun wrote:
>
> > If .py files are associated with py.exe or python.exe, then running a
> > .py script either inherits or allocates a console and attaches to it.
>
> Is it possible to determine, from within Python, whether Python
> allocated or inherited the console? This could be useful to know in a
> (global) error trap: to be able to see a traceback, the console must
> remain open, which won't happen if Python allocated the console itself.
>

It might be possible, but then there'd have to be lots of magic and
the result would be a different set of complaints ("sometimes I get a
black window, other times it just disappears"). Instead of trying to
detect and such, maybe there needs to be a standard recommendation for
an atexit or something - advise people to "stick this line at the top
of your program so the black window stays around". No magic, and
completely consistent.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Python 3.8.5 Not Launching

[Gertjan Klein]

Eryk Sun wrote:


If .py files are associated with py.exe or python.exe, then running a
.py script either inherits or allocates a console and attaches to it.


Is it possible to determine, from within Python, whether Python 
allocated or inherited the console? This could be useful to know in a 
(global) error trap: to be able to see a traceback, the console must 
remain open, which won't happen if Python allocated the console itself.


Regards,
Gertjan.
--
https://mail.python.org/mailman/listinfo/python-list

[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