[issue45579] [list.append(i) for i in list] causes high resources usage

2021-10-23 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue45588] cached_method similar to cached_property to cache with classes

2021-10-23 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

See also:  
https://docs.python.org/3/faq/programming.html#how-do-i-cache-method-calls

--

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



[issue45588] cached_method similar to cached_property to cache with classes

2021-10-23 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

AFAICT, the only capability added by the PR is keeping a weak reference to the 
instance.

This doesn't improve the hit rate and will make the hit rate worse for 
instances that define __hash__.  In the PR's example, two vector instances with 
equal coordinates would not be recognized as being equivalent.  Note, 
dataclasses make it trivially easy to add custom __eq__ and __hash__ support.

Users also lose the ability to limit maximum memory utilization.  Managing the 
combined size of many caches, one per instance, is much more difficult that 
setting an automatic maxsize limit on a single lru_cache.

Users further lose the ability to clear the entire cache all at once.  This can 
be important in testing.

AFAICT, the only benefit is that short-lived instances will be freed earlier 
than if they waited to age out of an lru_cache.  This would only ever matter if 
the instances were large, short-lived, and would never have other equivalent 
instances that could create a cache hit.

Lastly, I don't like the example given in the docs for the PR.  We really want 
the class to define __hash__ and __eq__ methods.  This doesn't just improve the 
hit rate, it is also necessary for avoiding bugs.  If the coordinates gets 
mutate, the cache has no way of knowing that its entry is invalid:
   
v = Vector(10, 20, 30)
print(v.norm())
v.coordinates = (11, 22, 33)
print(v.norm())

--
nosy: +rhettinger

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



[issue45113] [subinterpreters][C API] Add a new function to create PyStructSequence from Heap.

2021-10-22 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> Why is not PEP 630 enough?

My understanding is that this entire class of code changes has been put on hold 
pending Steering Council approval.  It represents a great deal of code churn 
and creation on new APIs.  Several of the patches had had negative performance 
impacts and AFAICT all of the patches have made the code more complicated and 
harder to maintain.  Several that I looked at had no tests at all, so there was 
no discernible or provabler user benefit.  Also the code being affected is 
typically some of our most stable code that hasn't had to be changed in over a 
decade.  IIRC one or more of the patches created new bugs, were destabilizing, 
or altered the APIs in subtle ways.

Please get explicit approval from the SC before continuing to sweep through the 
code base, creating heap types everywhere.  Given that some essential third 
party modules are not going down this path, it is unlikely that general users 
would ever see any benefit.

--
nosy: +pablogsal

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



[issue45530] Improve listobject.c's unsafe_tuple_compare()

2021-10-19 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
nosy: +rhettinger

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



[issue42222] Modernize integer test/conversion in randrange()

2021-10-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 5afa0a411243210a30526c7459a0ccff5cb88494 by Raymond Hettinger in 
branch 'main':
bpo-4: Remove deprecated support for non-integer values (GH-28983)
https://github.com/python/cpython/commit/5afa0a411243210a30526c7459a0ccff5cb88494


--

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



[issue45491] help() is too noisy for types used like functions

2021-10-15 Thread Raymond Hettinger


New submission from Raymond Hettinger :

When someone requests help(range), help(zip), help(property), or 
help(classmethod), the expectation and need is to see something like what is 
shown in main documentation rather than being subjected to a listing of every 
standard dunder method.

It would be nice to have a way to mark types that are mostly used like 
functions so that help() output will be more focused and less noisy.  Then 
help() can omit the Methods and Static methods sections.  It would keep the 
section for non-standard descriptors such as start, stop, step, fget, fset, or 
fdel.

Alternatively, for all types, we can condense the Methods and Static Methods 
sections to just list the standard dunder methods rather that eating several 
rows of output per method.

--
components: Library (Lib)
messages: 404050
nosy: rhettinger
priority: normal
severity: normal
status: open
title: help() is too noisy for types used like functions
type: enhancement
versions: Python 3.11

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



[issue42222] Modernize integer test/conversion in randrange()

2021-10-15 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
pull_requests: +27270
pull_request: https://github.com/python/cpython/pull/28983

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



[issue45483] pure Python class that has been registered as a `collections.abc.Sequence` can't be recgnized by the match statement without the `_abc` module

2021-10-15 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
nosy: +rhettinger

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



[issue45476] [C API] Convert "AS" functions, like PyFloat_AS_DOUBLE(), to static inline functions

2021-10-14 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> These macros can be abused to be used as l-value

You could simply document, "don't do that".  Also if these is a need to make an 
assignment, you're now going to have to create a new setter function to fill 
the need.

We really don't have to go on thin ice converting to functions that might or 
might not be inlined depending on compiler specific nuances.

AFAICT, no one has ever has problems with these being macros.  There really 
isn't a problem to be solved and the "solution" may in fact introduce new 
problems that we didn't have before.

Put me down for a -1 on the these blanket macro-to-inline function rewrites.  
The premise is almost entirely a matter of option, "macros are bad, functions 
are good" and a naive assumption, "inline functions" always inline.

