[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Raymond Hettinger added the comment: > Changing the way isinstance works internally might prove > beneficial for such tools. ISTM you're advocating a design change rather than discussing a bug report. The python-ideas mail list would be a better forum than the tracker. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46041] Add reference counting micro-optimizations to listobject.c
Raymond Hettinger added the comment: The OP self-closed the PR. -- nosy: +rhettinger resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46068] Change use of warnings.warn to logging.warning in a few places
Raymond Hettinger added the comment: > The downside of making this change is that it may break 3rd party unit tests. I don’t see any upside. The modules in question have been stable for a good while. There’s no benefit to changing them. Also, there is no strong agreement that the standard library should ever prefer logging.warn() over the warnings module which has mechanisms for filtering the warnings. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46068] Change use of warnings.warn to logging.warning in a few places
Change by Raymond Hettinger : -- Removed message: https://bugs.python.org/msg408512 ___ Python tracker <https://bugs.python.org/issue46068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46068] Change use of warnings.warn to logging.warning in a few places
Raymond Hettinger added the comment: > The downside of making this change is that it may break 3rd party unit tests. I don’t see any upside. The modules in question have been stable for a good while. There’s no benefit to changing them. Also, there is no strong agreement that the standard library should ever prefer logging.warning() over the warnings module which has mechanisms for filtering the warnings, escalating them to errors, or limiting the number of times they are reported. -- ___ Python tracker <https://bugs.python.org/issue46068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError
Change by Raymond Hettinger : -- status: pending -> closed ___ Python tracker <https://bugs.python.org/issue25864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46086] Add ratio_min() function to the difflib library
Change by Raymond Hettinger : -- assignee: -> tim.peters ___ Python tracker <https://bugs.python.org/issue46086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46085] OrderedDict iterator allocates di_result unnecessarily
Change by Raymond Hettinger : -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue46085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Raymond Hettinger added the comment: This seems to be a temporary outage, expected to be restored in the first half of 2022. Source: https://www.usno.navy.mil/USNO/time/master-clock I'll look for an alternative time source that is currently online. -- assignee: docs@python -> rhettinger nosy: +rhettinger priority: normal -> low ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45959] Teach pprint about dict views
Raymond Hettinger added the comment: More accurate to say that it aspires to print in a single line ONLY if the content fits in the specified width. Otherwise, it prints vertically with appropriate indentation. Indeed, that is the entire purpose of the module; otherwise, we would just use print() which always writes one line. -- ___ Python tracker <https://bugs.python.org/issue45959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46081] Document the msg argument for assertRaises
Raymond Hettinger added the comment: I concur with Eric that the current presentation is reasonable and better than adding boilerplate to every entry. It suffices that the docs cover the *msg* argument once and that each entry includes *msg* in its signature. Elsewhere in the docs we also try to avoid unnecessary repetition (for example, most classes don't list all their dunder methods). Excess repetition in the docs impairs readability. The unittest docs are already so long that it discourages someone from reading it top to bottom. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46092] Fix/update missing parameters in function signatures for Built-in Functions documentation.
Raymond Hettinger added the comment: My understanding is that we're holding off on adding the slash notation to the main docs. The reason is that they are mostly unintelligible to the average user. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46095] Warning about iterate/modify has unwarranted detail
Raymond Hettinger added the comment: I think this note can be removed. The tutorial now has coverage of mutating while iterating. That is the correct place for discussion of looping techniques. The part about the "internal counter" needs to be rewritten and moved to stdtypes.rst section on Sequence types. Here is a first draft: "Forward and reversed iterators over sequences access values using an index. That index will continue to march forward (or backward) even if the underlying sequence is mutated. The iterator terminates only when an IndexError or StopIteration is encountered (or when the index drops below zero)." Sequence iterators are roughly equivalent to: def seqiter(seq): i = 0 while True: try: yield seq[i] except (IndexError, StopIteration): break i += 1 -- assignee: docs@python -> rhettinger nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46095] Improve SeqIter documentation
Change by Raymond Hettinger : -- title: Warning about iterate/modify has unwarranted detail -> Improve SeqIter documentation type: enhancement -> versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46095> ___ ___ 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: For the small cases (say n < 50), we can get faster code by using a small (3Kb) table of factorial logarithms: double lf[50] = [log2(factorial(n)) for n in range(50)]; Then comb() and perm() can be computed quickly and in constant time using the C99 math functions: result = PyLong_FromDouble(round(exp2(lf[n] - (lf[r] + lf[n-r]; -- ___ 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
[issue37295] Possible optimizations for math.comb()
Change by Raymond Hettinger : -- Removed message: https://bugs.python.org/msg408865 ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: For the small cases (say n < 50), we can get faster code by using a small (3Kb) table of factorial logarithms: double lf[50] = [log2(factorial(n)) for n in range(50)]; Then comb() and perm() function can be computed quickly and in constant time using the C99 math functions: result = PyLong_FromDouble(round(exp2(lf[n] - (lf[r] + lf[n-r]; -- ___ 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
[issue33567] Explicitly mention bytes and other buffers in the documentation for float()
Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue33567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46076] Document using __slots__ to provide per-attribute docstrings
Raymond Hettinger added the comment: New changeset aeb9ef4c7287fe367b6e9adcf1c5f994d5bc1a09 by Alex Waygood in branch 'main': bpo-46076: Improve documentation for per-attribute docstrings with `__slots__` (GH-30109) https://github.com/python/cpython/commit/aeb9ef4c7287fe367b6e9adcf1c5f994d5bc1a09 -- ___ Python tracker <https://bugs.python.org/issue46076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46076] Document using __slots__ to provide per-attribute docstrings
Raymond Hettinger added the comment: Thanks for the PR. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
Raymond Hettinger added the comment: Thanks for the suggestion, but I also concur with Serhiy. -- nosy: +rhettinger resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
Raymond Hettinger added the comment: New changeset 2ef06d412531d1163dbc72877c88aedf3ed82a25 by Matti Picus in branch 'main': bpo-46131: add fastpath for PyFloat_Check() (#30200) https://github.com/python/cpython/commit/2ef06d412531d1163dbc72877c88aedf3ed82a25 -- ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
Change by Raymond Hettinger : -- pull_requests: +28429 pull_request: https://github.com/python/cpython/pull/30208 ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
Raymond Hettinger added the comment: New changeset 29ea68bd1dcf30842c2ed908a6d815bc1d90f484 by Raymond Hettinger in branch 'main': Revert "bpo-46131: add fastpath for PyFloat_Check() (GH-30200)" (GH-30208) https://github.com/python/cpython/commit/29ea68bd1dcf30842c2ed908a6d815bc1d90f484 -- ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
Raymond Hettinger added the comment: That would not change that slot space is at a premium and that we prefer to use that space for high payoff optimizations. -- ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46076] Document using __slots__ to provide per-attribute docstrings
Raymond Hettinger added the comment: New changeset d7537ac8e3a3ef15d2c5f3fe90e998618b6a97b9 by Miss Islington (bot) in branch '3.10': bpo-46076: Improve documentation for per-attribute docstrings with `__slots__` (GH-30109) (GH-30206) https://github.com/python/cpython/commit/d7537ac8e3a3ef15d2c5f3fe90e998618b6a97b9 -- ___ Python tracker <https://bugs.python.org/issue46076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46076] Document using __slots__ to provide per-attribute docstrings
Raymond Hettinger added the comment: New changeset 8bfb11a791679a33024c9857e082afed0d71e0b4 by Miss Islington (bot) in branch '3.9': bpo-46076: Improve documentation for per-attribute docstrings with `__slots__` (GH-30109) (GH-30207) https://github.com/python/cpython/commit/8bfb11a791679a33024c9857e082afed0d71e0b4 -- ___ Python tracker <https://bugs.python.org/issue46076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46132] Consider adding __slots__ to enums?
Raymond Hettinger added the comment: > In which case: consider this a feature request to > consider adding __slots__ ... A few thoughts: * Enumerations tend to be small, so a space savings likely isn't relevant. * In Python 3.11, the speed advantage of slots is now much smaller. * The code for Enum is already complex and has a lot of magic. Adding slots to the equation may make it even harder to reason about the internals. * It not even clear that __slots__ would or could play nice with existing code. Even if it does, it may tie our hands for other avenues of development such as a custom a __getattribute__ or use of @cached_property. Please consider a more use case driven development approach to working on the core. We have no known problems with Enum at this point that need to be solved. A general notion that __slots__ should be used in more places is a reasonable topic for python-ideas. The tracker is more suitable for targeted proposals like, "my company needs enums to work with tool x but it won't unless slot support is added", "my real-world app must support enormous enumerations that lead to memory problems unless slots are added", "i tried adding slots to Enum and found it was easy, didn't cause problems, and sped-up common cases by 22%". I mostly agree with Christian except that limiting attribute access is a legitimate reason to use slots. However, in the case of Enums that isn't a known issue. Also, it is something that would need to done when a tool is first released. Generally, we can't add it afterwards because that would be a breaking change (some applications may be legitimately adding additional attributes). For now, I'll close this. If Ethan thinks there is some fruit on this tree, he can reopen it. Also if a specific real world use case arises, it can be reopened. -- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46132> ___ ___ 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:
> The problem here is that C gives no guarantees about accuracy of either log2
> or exp2
* The input table has hard-wired constants so there is no dependency on log2().
The inputs can be as exact as pi, tau, and e.
* The C library's exp2() function doesn't have to be perfect. Just being good
would suffice. Our test suite already requires that exp2() be within 5 ulp:
self.ftest('exp2(2.3)', math.exp2(2.3), 4.924577653379665)
* With a perfect exp2(), the first failure is at C(50, 22). With a forced
error of 5 ulp, it happens at C(48, 24). So keeping n <= 47 that would let
exp2() be off substantially and still give correct answers.
* Since exp2() is deterministic, it is easy to write a test that covers all
C(n, r) where 0 <= r <= n <= 47. If there were to be a problem, we would know
right away and early during the release cycle.
* Also, it is easy to prove that C(n, r) always gives the correct result for a
given ulp error bound on exp2() and a given limit on n.
* The speed-up is substantial, so this is worth consideration.
> factorial(49) has 163 significant binary digits.
Exact factorials aren't needed. The important fact (no pun intended) is that
comb(47, 23).bit_length() == 44. For this to work, we need one addition and
one subtraction of 53 bit approximations to come within 44 bits of the true
answer.
--
___
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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: Stand by. I think I can implement this using only bit integer arithmetic. Will post tomorrow. -- ___ 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
[issue37295] Possible optimizations for math.comb()
Change by Raymond Hettinger : -- Removed message: https://bugs.python.org/msg408963 ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: > Just curious about why the focus on the newer exp2 and log2? No particular reason, those happened to give slighy best results on macOS. Across compilers, plain exp() is likely the most mature. The quality of log() is irrelevant because it isn't used. The table of log factorials can be precomputed to arbitrary exactness using tools other than the C math libraries. -- ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: > Finv = [pow(fodd, -1, 2**64) for fodd in Fodd] This is a good trick. I had already experimented with separating factorials into an odd component and a shift count, but failed to get a speed-up because the divisions were slow. Having a table of multiplicative inverses and working mod 2**64 bypasses that problem nicely. Division-free is the way to go :-) -- ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: Am I correct in my understanding the 64 bits are always available, that 128 bit ints aren't universal, and that #ifdefs would be needed to extend the range of the table for systems that support it? -- ___ 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
[issue46148] Optimize pathlib
Change by Raymond Hettinger : -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue46148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple
Raymond Hettinger added the comment: > can we finally get rid of this language wart Yes, please. This is a pretty bad pitfall. I've seen this happen to people who've been conditioned by other languages to think of assert() as a macro or function: assert(sometest, somemessage) -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46167> ___ ___ 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: [Mark] > Should I code up my suggestion in a PR, Yes, go for it. -- ___ 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
[issue46182] `super` and descriptor clarification
Raymond Hettinger added the comment: > "a base class ``B`` following ``A``" shouldn't it be "the base > class"? . After all, there is at most one base class following ``A`` No. There can be other classes in the chain. The first to match the lookup wins. > Also, it may help clarify to write "is an object `obj`" and > "is a type `type2`" so that it get clear what `obj` and `type2` means. Sorry, but I don't your proposed wording adds value. While you may feel that it is more precise, it just adds redundant words without adding information. FWIW, we do this all over the docs, letting parameter names such as *obj* and *type2* communicate that we're referring to an object or a type. > Hence, I believe that the parentheses should be removed after `m` I took care of that in the other tracker issue. That said, it arguably made the docs worse rather than better because by far the dominant use case for super() is calling methods rather than doing attribute lookup. I only made the change to be consistent with the other attribute lookup examples. > I find super documentation confusing because it uses multiple variables > that are never introduced. ISTM that you're looking for a full tutorial with fully worked worked out examples rather than English text interspersed with code snippets. Consider reading the super-considered-super post for that purpose. As for the existing text, I've wrestled with it for years and think we've hit a local optimum. Expanding the text with more steps and descriptions of each step results in documentation that causes people's eyes to glaze over and to miss the main point of each sentence. Also, remember that the documentation is factored. The descriptor tutorial is primarily about descriptors. A super() call is just one of four ways to invoke a descriptor. From a descriptor howto point-of-view, all we want to communicate is that the attribute/method search starts at the next in the mro rather than the current instance. It is not the goal of that section to fully document or discuss super(). As for the main super() docs, that is the place talk about how super works; however, it is not the job of that section to explain the rest of Python (terms like bound, unbound, etc). In a way, the only job of this section is to differentiate how ``super(A, a).x`` differs from ``a.x``. Other parts of the docs cover the general attribute lookup, C3 algorithm, method binding, etc. The use of super() is just a special case where where the search starts from the class right after the given or inferred *type* argument. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46182] `super` and descriptor clarification
Raymond Hettinger added the comment: I'm reluctant to give any more space to the least important case, one that rarely arises in practice. The text in the PR is wordy and IMO creates more confusion that it solves. Per the dev-guide, we mostly avoid "preachy" text. No, "it is recommended to avoid the single argument form". In the unlikely event that a person needs this, we are not recommending against it. It is in fact supported, tested, and mentioned in the documentation. And to the extend we care to nudge users in one direction or another, the traditional way to deemphasize a feature is spend less time and space talking about it :-) At this point, I recommend just letting it be. It feels like we're going down a rabbit hole here rather than solving problems that users actually have. These features are almost two decades old and the docs have been stable for a long time. If there were a significant communication issue here, we would have known long ago. To gain an appreciation for the challenges we face in documentation, take a look at the discussion in https://bugs.python.org/issue46173 . In the case of super(), more words don't make the docs better; it just adds more text that a user has to fight through to get the gestalt of what is going on. When I talk to advanced users of the language, they almost never think of super() in more detail than is covered in the docs; instead, they've grokked the central concept of next-in-mro and that it is commonly used in two ways either to call parent class or to implement cooperative multiple inheritance. Ideally, we want to lead readers to that same understanding. IMO, detailing the mechnanics of uncommon cases takes us in the opposite direction. -- ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Raymond Hettinger added the comment: > I believe that the behavior is so deeply ingrained in how argparse > works that it can't be changed. I think so as well. Handling arguments with a dash prefiew could be viewed as fundamental design flaw except for the fact that the module has been so successful (both before and after landing in the standard library). I've come to believe that argparse is very difficult to change without risk of breaking many existing tools that depend on argparse working exactly the way it does now. Also, this issue is over a decade old and no clear solution has emerged. > at this point installing modules from PyPI is sufficiently easy > that I'm not sure it makes sense to advocate for another command > line parser in the stdlib. I agree. It would be a hard sell at this point. Let's close this one. I don't think it is going to get solved. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Raymond Hettinger added the comment: > we should undo the deprecation of optparse in the documentation > (https://bugs.python.org/issue37103), since the stated justification > for that deprecation was that optparse will not be developed further. While optparse that it isn't being developed further, therebut will not be taken away. IIRC the reason for this was that it too had become difficult to build out and that is what necessitated the creation of argparse -- there wasn't clean way to add the desired features (subparsers, actions, etc). > If it's going to be closed, it should at least be acknowledged > that it *is* a fundamental design flaw That seems a spiteful demand. It is more correct to say that the design met its original intended goals but unfortunately the structure of the first pass scan precludes cleanly handling arguments with dashes. The limitations are noted in the docs in the section, "Arguments containing -". As Eric pointed out, there are alternative argument parsing packages available on PyPI. -- ___ Python tracker <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
New submission from Raymond Hettinger :
By default, isqrt(n) gives the floor of the exact square of n. It would be
nice to have a flag to give a rounded result:
y = isqrt(n, round=True)
Alternatively, set a mode argument to one of {'floor', 'round', 'ceil'}:
y = isqrt(n, mode='round')
I would like something better than this:
def risqrt(x):
'Big integer version of: round(sqrt(x)).'
y = isqrt(x)
s = y ** 2
return y if x <= s + y else y + 1
def cisqrt(x):
'Big integer version of: ceil(sqrt(x)).'
return isqrt(x - 1) + 1
My use case arose when building a table of square roots incorporated in
arbitrary precision functions implemented with scaled integer arithmetic:
def get_root_table(base, steps, scale):
s = []
x = round(base * scale)
for i in range(steps):
x = risqrt(x * scale)
s.append(x)
return s
--
assignee: mark.dickinson
components: Library (Lib)
messages: 409243
nosy: mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Optionally support rounding for math.isqrt()
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46187>
___
___
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: It's a little late, but I had a thought that code could be made more general, slightly faster, and much easier to understand if the popcount logic were to be replaced with a table that records how many bits of the factorial were shifted out to make it odd. from math import comb, perm, factorial as fact Modulus = 2 ** 64 Cmax = 67 Pmax = 25 Fmax = Pmax F = [] # odd factorial S = [] # shift back to factorial Finv = [] # multiplicative inverse of odd fact for n in range(Cmax+1): f = fact(n) s = (f & -f).bit_length() - 1 odd_f = (f >> s) % Modulus inv_f = pow(odd_f, -1, Modulus) assert odd_f * inv_f % Modulus == 1 assert (odd_f << s) % Modulus == f % Modulus F.append(odd_f) S.append(s) Finv.append(inv_f) def fact_small(n): return F[n] << S[n] def perm_small(n, k): return (F[n] * Finv[n-k] % Modulus) << (S[n] - S[n-k]) def comb_small(n, k): return (F[n] * Finv[k] * Finv[n-k] % Modulus) << (S[n] - S[k] - S[n-k]) assert all(fact_small(n) == fact(n) for n in range(Fmax+1)) assert all(perm_small(n, k) == perm(n, k) for n in range(Pmax+1) for k in range(0, n+1)) assert all(comb_small(n, k) == comb(n, k) for n in range(Cmax+1) for k in range(0, n+1)) -- ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: The shift table is an array of uint8_t, so it would be tiny (nearly fitting in one cache line). -- ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: Also, it would help Serhiy's divide and conquer algorithm if the fast cases included the sides of Pascal's triangle rather than just the top: if n < TableSize and k < limits[n]: return comb_small(n, k) return comb_slow(n, k) Build the table like this: TableSize = 101 limits = bytearray(TableSize) for n in range(0, TableSize): for k in range(0, n+1): if comb(n, k) != comb_small(n, k): break else: k += 1 limits[n] = k -- ___ 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
[issue46187] Optionally support rounding for math.isqrt()
Raymond Hettinger added the comment: > Sweet! New one on me Tim already knows this but for the record the derivation is isn't tricky. With y=isqrt(x), then next root is at y+1 and the half way point is y+1/2 which isn't an integer. The corresponding squares are y**2, (y+1/2)**2, and (y+1)**2. With a multiple of four, those become 4*y**2, 4*(y+1/2)**2, and 4*y+1)**2 which are equivalent to the squares of consecutive integers: (2y)**2, (2y+1)**2, and (2y+2)**2. Adding one gives the roots 2y+1, 2y+2, and 2y+3. The floor division eliminates the constant term giving the desired roots y, y+1, and y+1. > can we use the decimal module's names for the supported rounding modes? I'm not sure those make sense because we never get to exactly half. There is only floor, ceil, and round, not half_up, half_even, etc. -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46190] Omit k in random.sample()
Raymond Hettinger added the comment: If all you want is a sample where k==1, then use choice(). That is clearer and more efficient. The sample() function is for sampling without replacement which only makes sense when k > 1; otherwise, choice() or choices() is usually what you want. -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue46190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46190] Omit k in random.sample()
Raymond Hettinger added the comment: Okay. Thank for the quick response and the suggestion. I'm going to mark this one as closed. AFAICT, it distracts users from better solutions. I did a quick code search for sample(). The k==1 case is rare and in most cases the code should have used choice() or choices() instead. Accordingly, it doesn't make sense to make k==1 the default. Also, I suspect (but don't no for sure) that most users benefit by having the error message when k is omitted. That is more likely a user mistake than a correct design choice. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46190] Omit k in random.sample()
Raymond Hettinger added the comment: > My suggestion is not to set k=1 when omitted but to assign it a random value Sorry, I think that is just bizarre. Also, some populations are *very* large, so a minor user accident of omitting a parameter would result in a large unexpected output. For choices(), it would have been nice to have k default the population size (because resampling is a common use case) but we didn't go that path because of the likelihood of a large unexpected output. The same reasoning holds here a well. If you want to go down this path, I recommend making your code explicit about what it is trying to do. Something this unexpected should not be the implicit and default behavior. -- ___ Python tracker <https://bugs.python.org/issue46190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46190] Omit k in random.sample()
Raymond Hettinger added the comment: The use case isn't bizarre. But having an API where that is the default behavior would be. From the point of view of most users, such an API would be unusual and surprising (I don't know of any other random package that has such a default). -- ___ Python tracker <https://bugs.python.org/issue46190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Raymond Hettinger added the comment: > So use decimal's ROUND_CEILING, ROUND_FLOOR, and ROUND_HALF_EVEN It think is would suck to have to type those out. Sorry, I think you're headed down the path of foolish consistency with an unrelated module and a more complicated topic. What's wrong with keeping consistent the name of the existing functions: round, floor, and ceil which are self-explanatory and much better known than the decimal module constants. Also, the intent for these to be substitutable for existing code which uses round(sqrt(x)), floor(sqrt(x)), and ceil(sqrt(x)). If those are the starting point, then round, floor, and ceil are a logical progression from the existing code. It is also consistent with how the numeric tower approaches various ways of rounding. -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43639] Do not raise AttributeError on instance attribute update/deletion if data descriptor with missing __set__/__delete__ method found on its type
Raymond Hettinger added the comment: I'm going to decline this one. * It is arguable whether or not this behavior should have been designed in originally. However, changing it now is risky (as noted by Brett and Ethan). * Personally, I disagree with the notion of allowing a partial pass through. That seems hazardous and error-prone to me. It is easier to reason about data descriptors being all or nothing. I like that AttributeError is raised while still allowing me to add the missing methods if I want to explicitly define some other behavior. * This has been open for 9 months and no one else stepped forward to champion it. * For two decades, no one has complained that the current behavior got in the way of what they were trying to do. That provides some evidence that there isn't a real world problem to be solved. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43639] Do not raise AttributeError on instance attribute update/deletion if data descriptor with missing __set__/__delete__ method found on its type
Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker <https://bugs.python.org/issue43639> ___ ___ 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: - if comb(n, k) != comb_small(n, k): + if comb(n, k) != comb_small(n, k) % Modulus: -- ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: > Did you try running that? Yes. The table size was extended beyond what we have now. See attached file. -- Added file: https://bugs.python.org/file50526/comb_with_side_limits.py ___ 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
[issue37295] Possible optimizations for math.comb()
Raymond Hettinger added the comment: > I'd be happy to change the implementation to use the trailing > zero counts as suggested. Thanks. I think that is a portability win and will made the code a lot easier to explain. -- ___ 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
[issue46187] Optionally support rounding for math.isqrt()
Raymond Hettinger added the comment: > I'd similarly prefer to see recipes in the docs. Can you elaborate on why you prefer having this in the docs rather than as built-in functionality? For me, the rounded case would be the most common. I don't think I'm better-off writing a wrapper with a semi-opaque trick, having to give it a different name and having it run more slowly than built in functionality. Also as builtin, I can be assured that it is maintained, documented, and well-tested. Writing "y = isqrt(x, 'rounded')" is clear, fast, and convenient. I don't see the advantage is putting that functionality a little more out of reach. The string options have been successful elsewhere in Python. For example, str.encode() has the error modes: "strict", "ignore", and "replace" which as clear, fast, and much better than users having to write their own wrappers. -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Raymond Hettinger added the comment: So, are you going to reject my feature request? I don't understand why. Both Mark and I have had valid use cases. The implementation is straight-forward and simple. The workaround is slow and non-obvious. The default remains the same so that usability isn't impaired in any way. There is basically zero downside other that feeling icky about mode flags in general. With respect to itertools, I did add *initial* to accumulate() solely because you wanted it ;-) -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Raymond Hettinger added the comment: I'm thinking of this an a replacement example: >>> import json >>> import urllib.request >>> url = "http://worldtimeapi.org/api/timezone/America/Los_Angeles"; >>> with urllib.request.urlopen(url) as response: ... timeinfo = json.load(response) ... >>> print(timeinfo['datetime']) 2021-12-30T21:32:08.588278-08:00 -- ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Raymond Hettinger added the comment:
This is a little closer to the current code. Also it has a simpler and more
universal url.
from urllib.request import urlopen
url = 'http://worldtimeapi.org/api/timezone/etc/UTC.txt'
with urlopen(url) as request:
for line in request:
line = line.decode('utf-8')
if line.startswith('datetime'):
print(line)
datetime: 2021-12-31T08:23:15.083004+00:00
--
___
Python tracker
<https://bugs.python.org/issue46079>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25478] Consider adding a normalize() method to collections.Counter()
Raymond Hettinger added the comment: Withdrawing the suggestions for scaled_to() and scaled_by(). Am thinking that people are mostly better off with a dict comprehension where they can control the details of rounding and type conversions. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue25478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45670] New .mapping attribute is broken for some existing uses of dict views
Raymond Hettinger added the comment: To the list of four options I suggested for bidict, you can add one more. Create a feature request for a C implementation of collections.abc.KeyView. ISTM that your core issue is that bidict won't use the intended and guaranteed solution because the KeysView ABC is thought to be too slow (you should test this -- the `yield from self._mapping` code is very fast). > .mapping attribute in Python 3.10+ now leaking internal state. We do not agree on this essential point. The "leak", as in "all abstractions are leaky", is in the bidict code, not in the dict_keys code. The .mapping attribute itself is accurately refers to its underlying mapping. This is consistent with how other wrappers provide a __wrapped__ attribute (or __fget__, __func__, func, maps, etc). If some class ever uses an lru_cache, cache, property, boundmethod, partial object, or chainmap, then it is possible for the user to unwrap one level of abstraction. > Now suppose a new .mapping attribute were added to dict_keyiterator objects > in a future version of Python We don't do that for iterator objects. If we did, then ChainMap would have the same options as bidict has. Most likely, we would leave it as an undocumented, non-guaranteed implementation detail (much like random.randrange is a bound method with a __func__ attribute rather than an actual function). If we thought users really cared about the exact object returned and its full API, then we would have several options: 1) Document that that aspect of the API is non-guaranteed, 2) Document that that aspect is guaranteed. This would lock in our design choice forever, but all allow users the opportunity to exploit the new capability. 3) Wrap the iterator to hide parts of the API we don't want to expose. For example, return `chain(d)` instead of `iter(d)`. > I even have the passing property-based tests to prove it That tests an invented property that isn't true and wasn't ever intended to be true: "The API of the concrete dict_keys type is the same as the API of KeysView ABC". The correct property is: "The API of the concrete dict_keys type implements the KeysView ABC but may do other things as well". This is the common and normal relationship between ABCs and concrete classes. It is no more surprising that Mapping not supporting __or__ while dict does. > I also have counterpoints for your other feedback, I fear that we have an asymmetry of time available to explore every possible nuance including the counterfactual you gave in the last post. Doing so eats heavily into my limited time available for development. I don't think there is more that can be done here. We already have an official and supported API for your purpose. The dict_keys concrete API is unlikely to ever be built-out as a general purpose optimization of the KeysView ABC (that violates a number of design principles regarding separation of concerns, tight coupling, premature optimization, and the proper relationship between concrete and abstract classes). Please consider using one of the four options (now up to five) that I suggested previously. -- ___ Python tracker <https://bugs.python.org/issue45670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Change by Raymond Hettinger : -- keywords: +patch pull_requests: +28532 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30315 ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46095] Improve SeqIter documentation
Change by Raymond Hettinger : -- keywords: +patch pull_requests: +28533 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30316 ___ Python tracker <https://bugs.python.org/issue46095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Raymond Hettinger added the comment: New changeset ac4eea21722d9ed1604c9c30a8d29ae2ce74f1b2 by Raymond Hettinger in branch 'main': bpo-46079: Replace external link that is down for maintenance. (GH-30315) https://github.com/python/cpython/commit/ac4eea21722d9ed1604c9c30a8d29ae2ce74f1b2 -- ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Raymond Hettinger added the comment: New changeset 2bd73546959619b2519a7a830b3aaf190abeaf78 by Miss Islington (bot) in branch '3.10': bpo-46079: Replace external link that is down for maintenance. (GH-30315) (GH-30328) https://github.com/python/cpython/commit/2bd73546959619b2519a7a830b3aaf190abeaf78 -- ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Raymond Hettinger added the comment: New changeset 72ffcb02f3ea6efcd3afe368996dc3ee89701898 by Miss Islington (bot) in branch '3.9': bpo-46079: Replace external link that is down for maintenance. (GH-30315) (GH-30329) https://github.com/python/cpython/commit/72ffcb02f3ea6efcd3afe368996dc3ee89701898 -- ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46079] [doc] Broken URL in "Brief Tour of the Standard Library"
Change by Raymond Hettinger : -- priority: low -> normal resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46095] Improve SeqIter documentation
Raymond Hettinger added the comment: New changeset a09bc3a404befca197b5d9959a9c62110ee61d77 by Raymond Hettinger in branch 'main': bpo-46095: Improve SeqIter documentation. (GH-30316) https://github.com/python/cpython/commit/a09bc3a404befca197b5d9959a9c62110ee61d77 -- ___ Python tracker <https://bugs.python.org/issue46095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46095] Improve SeqIter documentation
Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46095] Improve SeqIter documentation
Raymond Hettinger added the comment: New changeset e9783d6434f28dfb0b531c6760f7642fc7ede278 by Miss Islington (bot) in branch '3.10': bpo-46095: Improve SeqIter documentation. (GH-30316) (GH-30330) https://github.com/python/cpython/commit/e9783d6434f28dfb0b531c6760f7642fc7ede278 -- ___ Python tracker <https://bugs.python.org/issue46095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46224] doc: Fix bisect example using mutable function default
Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker <https://bugs.python.org/issue46224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46224] doc: Fix bisect example using mutable function default
Raymond Hettinger added the comment: I'm going to decline this one. It seems that you're applying a stylistic guideline to a case where it isn't needed and where it doesn't improve the example. In this case, the example doesn't mutate the input, so the code is correct. It has some benefit in that it communicates to the user of the function that lists are allowable as an input (which is the norm for bisect). And the tooltips will show the relationship between the grades can the cutpoints. Also, this isn't library code. A bisect example needs to focus on bisect rather than other concerns. This isn't the place to talk about the pattern of setting a default to None and then filling it in in the body of the code. Likewise, we wouldn't use this example to communicate / and * for positional-only and keyword-only args. Nor do we have a docstring or type signature. Instead, it shows how to write a lookup function using bisect() and that is all we want. Lastly, I'll note this example has been present for a long time and has proven itself effective in teaching people how bisect works. In particular, we want to make it obvious the relationship between the 5 grades and the 4 cut points. -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46228] argparse docs: default for prog= in ArgumentParser() should be basename of argv[0], not argv[0], to match behaviour
Raymond Hettinger added the comment: Thank you for the PR. -- nosy: +rhettinger resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Raymond Hettinger added the comment: > divmod() allows easy emulation of any division rounding mode It could be used that way, but generally isn't. Please consider my original request. Adding a keyword argument is easy, clear, and has almost no mental overhead. It reads very well in code, `y = isqrt(x, 'ceil')` or `y = isqrt(x, 'round')`. The equivalents with isqrt_rem are awkward and don't read well (reminding me of my Fortran days). -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Raymond Hettinger added the comment: I don't think this is a door we should open: >>> Fraction(3.5, 2.5) Fraction(7, 5) This currently raises a useful exception: TypeError: both arguments should be Rational instances That is especially helpful in avoiding cases like this: >>> Fraction(1.1, 3.3) Fraction(2476979795053773, 7430939385161318) If that output is desired, the two conversions should be explicit. >>> Fraction(1.1) / Fraction(3.3) Fraction(2476979795053773, 7430939385161318 I recommend rejecting this feature request as being more likely to be hazardous than helpful. -- ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46182] `super` and descriptor clarification
Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46257] Convert statistics sum of squares to a single pass algorithm
New submission from Raymond Hettinger : The existing code makes two passes, one to compute the mean and another to compute the sum of squared differences from the mean. A consequence of making two passes is that iterator inputs must be converted to a list before processing. This throws away the memory saving advantages of iterators. The ostensible reason for the two pass code is that the single pass variant is numerically unstable when implemented with floating point accumulators. However, this code uses fractions throughout, so the accumulation is exact. Changing to a single pass saves memory, doubles the speed, and simplifies the upstream code in variance(), pvariance(), stdev(), and pstdev(). -- components: Library (Lib) messages: 409692 nosy: rhettinger, steven.daprano priority: normal severity: normal status: open title: Convert statistics sum of squares to a single pass algorithm type: performance versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46257] Convert statistics sum of squares to a single pass algorithm
Change by Raymond Hettinger : -- keywords: +patch pull_requests: +28611 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30403 ___ Python tracker <https://bugs.python.org/issue46257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46259] float formatting error?
Raymond Hettinger added the comment: The two numbers you gave become the same when rounded to the limited internal precision used by floats. >>> 1.12345678901234 == 1.123456789011 True When it comes to displaying the number, Python tries to show the shortest possible member of the equivalence class. -- nosy: +rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46257] Convert statistics sum of squares to a single pass algorithm
Raymond Hettinger added the comment: New changeset 43aac29cbbb8a963a22c334b5b795d1e43417d6b by Raymond Hettinger in branch 'main': bpo-46257: Convert statistics._ss() to a single pass algorithm (GH-30403) https://github.com/python/cpython/commit/43aac29cbbb8a963a22c334b5b795d1e43417d6b -- ___ Python tracker <https://bugs.python.org/issue46257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46257] Convert statistics sum of squares to a single pass algorithm
Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Raymond Hettinger added the comment: I don't think these were intended to be public. like "January" and "February", they were for internal use. Presumably, this is because the names vary across languages. In the absence of some demonstrated user need, we should leave this alone. -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Change by Raymond Hettinger : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Raymond Hettinger added the comment: > The problem is they are documented here: > https://docs.python.org/3/library/calendar.html#calendar.setfirstweekday Well, that does make them public, so we have to go forward. -- resolution: rejected -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46270] Comparison operators in Python Tutorial 5.7
Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46272] Fix bitwise and logical terminology in python.gram
New submission from Raymond Hettinger : In the section "Comparison operators", all mentions of "bitwise" should be "binary". The section "Logical operators" should be retitled "Bitwise operators". See: https://docs.python.org/3/reference/expressions.html#binary-bitwise-operations -- assignee: pablogsal components: Documentation messages: 409796 nosy: pablogsal, rhettinger priority: normal severity: normal status: open title: Fix bitwise and logical terminology in python.gram versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46270] Comparison operators in Python Tutorial 5.7
Raymond Hettinger added the comment: It may seem weird, but a "membership operator" is a kind of "comparison operator".¹ They can even participate in chaining, 'a < b in s < c` is equivalent to `(a < b) and (b in s) and (b < c)`. I'm propose this new wording to mention the concept of "membership": "The comparison operators `in` and `not in` are membership tests that determine whether a value is in (or not in) a container." ¹ https://docs.python.org/3/reference/expressions.html#comparisons -- ___ Python tracker <https://bugs.python.org/issue46270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Raymond Hettinger added the comment: New changeset e5894ca8fd05e6a6df1033025b9093b68baa718d by Nikita Sobolev in branch 'main': bpo-46266: Add calendar day of week constants to __all__ (GH-30412) https://github.com/python/cpython/commit/e5894ca8fd05e6a6df1033025b9093b68baa718d -- ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Raymond Hettinger added the comment: Thanks for the PR. Sorry that I missed the one public reference in the docs. -- resolution: -> fixed status: open -> closed versions: -Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46270] Comparison operators in Python Tutorial 5.7
Raymond Hettinger added the comment: Container is correct. Containers are defined as being anything that supports the "in" and "not in" operators. That includes sequences (str, list, tuple, bytes, bytearray), mappings (dict, ChainMap, defaultdict), and sets (frozenset and set). It doesn't matter that the word container comes up later. At this point in the tutorial we tend to have a number of forward or references. Our tutorial is more a guided walkthrough with examples rather than a series of sequential definitions. -- ___ Python tracker <https://bugs.python.org/issue46270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46272] Fix bitwise and logical terminology in python.gram
Raymond Hettinger added the comment:
> comparison::= or_expr (comp_operator or_expr)*
So, the meaning of these names like this is, "lt followed by an optional
bitwise_or expression"?
compare_op_bitwise_or_pair[CmpopExprPair*]:
| eq_bitwise_or
| noteq_bitwise_or
| lte_bitwise_or
| lt_bitwise_or
| gte_bitwise_or
| gt_bitwise_or
| notin_bitwise_or
| in_bitwise_or
| isnot_bitwise_or
| is_bitwise_or
eq_bitwise_or[CmpopExprPair*]: '==' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
Eq, a) }
noteq_bitwise_or[CmpopExprPair*]:
| (tok='!=' { _PyPegen_check_barry_as_flufl(p, tok) ? NULL : tok})
a=bitwise_or {_PyPegen_cmpop_expr_pair(p, NotEq, a) }
lte_bitwise_or[CmpopExprPair*]: '<=' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
LtE, a) }
lt_bitwise_or[CmpopExprPair*]: '<' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
Lt, a) }
gte_bitwise_or[CmpopExprPair*]: '>=' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
GtE, a) }
gt_bitwise_or[CmpopExprPair*]: '>' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
Gt, a) }
notin_bitwise_or[CmpopExprPair*]: 'not' 'in' a=bitwise_or {
_PyPegen_cmpop_expr_pair(p, NotIn, a) }
in_bitwise_or[CmpopExprPair*]: 'in' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
In, a) }
isnot_bitwise_or[CmpopExprPair*]: 'is' 'not' a=bitwise_or {
_PyPegen_cmpop_expr_pair(p, IsNot, a) }
is_bitwise_or[CmpopExprPair*]: 'is' a=bitwise_or { _PyPegen_cmpop_expr_pair(p,
Is, a) }
--
___
Python tracker
<https://bugs.python.org/issue46272>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment: #244 is a false positive. The value of new_state[i] on line 454 was initialized on line 442 with: new_state[i] = (uint32_t)element. #387 is also a false positive. There is an assertion on the previous line that the item != NULL. That assertion passes because item is the result of a call to deque_popleft() which only returns NULL when the size is zero; however, deque_del_item() is not ever called with size 0 and it has an assertion to that effect. The two callers are deque_remove() and deque_ass_item(). Both calls are guarded by regular tests (not assertions) so that they are only called when the index >= 0 and index < len(deque). -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue46280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment:
#324 and #325 are false positives. The result variable is initialized in the
preceding lines:
if (len_a == length) {
left = *((volatile const unsigned char**)&a);
result = 0;
}
if (len_a != length) {
left = b;
result = 1;
}
While the code is correct, the second test should be changed to "else".
--
___
Python tracker
<https://bugs.python.org/issue46280>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment:
#382 is false positive. The "iterable" variable is only accessed when known to
not be NULL.
# Line 970
if (iterable != NULL) {
if (set_update_internal(so, iterable)) {
Py_DECREF(so);
return NULL;
}
}
--
___
Python tracker
<https://bugs.python.org/issue46280>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment:
#420 and #421 are false positives. The value of "c" is initialized a few lines
before use.
for (;;) {
c = tok_nextc(tok);
...
}
...
tok_backup(tok, c);
if (c == '#' || c == '\n' || c == '\\') {
...
}
--
___
Python tracker
<https://bugs.python.org/issue46280>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment: The dead store notices for all the DISPATCH calls in ceval.c are false positives. The "oparg" value is used in many of the case statements. The dead store notices the clinic generated code all relate to "!--noptargs" which is sometimes used in generated code and sometimes not. By always making the assignment, the clinic generator code is made less stateful (I would say "simpler" but that part of clinic.py is a mess). -- ___ Python tracker <https://bugs.python.org/issue46280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment:
#511 and #512 are false positives. The "kind" variable is indeed uninitialized
in the bytes_writer case:
else if (bytes_writer) {
*bytes_str = _PyBytesWriter_Prepare(bytes_writer, *bytes_str, strlen);
if (*bytes_str == NULL) {
Py_DECREF(scratch);
return -1;
}
}
However, the flagged sections cannot be called in the bytes_writer case:
if (bytes_writer) { <=="kind" not used here
char *p = *bytes_str + strlen;
WRITE_DIGITS(p);
assert(p == *bytes_str);
}
else if (kind == PyUnicode_1BYTE_KIND) { <== bytes_write is false
Py_UCS1 *p;
WRITE_UNICODE_DIGITS(Py_UCS1);
}
else if (kind == PyUnicode_2BYTE_KIND) { <== bytes_write is false
Py_UCS2 *p;
WRITE_UNICODE_DIGITS(Py_UCS2);
}
else {
Py_UCS4 *p;
assert (kind == PyUnicode_4BYTE_KIND);
WRITE_UNICODE_DIGITS(Py_UCS4);
}
--
___
Python tracker
<https://bugs.python.org/issue46280>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment: #533, #534, #535, and #536 are false positives for the same reason as #511 and #512. The two "dead stores" in 533 and 534 match the "uninitialized variables" in 535 and 536. -- ___ Python tracker <https://bugs.python.org/issue46280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46280] About vulnerabilities in Cpython native code
Raymond Hettinger added the comment: #584 and #585: The code is correct but there are dead stores only when the asserts are turned off: 2635. carry = v_lshift(w->ob_digit, w1->ob_digit, size_w, d); 2636. assert(carry == 0); Elsewhere we use ifdefs around code like this to suppress warnings about unused variables. In this case though, it would be messy and cause code duplication. -- ___ Python tracker <https://bugs.python.org/issue46280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
