[issue47259] Clarify SortingHOWTO regarding locale aware string sorting
Change by Raymond Hettinger : -- title: string sorting often incorrect -> Clarify SortingHOWTO regarding locale aware string sorting versions: +Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue47259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47259] string sorting often incorrect
Raymond Hettinger added the comment: I don't think splashing this everywhere else in the docs would be helpful. Tools like list.sort, sorted, min, max, nlargest, nsmallest use whatever sort order is provided by the underlying object whether it be a string, tuple, float, or int. The section on expressions is the intended place to cover how comparison are defined for core objects: https://docs.python.org/3/reference/expressions.html#value-comparisons As suggested, I will edit the sorting howto to be cleared that locale aware sort ordering refers to alphabetical orderings which can vary (for example, the Spanish ll sorts differently in different locales). -- assignee: -> rhettinger components: +Documentation -Interpreter Core ___ Python tracker <https://bugs.python.org/issue47259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47259] string sorting often incorrect
Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue47259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47121] math.isfinite() can raise exception when called on a number
Raymond Hettinger added the comment: > isfinite() should return True for all ints, without needing > to coerce them to float Whoa there. You're venturing into changing what those math functions were all about and the core approach to how they operate. A zigzag to this new direction would need discussion with all the math folks. Many tools in the math module are thin wrapper around libmath and we never intended to be universal handlers of all numeric types. We have a lot of functions that start by coercing their input to a float. My two cents is that this would open an endless can of worms and make everyone pay a time and complexity cost for a feature that almost no one needs. AFAICT is more of a purity issue than an actual practical need that would warrant separate code paths (for example, we recently closed an issue where someone wanted math.log() to have a separate code path for Fraction inputs where it return log(f.numerator) - log(f.denominator) with the goal of handling fractional values smaller than float_min). -- nosy: +mark.dickinson, tim.peters ___ Python tracker <https://bugs.python.org/issue47121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation
Raymond Hettinger added the comment: This is a partial duplicate of an issue you already filed: https://bugs.python.org/issue47121 where math.isfinite(10**1000) raises an OverflowError even though it type checks. Here was one of the comments: """ Types relationships are useful for verifying which methods are available, but they don't make promises about the range of valid values. For example math.sqrt(float) -> float promises which types are acceptable but doesn't promise that negative inputs won't raise an exception. Likewise, "n: int=10; len(range(n))" is type correct but will raise an OverflowError for "n = 10**100". """ -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue47234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception
Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue28540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception
Raymond Hettinger added the comment: One other thought. The mental model for degrees() is just a simple scaling operation. If done in pure Python, we would get *inf* rather than an OverflowError. I don't see any value in breaking with the obvious substitution: >>> sys.float_info.max * (180 / pi) inf -- ___ Python tracker <https://bugs.python.org/issue28540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception
Raymond Hettinger added the comment: I'm not interested in having this move forward. AFAICT it doesn't solve any known user problems (no one has cared about this before or since this issue was opened). It slightly slows the code. And it might break some existing code that wasn't previously a need to catch an OverflowError. Marking this as closed. If someone thinks this is really needed, feel free to reopen. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47220] Document the optional callback parameter of weakref.WeakMethod
Raymond Hettinger added the comment: Antoine, was the *callback* argument intended to be part of the public API? -- nosy: +pitrou, rhettinger ___ Python tracker <https://bugs.python.org/issue47220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47225] Issue in subtraction of float numbers
Raymond Hettinger added the comment: See https://docs.python.org/3/tutorial/floatingpoint.html -- nosy: +rhettinger resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
Raymond Hettinger added the comment: > any objections before I propose the removal of one-argument super? AFAICT there is nothing to be gained by deprecating the one argument form. Because it has been stable API for two decades, removing it is guaranteed to cause some disruption. So why bother? Anthony Sottile provided this search to showing that at least a few popular projects are using the one argument form of super(): https://sourcegraph.com/search?q=context:global+%5Cbsuper%5C%28%5B%5E%2C%5C%28%5C%29%5Cn%5D%2B%5C%29+file:.py%24=regexp=yes -- ___ Python tracker <https://bugs.python.org/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47083] The __complex__ method is missing from the complex, float, and int built-in types
Change by Raymond Hettinger : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47083> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47178] Improve the implementations of Sequence.index and MutableSequence.extend in collections.abc
Raymond Hettinger added the comment: Marking as closed because the changes are incorrect. See the comments in the PR. -- assignee: -> rhettinger nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47180] Remove unnecessary registration of weakref.WeakSet as a subtype of _collections_abc.Set
Change by Raymond Hettinger : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47180] Remove unnecessary registration of weakref.WeakSet as a subtype of _collections_abc.Set
Change by Raymond Hettinger : -- versions: -Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47157] bijective invertible map
Raymond Hettinger added the comment: This is indeed a duplicate. If needed just use one of implementations on PyPI https://pypi.org/project/bidict/ -- nosy: +rhettinger resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Change by Raymond Hettinger : -- nosy: +ncoghlan ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47083] The __complex__ method is missing from the complex, float, and int built-in types
Raymond Hettinger added the comment: I think this may fine as-is. In general, virtiual classes only promise that an operation will work rather than promsing the presence of a particular method. An object can be Iterable without defining __iter__ because iter() can use __getitem__ and __len__ to build a sequence iterator. Likewise, an object can be a Container without defining __contains__ because the in-operator will work on any iterable. An object can be Reversible without defining __reversed__ because reversed() will fall back to an implementation based on __getitem__ and __len__. The docstring in numbers.Complex promises, "Complex defines the operations that work on the builtin complex type. In short, those are: a conversion to complex, .real, .imag, +, -, *, /, **, abs(), .conjugate, ==, and !=." In other words, the promise is that these work (which they do): >>> complex(0.0) 0j >>> int(0.0) 0 -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue47083> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
Raymond Hettinger added the comment: Will leave this open for a few days to see if anyone else steps forward to make a case for or against this proposal. -- assignee: -> rhettinger versions: -Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
Raymond Hettinger added the comment: Guido, what do you think about this proposal? Personally, I'm dubious about changing the meaning of the arguments between code paths. The callee has no way to distinguish which meaning was intended. And adding classmethod() support in super_descr_get() would create tight coupling where there should be separate concerns (no other descriptor call is classmethod specific). On StackOverflow, there has been some mild interest in the interactions between super() and classmethod(): * https://stackoverflow.com/questions/64637174 * https://stackoverflow.com/questions/1269217 * https://stackoverflow.com/questions/1817183 The OP's proposed use case is mildly plausible though I've never seen it the arise in practice. The GoF factory pattern is typically implemented in a function rather than in the class itself — for example the open() function returns one of two different classes depending on the text or binary file mode. It is rare to see __new__ used to fork off different types based on a parameter. Presumably, it would be even more rare with a classmethod. Also, it's not clear that the GoF pattern would mesh well with our cooperative super() since the upstream parent class isn't known in advance. -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47122] Fix the table of methods in the collections.abc documentation
Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue47122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47121] math.isfinite() can raise exception when called on a number
Raymond Hettinger added the comment: The math.isfinite() docs could be changed to something like, "coerces x to a float if possible and then returns True if x is neither an infinity nor a NaN, and False otherwise." Or there could be a general note about which functions (most of them) coerce to float (which can fail). With respect to typing and PEP-484, I don't see a bug or documentation issue. Types relationships are useful for verifying which methods are available, but they don't make promises about the range of valid values. For example math.sqrt(float) -> float promises which types are acceptable but doesn't promise that negative inputs won't raise an exception. Likewise, "n: int=10; len(range(n))" is type correct but will raise an OverflowError for "n = 10**100". -- assignee: -> docs@python components: +Documentation nosy: +docs@python, rhettinger ___ Python tracker <https://bugs.python.org/issue47121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47114] random.choice and random.choices have different distributions
Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue47114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47114] random.choice and random.choices have different distributions
Raymond Hettinger added the comment: This was an intentional decision. It is documented and tested. The rationale is that is keeps choices() internally consistent so that choices with equal weights produces the same result as if no weights are specified. For anyone who wants an alternative, it is trivial just call choice() in a list comprehension: [choice(seq) for i in range(k)] Another thought is that choices() is more performant than calling choice() in a loop. This matters because one of the principal use cases for choices() in bootstrapping where choices() can be called many times. Lastly, we are strongly averse to changing the algorithms after they are published because it impacts reproducible research where people need to be able to recreate their random selections for a given seed. -- nosy: +rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18241] Add unique option to heapq functions
Change by Raymond Hettinger : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue18241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26019] collections.abc documentation incomplete
Raymond Hettinger added the comment: This was fixed in commit 62fa613f6a6e872723505ee9d56242c31a654a9d -- nosy: +rhettinger resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue26019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433030] SRE: Atomic Grouping (?>...) is not supported
Change by Raymond Hettinger : -- assignee: effbot -> ___ Python tracker <https://bugs.python.org/issue433030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47023] re.sub shows key error on regex escape chars provided in repl param
Raymond Hettinger added the comment:
There seem to be a number of escaping problems in the OP's example.
Is this what was intended?
>>> re.sub(r"\{(\w+)\}", r"\1", "Hello! {user}")
'Hello! user'
--
nosy: +rhettinger
status: pending -> open
___
Python tracker
<https://bugs.python.org/issue47023>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47007] [doc] str docs are inconsistent with special method lookup
Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue47007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46941] Bug or plug not removed (The operator "is")
Raymond Hettinger added the comment: The code in the screenshot looks correct. >>> i = 0 >>> i is int False >>> type(i) is int True The code above does not get warning because "int" is a variable. This kind of comparison is always allowed and will work reliably. >>> i is 0 :1: SyntaxWarning: "is" with a literal. Did you mean "=="? True The above code generates a warning because 0 is a numeric literal and there may be more than one instance of that literal. While this kind of comparison is allowed, it is unreliable because numeric literals are not guaranteed to be singletons: >>> x = 600 >>> (x + x) is 1200 :1: SyntaxWarning: "is" with a literal. Did you mean "=="? False The reliable and correct way to test numeric values with an equality: >>> x + x == 1200 True -- nosy: +rhettinger -Dennis Sweeney, Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue46941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44863] Allow TypedDict to inherit from Generics
Raymond Hettinger added the comment: Related issue: https://bugs.python.org/issue43923 -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue44863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46925] Document dict behavior when setting equal but not identical key
Raymond Hettinger added the comment: The weakref docs in particular should point out the OP's example and highlight the workaround. -- ___ Python tracker <https://bugs.python.org/issue46925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46925] Replace key if not identical to old key in dict
Raymond Hettinger added the comment: I concur with Jelle and Methane that we can't do this without breaking code. Also if you don't care about dict order, the work around is easy. Just remove the old key: d.pop(k); d[k] = v -- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46900] marshal.dumps represents the same list object differently
Raymond Hettinger added the comment: The difference is the FLAG_REF which is set to 128 (0x80). >>> import marshal >>> var_example = [(1,2,3),(4,5,6)] >>> vm = marshal.dumps(var_example) >>> rm = marshal.dumps([(1,2,3),(4,5,6)]) >>> [v ^ r for v, r in zip(vm, rm)] [128, 0, 0, 0, 0, 128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] Whether a flag for possible reuse is generated depends on the reference count of a object. When passing in the list as variable, the reference count is higher than passing it as a literal. That flag tells marshal whether to generate an index entry. Whether that occurs re -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12165] [doc] clarify documentation of nonlocal
Raymond Hettinger added the comment: > I think this is more confusing then helpful. I concur. -- ___ Python tracker <https://bugs.python.org/issue12165> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46852] Remove float.__get_format__() and float.__set_format__()
Raymond Hettinger added the comment: I would not miss these methods. Unless Mark says they are needed, +1 for removal. -- nosy: +mark.dickinson, rhettinger, tim.peters ___ Python tracker <https://bugs.python.org/issue46852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Add an async variant of lru_cache for coroutines.
Raymond Hettinger added the comment: [Andrew Svetlov] > A third-party library should either copy all these > implementation details or import a private function from stdlib OrderedDict provides just about everything needed to roll lru cache variants. It simply isn't true this can only be done efficiently in the standard library. [Serhiy] > it would be simpler to add a decorator which wraps the result > of an asynchronous function into an object which can be awaited > more than once: This is much more sensible. > It can be combined with lru_cache and cached_property any third-party > caching decorator. No access to internals of the cache is needed. Right. The premise that this can only be done in the standard library was false. > async_lru_cache() and async_cached_property() can be written > using that decorator. The task becomes trivially easy :-) [Andrew Svetlov] > Pull Request is welcome! ISTM it was premature to ask for a PR before an idea has been thought through. We risk wasting a user's time or committing too early before simpler, better designed alternatives emerge. -- ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46813] Allow developer to resize the dictionary
Raymond Hettinger added the comment: I'm going to close this one. Making a new and previously rejected extension to one of Python's most import APIs requires broad discussion and buy-in. If you really want to push for this, please take it to the python-ideas list. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Add an async variant of lru_cache for coroutines.
Change by Raymond Hettinger : -- title: Add a async variant of lru_cache for coroutines. -> Add an async variant of lru_cache for coroutines. ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46622] Add a async variant of lru_cache for coroutines.
Raymond Hettinger added the comment: If this goes forward, my strong preference is to have a separate async_lru() function just like the referenced external project. For non-async uses, overloading the current lru_cache makes it confusing to reason about. It becomes harder to describe clearly what the caches do or to show a pure python equivalent. People are already challenged to digest the current capabilities and are already finding it difficult to reason about when references are held. I don't want to add complexity, expand the docs to be more voluminous, cover the new corner cases, and add examples that don't make sense to non-async users (i.e. the vast majority of python users). Nor do I want to update the recipes for lru_cache variants to all be async aware. So, please keep this separate (it is okay to share some of the underlying implementation, but the APIs should be distinct). Also as a matter of fair and equitable policy, I am concerned about taking the core of a popular external project and putting in the standard library. That would tend to kill the external project, either stealing all its users or leaving it as something that only offers a few incremental features above those in the standard library. That is profoundly unfair to the people who created, maintained, and promoted the project. Various SC members periodically voice a desire to move functionality *out* of the standard library and into PyPI rather than the reverse. If a popular external package is meeting needs, perhaps it should be left alone. As noted by the other respondants, caching sync and async iterators/generators is venturing out on thin ice. Even if it could be done reliably (which is dubious), it is likely to be bug bait for users. Remember, we already get people who try to cache time(), random() or other impure functions. They cache methods and cannot understand why references is held for the instance. Assuredly, coroutines and futures will encounter even more misunderstandings. Also, automatic reiterability is can of worms and would likely require a PEP. Every time subject has come up before, we've decided not to go there. Let's not make a tool that makes user's lives worse. Not everything should be cached. Even if we can, it doesn't mean we should. -- title: Support decorating a coroutine with functools.lru_cache -> Add a async variant of lru_cache for coroutines. ___ Python tracker <https://bugs.python.org/issue46622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46828] math.prod can return integers (contradicts doc)
Raymond Hettinger added the comment: I'll add a note that the output type is determined by the input type. -- assignee: docs@python -> rhettinger nosy: +rhettinger priority: normal -> low ___ Python tracker <https://bugs.python.org/issue46828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Raymond Hettinger added the comment:
Note that adding an empty __post_init__ method would be a breaking change. The
following prints out 'B' then 'C'. But if class A adds an empty __post_init__,
then 'B' never gets printed. The arrangement relies on class A being a
passthrough to class B.
from dataclasses import dataclass
@dataclass
class A:
pass
@dataclass
class B:
def __post_init__(self):
print('B')
@dataclass
class C(A, B):
def __post_init__(self):
super().__post_init__()
print('C')
c = C()
--
___
Python tracker
<https://bugs.python.org/issue46757>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46814] Documentation for constructing abstract base classes is misleading
Raymond Hettinger added the comment: FWIW, I’m only -0 on this. It is also perfectly reasonable to say that a class is abstract if and only if there is at least one remaining abstract method. After 15 years though, I’m inclined to say that the status quo wins. -- ___ Python tracker <https://bugs.python.org/issue46814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46814] Documentation for constructin abstract base classes is misleading
Raymond Hettinger added the comment: An analogy may help. Release managers must check the list of release blockers and stop if the list is non-empty. If no release blockers were ever filed, the release blockers list is empty, but it still exists and its definition hasn't changed. The test is_blocked(blockers) tells us whether the list is non-empty. It doesn't redefine what it means to be a blockers list. -- ___ Python tracker <https://bugs.python.org/issue46814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46814] Documentation for constructin abstract base classes is misleading
Raymond Hettinger added the comment:
To me, this looks like a way too extensive edit jsut to emphasize a corner case
that rarely arises in practice. It bends over backwards to force an awkward
definition regarding what an ABC really is.
A more minimal edit is to just note that inspect.isabstract() returns true if a
class inherits from ABC and has at least one remaining abstractmethod.
That tells the truth without having to redefine an ABC. And it matches the
spirit of the ABC mechanism. At no point does ABCMeta ever require that any
class in the chain must have ever defined an abstractmethod. Instead, its only
rule is that if there is least one remaining abstractmethod, it will refuse to
instantiate. Roughly:
if any(getattr(meth, '__isabstractmethod__', False) for meth in meths):
raise TypeError("Can't instantiate")
instantiate(cls)
Note, any() defaults to False if there are no inputs and that the actual C code
works the same way. Even if a class never defines any abstractmethods, this
test still occurs. For an empty ABC, it just happens to always succeed in
instantiating because there is no work left to be done.
Worldviews aside, I don't think it helpful to users to everywhere rewrite what
it means to be an ABC just to make it match the output of inspect.isabstract()
which is just short for inspect.has_abstract_methods_remaining().
Guido, any thoughts?
--
nosy: +gvanrossum, rhettinger
___
Python tracker
<https://bugs.python.org/issue46814>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46813] Allow developer to resize the dictionary
Raymond Hettinger added the comment: This idea surfaced once before and Guido shot it down. IIRC the rationale was the exposed implementation details, that would challenging for users to consistently set the size correctly, and that it may not make sense for other implementations. This was a good while ago so it may be worth scanning the tracker or python-dev archives to find where he opined. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46812] Thread starvation with threading.Condition
Change by Raymond Hettinger : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue46812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Raymond Hettinger added the comment: -1 * I concur with Eric that this is mostly not needed. Probably 99.95% of dataclass use case don't need this. When it is needed, it is trivial to implement and probably should be explicit rather that implicit. * Vedran is also correct in noting that it would sometimes mask errors. * There is a runtime cost for all dataclasses that do not use __post_init__. Calling an empty method takes time. We shouldn't make all users pay for a feature that almost no one needs. * With respect to use of super(), it might help a little bit, but only because __post_init__() takes no arguments. For the other methods in cooperative multiple inheritance, a user would need to either incorporate a straight forward hasattr() check or add a terminal root class as described in super-considered-super. I see no reason to make __post_init__ a special case that would differ from other methods (for example, object() doesn't provide an empty __call__ or __getitem__). * Adding a default __post_init__ will create a new problem. Currently, it is possible to easily introspect and determine whether a __post_init__ has been provided, but if there is an empty default, it becomes a much more tricky test. We had this problem with functools.total_ordering. When that tool was first created, we could easily use hasattr() to test for a user defined rich comparison method. But after default methods were added to object(), the test because much more delicate: ``getattr(cls, op, None) is not getattr(object, op, None)``. Likewise the Hashable ABC cannot just use hasattr() because __hash__() is always present and has to be set to None to turn it off. A default __post_init__ is worse than both cases. You can't test for it, so you just have to call it, not knowing in advance whether it would do anything. * Anyone supporting multiple versions of Python will still need to write the hasattr() check or provide a terminal/root class. They won't be able to rely on the default being present. I recommend leaving dataclasses as is. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.
Raymond Hettinger added the comment:
> Nor will it achieve world peace.
Please watch the tone. It is borderline abusive and dismissive.
> we can invoke the attached as best_fraction(Fraction("0.001"),
> Fraction("0.0005"), Fraction("0.0015")) to get the output
> Fraction(1, 1000).
-1 I am solidly against this. The other inputs to Fraction() are exact
conversions. The proposal works against a core concept behind the fraction
module.
Also, my expectation for Fraction("0.0015") would be to give Fraction(3, 2000),
the same as would be given by Fraction(Decimal("0.0015")).
> But if it solves enough use cases then it is worth discussing, yes?
Perhaps this tracker issue should be closed and moved to python-ideas. The
notions are currently too immature to warrant more core developer time.
Also, it would be nice to have research into what other languages and libraries
do for fractional approximations of decimal strings.
--
___
Python tracker
<https://bugs.python.org/issue46780>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.
Raymond Hettinger added the comment: Also note for the music example that the notion of "near enough" isn't equidistant about the "simple fraction". The sense of nearness is logarithmic and is measured in "cents" which are hundredths of an equal-tempered semitone (i.e a one octave consists of 1200 cents). -- ___ Python tracker <https://bugs.python.org/issue46780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.
Raymond Hettinger added the comment: I don't think the standard library should go down this path. Mark's disinclinations all make sense to me, but I'm also concerned that the API would be almost unusable in practical situations. Users would tend to know their input fraction and that they have a desire for "simplification", but it would be challenging for them to come with a surrounding interval that made sense. We could attempt to infer an interval from the input, but a user is likely to have a poorly specified idea of what they actually want. The operating principle here is, "refuse the temptation to guess". Here's a little exercise for the API. The 12 semitones in an octave are separated by a frequency ratio of 2**(1/12). For example, if A is 440 Hz, then A# is 440*2**(1/12) = 466.16 Hz. Note pairs sound the most harmonious when the ratio of their frequencies is a "near" a small fraction. Determine the small fraction for each of the twelve notes. For example, a perfect fifth has the frequency ratio of 2**(7/12) -> 1.498307 — it it "perfect" because it "close-enough" to the small integer ratio of 3 : 2. Notice the vague requirements of "near", "close-enough" and "small integer ratio". -- ___ Python tracker <https://bugs.python.org/issue46780> ___ ___ 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
Raymond Hettinger added the comment: See also: https://bugs.python.org/issue46764 -- ___ 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
[issue46764] Wrapping a bound method with a @classmethod no longer works
Raymond Hettinger added the comment: This seems like a reasonable fix. I'll wait a bit so that others can comment as well. FWIW, we looking a potentially reverting the whole line of development starting with that commit. It has caused a number of problems and no longer looks tenable. See https://bugs.python.org/issue45356 -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue46764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46783] Add a new feature to enumerate(iterable, start=0) built-in function
Raymond Hettinger added the comment: Thank you for the suggestion, but we will decline. We looked at this before and decided not to go down this path, preferring instead to the keep the builtin function simple and focused on its core task of enumeration. To cover the rarer cases, it is a simple matter to fulfill the need with fast, clear code using itertools: >>> from itertools import count >>> names = ['eddard', 'catelyn', 'robb', 'sansa', 'arya', 'bram', 'rickon'] >>> for i, name in zip(count(start=7, step=-1), names): print(i, name) 7 eddard 6 catelyn 5 robb 4 sansa 3 arya 2 bram 1 rickon -- assignee: -> rhettinger nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46737] Default to the standard normal distribution
Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46737] Default to the standard normal distribution
Raymond Hettinger added the comment: New changeset 08ec80113b3b7f7a9eaa3d217494536b63305181 by Zackery Spytz in branch 'main': bpo-46737: Add default arguments to random.gauss and normalvariate (GH-31360) https://github.com/python/cpython/commit/08ec80113b3b7f7a9eaa3d217494536b63305181 -- ___ Python tracker <https://bugs.python.org/issue46737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45976] Random._randbelow() loses time by caching an attribute lookup
Raymond Hettinger added the comment: I'm thinking that we care more about the unhappy cases (the extreme values) than we care about a mild and implementation dependent improvement to the average case. -- resolution: later -> rejected ___ Python tracker <https://bugs.python.org/issue45976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46737] Default to the standard normal distribution
New submission from Raymond Hettinger : This is really minor, but it would convenient if we provided default arguments: random.gauss(mu=0.0, sigma=1.0) random.normalvariate(mu=0.0, sigma=1.0) -- components: Library (Lib) messages: 413177 nosy: rhettinger priority: normal severity: normal status: open title: Default to the standard normal distribution type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46700] wrong nomenclature (options vs. arguments) in argparse
Raymond Hettinger added the comment: Éric is correct. There is not much that can be done about this. The nomenclature is deeply baked into the code and the docs. We did change the help output to list "options" rather than "optional arguments". That helps the end users so that "optional" doesn't imply the opposite of "required". -- nosy: +rhettinger resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46718] Feature: itertools: add batches
Change by Raymond Hettinger : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46728] Docstring of combinations_with_replacement for consistency
Change by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
Change by Raymond Hettinger : -- nosy: -rhettinger ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46713] Provide a C implementation of collections.abc.KeysView and friends
Raymond Hettinger added the comment: - arbitrary mappings supports by the view ABCs + arbitrary mappings supported by the view ABCs - A first look, + At first glance, -- ___ Python tracker <https://bugs.python.org/issue46713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46713] Provide a C implementation of collections.abc.KeysView and friends
Raymond Hettinger added the comment: Some thoughts: * Other than set operations, most of the pure python code in the dict view ABCs are fast pass throughs. There is no point in rewriting these in C: def __contains__(self, key): return key in self._mapping def __iter__(self): yield from self._mapping def __len__(self): return len(self._mapping) * For the set operations, the pure python code has only a simple for-loop and contains test. There isn't much fat to be cut: def __ge__(self, other): if not isinstance(other, Set): return NotImplemented if len(self) < len(other): return False for elem in other: if elem not in self: return False return True * Possibly the eval-loop overhead can be eliminated with Python by using itertools: def __ge__(self, other): if not isinstance(other, Set): return NotImplemented if len(self) < len(other): return False for elem in filterfalse(self.__contains__, other): return False return True * That leaves the question of why the dict views are so much faster (presuming that the posted timings are representative). I haven't looked in detail, but the first candidate that comes to mind is that dictviews_to_set() has a fast path for exact dicts. That lets it bypass the mapping proxy and exploit the fast path in PySet_New for exact dicts. That fast path reuses the stored hash values and exploits knowing that the input has no duplicates. Off-hand, I don't see how that can generalize to the arbitrary mappings supports by the view ABCs. * Summary: A first look, it doesn't seem like a C rewrite of the view ABCs would bear fruit. -- ___ Python tracker <https://bugs.python.org/issue46713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46721] Optimize set.issuperset() for non-set argument
Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue46721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46718] Feature: itertools: add batches
Raymond Hettinger added the comment: For large n, I don't think a C implementation would do much better than your Python version where most of the work is done by chain() and islice() which are already in C. The best that could be done is to eliminate the overhead of chain() which is likely about a third of the cost. For smaller n, the grouper recipe is already very close to optimal. -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue46718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Raymond Hettinger added the comment: > Would not testing len(self.difference(other)) == 0 > be more efficient? Yes, I think so. -- Added file: https://bugs.python.org/file50620/instrument_issubset.py ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Raymond Hettinger : Added file: https://bugs.python.org/file50615/instrument_issubset.py ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Raymond Hettinger : Removed file: https://bugs.python.org/file50614/instrument_issubset.py ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Raymond Hettinger : Removed file: https://bugs.python.org/file50613/instrument_issubset.py ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Raymond Hettinger added the comment: I've run a few more experiments and this looks like a net win more often than not. Go ahead and submit a PR so we can evaluate it further. -- Added file: https://bugs.python.org/file50614/instrument_issubset.py ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Raymond Hettinger added the comment: We care more about the running speed than the memory usage. Since sets only store pointers to data, they are typically smaller than the data they refer to. I've attached some instrumentation code for running experiments to verify the workload under various scenarios. -- Added file: https://bugs.python.org/file50613/instrument_issubset.py ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Raymond Hettinger : -- versions: -Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46684] Expose frozenset._hash classmethod
Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue46684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46684] Expose frozenset._hash classmethod
Raymond Hettinger added the comment: > Why not expose the C implementation via a frozenset._hash() > classmethod, and change Set._hash() to merely call that? The frozenset.__hash__ method is tightly bound to the internals of real sets to take advantage of the hash values already being known for real sets. So we can't just expose it to ABC sets. Also, the ABC sets need to be kept in sync with an __eq__ method, so users really need to see what Set._hash is actually doing. Lastly, pure python hashable sets based on the ABC are not common, so it doesn't warrant a C fast path. If C fast paths were offered, the union, intersection, and difference methods would more important targets. So, thanks for the suggestion but it isn't as straight-forward as exposing existing code and it might make it harder for implementer to stay synced with an __eq__ method. Tangential thought: If you do implement __hash__ with Set._hash, consider using a cached_property decorator. -- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed type: -> performance versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46669] Add types.Self
Raymond Hettinger added the comment: > Your suggested signature looks like it's trying to support > the second invariant, but it doesn't quite: if the types > don't match, the type checker will just set T to the > common base type of the two arguments. Is there a way to write the second invariant correctly? -- ___ Python tracker <https://bugs.python.org/issue46669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
Raymond Hettinger added the comment:
> New learners coming to Python don't know the same things
> as people with experience.
IMO, new learners will be worse off by adding "returns None" to all of the
builtins. At best it a distractor.
I work with new learners almost every day. The issue never arises. No one
writes "x = print('hello world')" and they would be worse off if shown such a
possibility.
One other consideration is that MyPy and the tools that use it (such as
PyCharm) reject the idea of None as return value. Their view is that no value
is returned all. We don't want the docs to contradict that world view.
$ cat hello.py
x = print('hello world')
$ mypy hello.py
hello.py:1: error: "print" does not return a value
Found 1 error in 1 file (checked 1 source file)
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46669] Add types.Self
Change by Raymond Hettinger : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Implementing PEP 673 (Self type) ___ Python tracker <https://bugs.python.org/issue46669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46669] Add types.Self
Raymond Hettinger added the comment:
On a related note, is this the correct way to annotate __exit__?
Exc = TypeVar('Exc', bound=Exception)
def __exit__(self, exctype: Optional[Type[Exc]], excinst: Optional[Exc], exctb:
Any) -> None:
--
___
Python tracker
<https://bugs.python.org/issue46669>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46666] IDLE Add indent guide
Raymond Hettinger added the comment:
If this were possible, it would be really nice to have.
FWIW, the rich¹ project was able to pull this off in regular text terminal
window:
$ python3.10 -m pip install rich
$ python3.10 -m rich.pretty
{
│ 'foo': [1, 'Hello World!', 100.123, 323.232, 432324.0, {(1, 2, 3, 4), 5, 6,
7, 8}, ...],
│ 'bar': frozenset({1, 2, 3}),
│ 'defaultdict': defaultdict(, {'crumble': ['apple', 'rhubarb',
'butter', 'sugar', 'flour']}),
│ 'counter': Counter({'apple': 1, 'orange': 1, 'pear': 1, 'kumquat': 2,
'duriandurianduriandu'+580: 1}),
│ 'atomic': (False, True, None),
│ 'Broken':
}
¹ https://rich.readthedocs.io/en/stable/index.html
--
nosy: +rhettinger
___
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
[issue46669] Add types.Self
New submission from Raymond Hettinger :
Typeshed now has a nice self-describing type variable to annotate context
managers:
Self = TypeVar('Self')
def __enter__(self: Self) -> Self:
return self
It would be nice to have that in the standard library types module as well.
--
messages: 412682
nosy: Jelle Zijlstra, gvanrossum, rhettinger
priority: normal
severity: normal
status: open
title: Add types.Self
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46669>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46615] Use-after-free by mutating set during set operations
Raymond Hettinger added the comment: Marking as low priority given that ehe next loop code has been deployed without incident for two decades (a little less for sets and a little more for dicts). -- priority: normal -> low ___ Python tracker <https://bugs.python.org/issue46615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46200] Discourage logging f-strings due to security considerations
Raymond Hettinger added the comment: In a favor of deferred substitution, the cookbook should have a recipe where substituted messages are logged to a file and the unsubstituted message stored in SQLite3 database with the parameters stored as JSON.This gives both human readable output and queryable, preparsed data for automated analysis. -- ___ Python tracker <https://bugs.python.org/issue46200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46200] Discourage logging f-strings due to security considerations
Raymond Hettinger added the comment:
> Eric is absolutely right, due to function calls being
> somewhat slow in Python the performance argument in
> practice falls in favor of f-strings.
Also f-strings can evaluate expressions in the template which is also a big win:
f('Pending {len(req)} requests: {req[0]!r} ... {req[-1]!r}')
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46615] Use-after-free by mutating set during set operations
Raymond Hettinger added the comment: Presumably _PyDict_Next is also suspect. Even the advertised "safe" calls to PyDict_SetItem() for existing keys would be a trigger. Calling clear() in either __eq__ or __hash__ would suffice. If the next loops are the culprint, the new challenge is figuring out how to fix it without wrecking code clarity and performance (and having to deprecate PyDict_Next() which is part of the stable ABI). -- ___ Python tracker <https://bugs.python.org/issue46615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46615] Use-after-free by mutating set during set operations
Raymond Hettinger added the comment: The likely culprit is the set_next() loop. Perhaps it is never safe to use set_next() because any lookup can callback to __eq__ which can mutate the set. Since set_isdisjoint() method isn't a mutating method, that is the easiest place to start investigating. Try disabling the exact set fast path to see if the issue persists. -- ___ Python tracker <https://bugs.python.org/issue46615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46624] random.randrange removed support for non-integer types after just one release of deprecation
Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46624] random.randrange removed support for non-integer types after just one release of deprecation
Raymond Hettinger added the comment: New changeset 6baa98e538b2e26f16eaaf462f99496e98d2cfb1 by Miro Hrončok in branch 'main': bpo-46624: Defer to 3.12: "Remove deprecated support for non-integer values" (GH-31098) https://github.com/python/cpython/commit/6baa98e538b2e26f16eaaf462f99496e98d2cfb1 -- ___ Python tracker <https://bugs.python.org/issue46624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46621] Should map(function, iterable, ...) replace StopIteration with RuntimeError?
Raymond Hettinger added the comment: -1 for being a breaking change, for addressing a minor issue that rarely arises in real life, and for being a slippery slope. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46610] assertCountEqual doesn't work as expected for dictionary elements
Raymond Hettinger added the comment: I agree with Eric that this should not be changed. It is working as documented and intended. In its original incarenation, assertCountEqual was documented as being equivalent to ``assertEqual(sorted(expected), sorted(actual))``. Either way, the goal was to count the values produced by iterating. To compare two dicts or two Counters including both keys and values, just use assertEqual. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46561] Descriptor resolution should own arguments passed to descriptors
Raymond Hettinger added the comment: If this can only be triggered from C code, it less of a concern. The PR increases cost on a critical path, so we ought to be wary of applying it unless a known problem is being solved. Note, this code path has survived two decades of deployment. Also, the PR doesn't have a test to demonstrate that it fixes anything. Those facts give some evidence that the PR has every user paying to solve a problem that almost no one actually has. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46554] Add append keyword argument to Path.write_text() and Path.write_bytes()
Raymond Hettinger added the comment: I concur with Serhiy. -- nosy: +pitrou, rhettinger ___ Python tracker <https://bugs.python.org/issue46554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46574] itertools.count should work with non-number types
Raymond Hettinger added the comment:
Thanks for the suggestion but I'm going to decline.
* The need for this is very low.
* It's easy to roll your own.
* The code for `count('', 'a')` and `count((), (1,))` isn't intelligible.
* Without special casing, the code for `count('', 'a')` and `count((), (1,))`
is highly inefficient. We advise people not to use the 's = s + t' pattern in
a loop for sequences because it leads to quadratic behavior.
--
assignee: -> rhettinger
nosy: +rhettinger
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46574>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33205] GROWTH_RATE prevents dict shrinking
Change by Raymond Hettinger : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue33205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46527] enumerate no longer accepts iterable keyword argument
Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33205] GROWTH_RATE prevents dict shrinking
Raymond Hettinger added the comment: Should this have been "filled*3" rather than "used*3"? The intent was to give a larger resize to dict that had a lot of dummy entries and a smaller resize to dicts without deletions. -- ___ Python tracker <https://bugs.python.org/issue33205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46488] listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time.
Change by Raymond Hettinger : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: > But I won't post code (unless someone asks) Okay, I'll ask. -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46488] listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time.
Raymond Hettinger added the comment: Presumably the OP is referring to this text: """ `powerloop()` emulates these divisions, 1 bit at a time, using comparisons, subtractions, and shifts in a loop. You'll notice the paper uses an O(1) method instead, but that relies on two things we don't have: - An O(1) "count leading zeroes" primitive. We can find such a thing as a C extension on most platforms, but not all, and there's no uniform spelling on the platforms that support it. - Integer division on an integer type twice as wide as needed to hold the list length. But the latter is Py_ssize_t for us, and is typically the widest native signed integer type the platform supports. But since runs in our algorithm are almost never very short, the once-per-run overhead of `powerloop()` seems lost in the noise. """ -- assignee: docs@python -> tim.peters nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