--
nosy: +lemburg, rhettinger

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



[issue45456] operator 'pass' in 'if-else' linear expression

2021-10-13 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

Evgeniy, please leave this closed and take the proposal to the python-ideas 
mailing list.   There is no further progress that can be made in this tracker 
issue.  We can’t discern any part of your proposal that would make sense for 
improving the language.

--
nosy: +rhettinger
status: open -> closed

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



[issue45438] inspect not capturing type annotations created by __class_getitem__

2021-10-12 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

It looks like the error is in inspect.formatannotation().

For instances of type, that function incorrectly returns only 
annotation.__qualname__.

Instead, it should return repr(annotation) which would include the args.

=


def formatannotation(annotation, base_module=None):
if getattr(annotation, '__module__', None) == 'typing':
return repr(annotation).replace('typing.', '')
if isinstance(annotation, type):# <== Erroneous case
if annotation.__module__ in ('builtins', base_module):
return annotation.__qualname__
return annotation.__module__+'.'+annotation.__qualname__
return repr(annotation)

--

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



[issue45438] inspect not capturing type annotations created by __class_getitem__

2021-10-11 Thread Raymond Hettinger


New submission from Raymond Hettinger :

In the example below, __annotations__ is correct but not the corresponding 
Signature object.

---

from typing import List

def f(s: List[float]) -> None: pass

def g(s: list[float]) -> None: pass

>>> inspect.signature(f)
 None>

>>> inspect.signature(g)
 None>

g.__annotations__
{'s': list[float], 'return': None}

--
components: Library (Lib)
messages: 403692
nosy: gvanrossum, levkivskyi, rhettinger
priority: normal
severity: normal
status: open
title: inspect not capturing type annotations created by __class_getitem__
versions: Python 3.10

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



[issue45356] Calling `help` executes @classmethod @property decorated methods

2021-10-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

It may have been a mistake to allow this kind of decorator chaining.  

* As Randolf and Alex have noticed, it invalidates assumptions made elsewhere 
in the standard library and presumably in third-party code as well.  

* And as Randolf noted in his last post, the current descriptor logic doesn't 
make it possible to implement classmethod properties with setter logic. 

* In issue 44973, we found that staticmethod and property also don't compose 
well, nor does abstract method.

We either need to undo the Python 3.9 feature from issue 19072, or we need to 
put serious thought into making all these descriptors composable in a way that 
would match people's expectations.

--
assignee:  -> rhettinger
nosy: +berker.peksag

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



[issue44904] Classmethod properties are erroneously "called" in multiple modules

2021-10-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Moving this discussion to issue 45356 because some of the discussion would need 
to be duplicated.

--
nosy: +rhettinger
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Calling `help` executes @classmethod @property decorated methods

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



[issue45356] Calling `help` executes @classmethod @property decorated methods

2021-10-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I'm merging issue 44904 into this one because they are related.

--
nosy: +rhettinger

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



[issue45378] Can't find "map" with search on docs.python.org

2021-10-05 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I'm surprised no one else noticed this until now.  

The doc search finds some entries such as: "sum", "min", "max", and 
"enumerate".  However, it is missing others such as: "map" and "filter".

--
nosy: +rhettinger

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



[issue45302] 10 built-in functions need non-None .__text_signature__

2021-10-03 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

As Serhiy says, this is a known issue that we can't do anything about until 
signature objects become more expressive.  The C code already has comments such 
as:

 /* AC: cannot convert yet, waiting for *args support */
 /* AC: cannot convert yet, as needs PEP 457 group support in inspect */

--
nosy: +rhettinger
resolution:  -> wont fix
stage: test needed -> resolved
status: open -> closed

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



[issue45352] Move documentation for typed generic forms of standard collections to collections.abc

2021-10-03 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Where are capabilities like "list[str]" and "dict[str, list[int]]" going to be 
documented?

--

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



[issue44674] dataclasses should allow frozendict default value

2021-10-03 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

[Eric]
> I agree that there's no good way of telling if an
> arbitrary class is immutable, so I'm not sure we can 
> do anything here.

Consider using non-hashability as a proxy indicator for immutability.

-  isinstance(f.default, (list, dict, set))
+  f.default.__hash__ is None

While this is imperfect, it would be more reliable than what we have now.

--
nosy: +rhettinger

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



[issue44831] Inconsistency between datetime.now() and datetime.fromtimestamp(time.time(), None)

2021-10-02 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Related:  https://bugs.python.org/issue45347

--

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



[issue45347] datetime subject to rounding?

2021-10-02 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Related:  https://bugs.python.org/issue44831

--
nosy: +rhettinger

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



[issue45346] Some "truthy" crept in

2021-10-02 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue45346] Some "truthy" crept in

2021-10-02 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 72089f33c0aed391f047b1cbaf19d8da1e51c167 by Miss Islington (bot) 
in branch '3.10':
bpo-45346: Keep docs consistent regarding true and false values (GH-28697) 
(GH-28698)
https://github.com/python/cpython/commit/72089f33c0aed391f047b1cbaf19d8da1e51c167


--

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



[issue45346] Some "truthy" crept in

2021-10-02 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset db91b058d5d4fbff4185982095d90fe6a2741aed by Raymond Hettinger in 
branch 'main':
bpo-45346: Keep docs consistent regarding true and false values (GH-28697)
https://github.com/python/cpython/commit/db91b058d5d4fbff4185982095d90fe6a2741aed


--

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



[issue45346] Some "truthy" crept in

2021-10-02 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
keywords: +patch
pull_requests: +27056
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28697

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



[issue45346] Some "truthy" crept in

2021-10-02 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
nosy: +rhettinger
type: enhancement -> 

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



[issue45313] Counter.elements() wrong error message

2021-09-28 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

The elements() method is working correctly:

>>> from collections import Counter
>>> aCounter = Counter('abracadabra')
>>> list(aCounter.elements())
['a', 'a', 'a', 'a', 'a', 'b', 'b', 'r', 'r', 'c', 'd']

No arguments should be passed into elements, so this code is incorrect:

aCounter.elements(1)

You may have expected that the error message would say:

TypeError: Counter.elements() takes 0 positional argument but 1 was given

Instead, you observed the counts were one higher than you expected.

This is due to how Python implements object oriented programming.

The call:

aCounter.elements(1)

is effectively translated to:

Counter.elements(aCounter, 1)

which does in fact have two arguments.

No one really likes the error message, but it has been deemed hard to fix and 
we just live with it.

Note, this isn't specific to Counter.  All pure python classes work this way:

>>> class A:
def m(self, x):
pass

>>> a = A()
>>> a.m(10, 20)
Traceback (most recent call last):
  File "", line 1, in 
a.m(10, 20)
TypeError: m() takes 2 positional arguments but 3 were given

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

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



[issue45261] Unreliable (?) results from timeit (cache issue?)

2021-09-26 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Given that there isn't an actual bug here, please move this discussion to 
python-ideas.

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

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



[issue45293] List inplace addition different from normal addition

2021-09-26 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Kapil, this behavior was intentional (not a bug), but later regarded as a 
design mistake.  GvR has said that if he had to do it over again list.__iadd__ 
would only accept other lists.  The problem arises when people write "somelist 
+= 'hello'" and expect it to add a single string with one word rather than five 
one letter strings.  That said, the current behavior is guaranteed, people rely 
on it, and we cannot change it.

As Karthikeyan points out, this is documented.  However since the docs have 
grown so voluminous, it is often difficult to find any one particular fact.

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

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



[issue45271] Add a 'find' method (a'la str) to list

2021-09-23 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

This is one bit of symmetry that we shouldn't pursue.  The find() methods have 
been a recurring source of bugs because of failing to check for a -1 result but 
having that be a valid index into the sequence.

Also, the sequence APIs are long established.  If find() were really needed, we 
would have felt the pain and added it long ago.

As Steve says, you can take this to python-ideas, but my recommendation is to 
not do it all.

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

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



[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user

2021-09-22 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user

2021-09-22 Thread Raymond Hettinger

Raymond Hettinger  added the comment:


New changeset 8c21941ddafdf4925170f9cea22e2382dd3b0184 by Alexander Böhn in 
branch 'main':
bpo-39549: reprlib.Repr uses a “fillvalue” attribute (GH-18343)
https://github.com/python/cpython/commit/8c21941ddafdf4925170f9cea22e2382dd3b0184


--

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



[issue40116] Regression in memory use of shared key dictionaries for "compact dicts"

2021-09-22 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> Overall, I expect the improved sharing to more than
> compensate for the disadvantages.

I expect the opposite.  This makes all dicts pay a price (in space, 
initialization time, and complexity) for a micro-optimization of an uncommon 
case (the normal case is for __init__ to run and set all the keys in a 
consistent order).  It is unlikely that the "benefits" to never be felt in 
real-word applications, but "disadvantages" would affect every Python program.

> The language specification says that the dicts maintain insertion 
> order, but the wording implies that this only to explicit 
> dictionaries, not instance attribute or other namespace dicts.

That is a quite liberal reading of the spec.  I would object to making instance 
and namespace dicts behave differently.  That would be a behavior regression 
and we would forever have to wrestle with the difference.

--

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



[issue45265] Bug in append() method in order to appending a temporary list to a empty list using for loop

2021-09-22 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

This is expected behavior.

To get a better understanding, see:  
https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x

To get help writing correct code, please do not use the bug tracker.  Consider 
posting to StackOverflow instead.

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

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



[issue45259] No _heappush_max()

2021-09-21 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

The underscore functions are private and for internal use.  There is no 
_heappush_max() because we didn't need it internally and it would just be dead 
code.

Thanks for the report.

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

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



[issue45246] the sorted() documentation should refer to operator

2021-09-21 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue45246] the sorted() documentation should refer to operator

2021-09-21 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 9a0dcc5b2e04d9c51350107734f12a1cbc0284a7 by Raymond Hettinger in 
branch 'main':
bpo-45246: Document that sorted() only uses "<" comparisons (GH-28494)
https://github.com/python/cpython/commit/9a0dcc5b2e04d9c51350107734f12a1cbc0284a7


--

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



[issue45246] the sorted() documentation should refer to operator

2021-09-21 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> Thank you for looking into this.

You're welcome :-)


> Would it make sense to change list.sort() in the same way?

I think not.  This is a such a minor point and is a distractor.  Most users 
would be better off focusing on the other text.

--

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



[issue45246] the sorted() documentation should refer to operator

2021-09-21 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
pull_requests: +26889
pull_request: https://github.com/python/cpython/pull/28494

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



[issue24076] sum() several times slower on Python 3 64-bit

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> I created a PR from my last patch, inlining the unpacking 
> of single digit integers. 

Thanks, that gets to the heart of the issue.

I marked the PR as approved (though there is a small coding nit you may want to 
fix).

--

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



[issue45246] the sorted() documentation should refer to operator

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

-0 on this.  While it is true that __lt__ is used, we don't really want people 
to exploit that fact.  Doing so will get them into trouble elsewhere.  For 
example, max(seq) uses __gt__.  Also, when mixing types, a return of 
NotImplemented will trigger a call to the reflection method.  And PEP 8 
recommends that all six rich comparison operators be defined to avoid 
hard-to-find bugs.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger, tim.peters

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



[issue39778] collections.OrderedDict and weakref.ref raises "refcount is too small" assertion

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

False alarm.  I misread the diff.  All is well.

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

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



[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

2021-09-20 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
resolution: fixed -> 
status: closed -> 

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



[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

2021-09-20 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
Removed message: https://bugs.python.org/msg402274

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



[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

False alarm.  I misread the diff.  All is well.

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

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 9510e6f3c797b4398aaf58abc1072b9db0a644f9 by Raymond Hettinger in 
branch 'main':
bpo-45155: Apply new byteorder default values for int.to/from_bytes (GH-28465)
https://github.com/python/cpython/commit/9510e6f3c797b4398aaf58abc1072b9db0a644f9


--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-20 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
pull_requests: +26879
pull_request: https://github.com/python/cpython/pull/28465

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



[issue24076] sum() several times slower on Python 3 64-bit

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> OTOH on my Mac I still find that 3.10 with PGO is still 
> more than twice as slow than 2.7.

> Thinking about it that's a bit odd, since (presumably) 
> the majority of the work in sum() involves a long int result 
> (even though the values returned by range() all fit in 30 bits, 
> the sum quickly exceeds that).

The actual accumulation of a long int result is still as fast as it ever was.

The main difference from Py2.7 isn't the addition, it is that detecting and 
extracting a small int added has become expensive.  


-- Python 2 fastpath --

if (PyInt_CheckExact(item)) {   // Very cheap
long b = PyInt_AS_LONG(item);   // Very cheap
long x = i_result + b;  // Very cheap
if ((x^i_result) >= 0 || (x^b) >= 0) {  // Semi cheap
i_result = x;   // Zero cost 
Py_DECREF(item);// Most expensive step, 
but still cheap
continue;
}
}

-- Python 3 fastpath --

if (PyLong_CheckExact(item) || PyBool_Check(item)) { // Cheap
long b = PyLong_AsLongAndOverflow(item, );  // Super 
Expensive
if (overflow == 0 && // Branch 
predictable test
(i_result >= 0 ? (b <= LONG_MAX - i_result)  // Slower 
but better test  
   : (b >= LONG_MIN - i_result)))
{
i_result += b;// Very 
cheap
Py_DECREF(item);
continue;
}
}

-- Supporting function 

long
PyLong_AsLongAndOverflow(PyObject *vv, int *overflow) // OMG, 
this does a lot of work
{
/* This version by Tim Peters */
PyLongObject *v;
unsigned long x, prev;
long res;
Py_ssize_t i;
int sign;
int do_decref = 0; /* if PyNumber_Index was called */

*overflow = 0;
if (vv == NULL) {
PyErr_BadInternalCall();
return -1;
}

if (PyLong_Check(vv)) {
v = (PyLongObject *)vv;
}
else {
v = (PyLongObject *)_PyNumber_Index(vv);
if (v == NULL)
return -1;
do_decref = 1;
}

res = -1;
i = Py_SIZE(v);

switch (i) {
case -1:
res = -(sdigit)v->ob_digit[0];
break;
case 0:
res = 0;
break;
case 1:
res = v->ob_digit[0];
break;
default:
sign = 1;
x = 0;
if (i < 0) {
sign = -1;
i = -(i);
}
while (--i >= 0) {
prev = x;
x = (x << PyLong_SHIFT) | v->ob_digit[i];
if ((x >> PyLong_SHIFT) != prev) {
*overflow = sign;
goto exit;
}
}
/* Haven't lost any bits, but casting to long requires extra
 * care (see comment above).
 */
if (x <= (unsigned long)LONG_MAX) {
res = (long)x * sign;
}
else if (sign < 0 && x == PY_ABS_LONG_MIN) {
res = LONG_MIN;
}
else {
*overflow = sign;
/* res is already set to -1 */
}
}
  exit:
if (do_decref) {
Py_DECREF(v);
}
return res;
}

--

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



[issue45213] Frozen modules are looked up using a linear search.

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

If you close this out, consider adding a prominent comment so that the issue 
will be on the minds of people looking at this code.

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

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



[issue39778] collections.OrderedDict and weakref.ref raises "refcount is too small" assertion

2021-09-20 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Also a test should be added to make sure the weakref callbacks are still 
occurring.

--

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



[issue39778] collections.OrderedDict and weakref.ref raises "refcount is too small" assertion

2021-09-19 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I'm thinking that edit to tp_dealloc was incorrect.  The PyClear call should 
have been replaced (not removed) with the pattern shown in the C APIs docs ( 
https://docs.python.org/3/extending/newtypes.html?highlight=pyobject_clearw#weak-reference-support
 ):

if (self->weakreflist != NULL)
PyObject_ClearWeakRefs((PyObject *) self);

--

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



[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

2021-09-19 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I concur with Ma Lin.

--

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



[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user

2021-09-19 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
assignee:  -> rhettinger

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



[issue45113] [subinterpreters][C API] Add a new function to create PyStructSequence from Heap.

2021-09-19 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Is the subinterpreters work still on hold pending a PEP?

I thought that conversions to heap types had been suspended because there is a 
Steering Council level cost benefit decision.  Mostly it seems that everything 
helps subinterpreters makes code worse in almost every other way (slower, more 
complex, new APIs, etc).

--
nosy: +rhettinger

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



[issue45216] Remove redundand information from difflib docstrings

2021-09-18 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
nosy: +tim.peters

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



[issue45198] __set_name__ documentation not clear about its usage with non-descriptor classes

2021-09-18 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue45198] __set_name__ documentation not clear about its usage with non-descriptor classes

2021-09-18 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 94b462686b7dfabbd69cc9401037d736d71c4dc2 by Raymond Hettinger in 
branch 'main':
bpo-45198: __set_name__ documentation not clear about its usage with 
non-descriptor classes (GH-28439)
https://github.com/python/cpython/commit/94b462686b7dfabbd69cc9401037d736d71c4dc2


--

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



[issue45235] argparse does not preserve namespace with subparser defaults

2021-09-18 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue45235] argparse does not preserve namespace with subparser defaults

2021-09-18 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset a18d52269ab6071a605d6c72f6af585a4c533ca4 by Miss Islington (bot) 
in branch '3.9':
bpo-45235: Fix argparse overrides namespace with subparser defaults (GH-28420) 
(GH-28443)
https://github.com/python/cpython/commit/a18d52269ab6071a605d6c72f6af585a4c533ca4


--

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



[issue45235] argparse does not preserve namespace with subparser defaults

2021-09-18 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 6e4101add568910409294554c8e863226a66bb64 by Miss Islington (bot) 
in branch '3.10':
bpo-45235: Fix argparse overrides namespace with subparser defaults (GH-28420) 
(GH-28442)
https://github.com/python/cpython/commit/6e4101add568910409294554c8e863226a66bb64


--

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



[issue45235] argparse does not preserve namespace with subparser defaults

2021-09-17 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset a6e8db5e8e6780411db749d404715dbe021647c7 by Adam Schwalm in 
branch 'main':
bpo-45235: Fix argparse overrides namespace with subparser defaults (GH-28420)
https://github.com/python/cpython/commit/a6e8db5e8e6780411db749d404715dbe021647c7


--
nosy: +rhettinger

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



[issue45020] Freeze all modules imported during startup.

2021-09-17 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> Raymond, do you think we should also freeze the dependencies
> of runpy (so "python -m " also starts faster)?

Yes, please.  

The '-m' load option can be considered core startup functionality.  It is often 
the recommended way to launch command line tools outside of a virtual 
environment.

   python -m pip install some_package

--

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



[issue45020] Freeze all modules imported during startup.

2021-09-17 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

It would be nice to freeze argparse.py and its dependencies.  For command-line 
tools, startup time is important.

--
nosy: +rhettinger

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



[issue45198] __set_name__ documentation not clear about its usage with non-descriptor classes

2021-09-17 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
keywords: +patch
pull_requests: +26844
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28439

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



[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

2021-09-17 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Pablo, should this be a release blocker?

--
nosy: +lemburg, pablogsal

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



[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

2021-09-17 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> Right now, I'm not sure. The heuristic to decide
> if a function is inlined or not seems to depend
> a lot on the compiler and the compiler options.

That is exactly correct.  And it is why we should
use the macro form which is certain to be inlined. 

Please do as Steve asked  and revert back to the
previous stable, reliable code.

--

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



[issue43413] tuple subclasses allow arbitrary kwargs

2021-09-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

> Subclass of set can now define a __new__() method with 
> additional keyword parameters without overriding also __init__().

Is there any use case for this?   Offhand, I can't think of any reason.

The new code in set.__init__ is somewhat opaque and is likely slower, so I 
prefer the previous code unless there is a legitimate use case being served.

--

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



[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

2021-09-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Confirmed that this weird behavior is still present.  Am not sure when someone 
will have the time and inclination to drill into the cause.

--
nosy: +rhettinger

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



[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

2021-09-16 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
nosy: +lukasz.langa

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



[issue43574] Regression in overallocation for literal list initialization in v3.9+

2021-09-16 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
nosy: +rhettinger

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



[issue45225] use map function instead of genexpr in capwords

2021-09-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Thanks for the PR.

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

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



[issue45225] use map function instead of genexpr in capwords

2021-09-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset a59ede244714455aa9ee8637608e019a20fa2ca6 by speedrun-program in 
branch 'main':
bpo-45225: use map function instead of genexpr in capwords (GH-28342)
https://github.com/python/cpython/commit/a59ede244714455aa9ee8637608e019a20fa2ca6


--
nosy: +rhettinger

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



[issue45224] Argparse shows required arguments as optional

2021-09-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

In Python3.10, "optional arguments" has been replaced with "options".

We didn't backport the change because it risks breaking tests that rely on 
exact string matches.  Also, it was really a bug, it was just an unfortunate 
choice of words.  "Optional arguments" meant to say that it was one of the -x 
or --fullword style arguments which are called options, so they really are 
"optional arguments" as opposed to "positional arguments".  Unfortunately, the 
most obvious reading of "optional arguments" is as the opposite of "required 
arguments" which is not what was meant.

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

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



[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

2021-09-16 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

These should be changed back to macros where inlining is guaranteed.

--

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



[issue45198] __set_name__ documentation not clear about its usage with non-descriptor classes

2021-09-15 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

You are correct that __set_name__ works for non-descriptor classes as well.

The docs for it should be moved out of the "Implementing Descriptors" section.  
Also, it should have a non-descriptor example.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger
versions: +Python 3.10, Python 3.11 -Python 3.6, Python 3.7, Python 3.8

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



[issue45197] IDLE should suppress ValueError for list.remove()

2021-09-14 Thread Raymond Hettinger


New submission from Raymond Hettinger :

I got this today running a stock Python 3.9.6 for macOS downloaded from 
python.org.

-

Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/tkinter/__init__.py",
 line 1892, in __call__
return self.func(*args)
  File 
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/multicall.py",
 line 176, in handler
r = l[i](event)
  File 
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/autocomplete_w.py",
 line 350, in keypress_event
self.hide_window()
  File 
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/autocomplete_w.py",
 line 463, in hide_window
self.widget.event_delete(HIDE_VIRTUAL_EVENT_NAME, seq)
  File 
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/multicall.py",
 line 392, in event_delete
triplets.remove(triplet)
ValueError: list.remove(x): x not in list

--
assignee: terry.reedy
components: IDLE
messages: 401782
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE should suppress ValueError for list.remove()
type: behavior
versions: Python 3.9

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Just reread the thread. AFAICT not a single use case was presented for having 
system byte ordering as the default.  However, multiple respondents have 
pointed out that a default to system byte ordering is a bug waiting to happen, 
almost ensuring that some users will encounter unexpected behaviors when 
crossing platforms.  We've seen issues like that before and should avoid them.

We don't really need a poll.  What is needed is for the system byte ordering 
proponents to present valid reasons why it would useful and to address the 
concerns that it is actually harmful.

If the proposal goes through despite the concerns, we should ask folks writing 
lint tools to flag every use of the default as a potential bug and advise 
people to never use the default unless they know for sure that it is encoding 
only a single byte.  Personally, I would never let system byte ordering pass a 
code review.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-12 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Interestingly, "little" is faster than "big".

$ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")'
500 loops, best of 11: 82.7 nsec per loop
$ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")'
500 loops, best of 11: 90.6 nsec per loop

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-10 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

[Mark Dickinson]
> I'd also really like to avoid a system-dependent default.

[Petr Viktorin]
> Exactly, a platform-dependent default is a bad idea.

I concur with Petr and Mark. 

The principal use case for int.to_bytes is to convert an integer of arbitrary 
size to a binary format for storage or transmission.  The corresponding file 
load or received data needs to symmetrically restore the int.  The default 
(whether little or big) needs to be the same on both sides to prevent bugs.  
Otherwise, for portable code, we would have to recommend that people not use 
the default because the output isn't deterministic across systems.

By way of comparison, we've had long standing issues like this in other parts 
of the language.  For example, this gives inconsistent encodings across systems:

with open(filename) as f:
f.write(text)

Not long ago, Inada had to sweep through and add encoding="utf-8" to fix all 
the bugs caused by the default platform dependent encoding.   Arguably, most 
code that has ever been written without an explicit encoding is wrong if the 
files were intended to be shared outside the local file system.

So if Veky wants the default to be "big", that's fine by me.  The important 
thing is that a *consistent* default be used (not platform dependent).  I won't 
argue for a "sensible default" because apparently Veky has different 
sensibilities.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Serhiy is likely thinking of other the other cases.  Prior to this discussion, 
the principal use for to_bytes and from_bytes was for integers larger than a 
single byte.  If we're going to add a *byteorder* default, it needs to make 
sense for those cases as well.

--

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



[issue45024] Cannot extend collections ABCs with protocol

2021-09-09 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11

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



[issue23864] doc: issubclass without registration only works for "one-trick pony" collections ABCs.

2021-09-09 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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



[issue23864] doc: issubclass without registration only works for "one-trick pony" collections ABCs.

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 89edd18779e382c5fa7f57722b0b897a907ed2c4 by Miss Islington (bot) 
in branch '3.10':
bpo-45024 and bpo-23864: Document how interface testing works with the 
collections ABCs (GH-28218) (GH-28266)
https://github.com/python/cpython/commit/89edd18779e382c5fa7f57722b0b897a907ed2c4


--

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



[issue45024] Cannot extend collections ABCs with protocol

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 89edd18779e382c5fa7f57722b0b897a907ed2c4 by Miss Islington (bot) 
in branch '3.10':
bpo-45024 and bpo-23864: Document how interface testing works with the 
collections ABCs (GH-28218) (GH-28266)
https://github.com/python/cpython/commit/89edd18779e382c5fa7f57722b0b897a907ed2c4


--

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



[issue23864] doc: issubclass without registration only works for "one-trick pony" collections ABCs.

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 62fa613f6a6e872723505ee9d56242c31a654a9d by Raymond Hettinger in 
branch 'main':
bpo-45024 and bpo-23864: Document how interface testing works with the 
collections ABCs (GH-28218)
https://github.com/python/cpython/commit/62fa613f6a6e872723505ee9d56242c31a654a9d


--

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



[issue45024] Cannot extend collections ABCs with protocol

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 62fa613f6a6e872723505ee9d56242c31a654a9d by Raymond Hettinger in 
branch 'main':
bpo-45024 and bpo-23864: Document how interface testing works with the 
collections ABCs (GH-28218)
https://github.com/python/cpython/commit/62fa613f6a6e872723505ee9d56242c31a654a9d


--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Perhaps instead of the system byte ordering, choose one for the default so that 
default encoding/decoding will work cross platform.  I think "little" is the 
most common (intel and arm).

--
nosy: +rhettinger

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



[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Idea for improving unmarshalling speed:  Since reading PYCs is I/O bound, it 
may be worthwhile to compress them.  When the idea came up previously, Antoine 
suggested choosing an algorithm with the fastest possible decompression speed 
(iirc, it was lzma4 at the time).  This should be an easy optimization that 
doesn't require changing the rest of the runtime.

--

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



[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

Thanks for the link.  This is a worthwhile experiment.  However, the potential 
gains will be hard to come by.

The workload of LOAD_CONST is very small.  After paying for the usual dispatch 
logic overhead, all it does is an index into a struct member and an incref.  
Both the co_consts table and the popular constant objects are already likely to 
be in the L1 data cache.  


##DEBUG_LABEL: TARGET_LOAD_CONST
movslq  %r15d, %rax ## OpArg fetch, typically a zero code 
register rename   
movq-368(%rbp), %rcx## 8-byte Reload to access co_consts
movq24(%rcx,%rax,8), %rax   ## The actual indexing operation  (3 
cycles)
incq(%rax)  ## The incref  


A specialized opcode for a specific constant like None can 1) eliminate the 
oparg fetch (likely saving nothing), and 2) eliminate the two sequentially 
dependent memory access (this is a win):

##DEBUG_LABEL: TARGET_LOAD_NONE
  ​  movq   __Py_NoneStruct@GOTPCREL(%rip), rax
incq(%rax)  ## The incref


Any more general opcode for loading small ints would still need the oparg fetch 
and the incref.  To win, it would need to convert the oparg into an int more 
efficiently than the two movq steps.  If the small int table is in a fixed 
location (not per-subinterpreter), then you can save 2 cycles with the simpler 
address computation:

##DEBUG_LABEL: TARGET_SMALLINT
movslq  %r15d, %rax ## OpArg fetch, typically a zero code 
register rename 
movq__Py_SmallInt@GOTPCREL(%rip), %rcx## Find an array of 
ints
movq(%rcx,%rax,8), %rax ## Cheaper address computation takes 1 
cycle
incq(%rax)  ## The incref 

The 2 cycle win (intel-only) will be partially offset by the additional 
pressure on the L1 data cache.  Right now, the co_consts is almost certainly in 
cache, holding only the constants that actually get used (at a rate of 8 per 
cache line).  Accesses into a small_int array will push other data out of L1.

IIRC, Serhiy already experimented with a LOAD_NONE opcode and couldn't get a 
measurable win.

--
nosy: +serhiy.storchaka

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



[issue45152] Prepare for splitting LOAD_CONST into several opcodes

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I didn't know this was in the works.  Can you point me to the relevant 
discussion about why LOAD_CONST would be split?

--
nosy: +rhettinger

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



[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

The pow() docs could use substantial updating.  All of the logic for pow() is 
implemented in base.__pow__(exp, [mod]).  Technically, it isn't restricted to 
numeric types, that is just a norm.  The relationship between "pow(a,b)" and 
"a**b" is that both make the same call, a.__pow__(b).  The discussion of 
coercion rules dates back to Python 2 where used to have a coerce() builtin.  
Now, the cross-type logic is buried in either in type(a).__pow__ or in 
type(b).__rpow__.  The equivalence of pow(a, b, c) to a more efficient form of 
"a ** b % c" is a norm but not a requirement and is only supported by ints or 
third-party types.

My suggestions

1st paragraphs:  Stay at a high level, covering only the most common use case 
and simple understanding of how most people use pow():

   Return *base* to the power *exp* giving the same result
   as ``base**exp``.

   If *mod* is present and all the arguments are integers,
   return *base* to the power *exp*, modulo *mod*.  This
   gives the same result as ``base ** exp % mod`` but is
   computed much more efficiently.

2nd paragraph:  Be precise about what pow() actually does, differentiating the 
typical case from what is actually required:

   The :func:`pow` function calls the base's meth:`__pow__` method
   falling back to the exp's meth:`__rpow__` if needed.  The logic
   and semantics of those methods varies depending on the type.
   Typically, the arguments have numeric types but this is not required.
   For types that support the three-argument form, the usual semantics
   are that ``pow(b, e, m)`` is equivalent to ``a ** b % c`` but
   this is not required.

3rd paragraph: Cover behaviors common to int, float, and complex.

4th paragraph and later:  Cover type specific behaviors (i.e. only int supports 
the three argument form and the other arguments must be ints as well).

--
nosy: +rhettinger

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



[issue45154] Enumerate() function or class?

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

In pure python, generators are implemented as functions.  In CPython, the only 
way to implement them is as a class.  From a user's point of view, enumerate(), 
map(), zip(), and filter() are used like a functions (they doesn't have 
non-dunder methods).  Accordingly, they don't have class markup in the docs 
even though technically they are classes.  The docs are mostly consistent in 
this regard and have opted for the presentation that tends to be the most 
helpful to users.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue45139] Docs: add source directive for minor translation simplification

2021-09-09 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

New directives introduce complexity. They should be saved for pervasive and 
non-trivial problems.

The motivation for this change is dubious (that a translator can't easily 
handle a simple fixed string pattern).  The OP grants that this is a "only 
small burden".   In general, translation is a large, difficult and time 
consuming task.  Adding this directive would not change that noticeably 
(changing the source text is among the easiest and most trivial subtasks).  It 
may even make translators job more difficult because it entails knowing how to 
edit the directive as opposed to use basic knowledge to make a simple in-line 
text substitution.

OTOH, there are costs.  Every new directive takes time to learn and remember.  
This is especially problematic when the directives are specific to one project; 
otherwise, the documentation skills don't translate across projects.  
Generally, it is best to use dirt simple, standard Sphinx markup, especially 
for trivial tasks like this one.

I do a lot of documentation work and am constantly wrestling will sphinx, many 
times unsuccessfully. Even among core developers, very few people already know 
all the directives that we already have.  Making the list longer doesn't make 
our lives easier unless a directive is solves a challenging problem and is 
commonly used.

--

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



[issue20499] Rounding errors with statistics.variance

2021-09-08 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
assignee: steven.daprano -> rhettinger

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



[issue20499] Rounding errors with statistics.variance

2021-09-08 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 3c30805b58421a1e2aa613052b6d45899f9b1b5d by Raymond Hettinger in 
branch '3.10':
[3.10] bpo-20499: Rounding error in statistics.pvariance (GH-28230) (GH-28248)
https://github.com/python/cpython/commit/3c30805b58421a1e2aa613052b6d45899f9b1b5d


--

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



[issue20499] Rounding errors with statistics.variance

2021-09-08 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
pull_requests: +26669
pull_request: https://github.com/python/cpython/pull/28248

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



[issue20499] Rounding errors with statistics.variance

2021-09-08 Thread Raymond Hettinger


Change by Raymond Hettinger :


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

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



[issue20499] Rounding errors with statistics.variance

2021-09-08 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 4a5cccb02bb2254634c0fbb2cbb14e2e7f45e2d5 by Raymond Hettinger in 
branch 'main':
bpo-20499: Rounding error in statistics.pvariance (GH-28230)
https://github.com/python/cpython/commit/4a5cccb02bb2254634c0fbb2cbb14e2e7f45e2d5


--

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



[issue45139] Docs: More surrounding text into the "source" directive

2021-09-08 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
title: Simplify source links in documentation? -> Docs: More surrounding text 
into the "source" directive
versions: +Python 3.11

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



  1   2   3   4   5   6   7   8   9   10   >