[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

Change by theeshallnotknowethme : -- pull_requests: +28854 pull_request: https://github.com/python/cpython/pull/30653 ___ Python tracker <https://bugs.python.org/issue46

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

theeshallnotknowethme added the comment: Also how would it be implemented? in terms of a PyLongObject or just a uint64_t? -- ___ Python tracker <https://bugs.python.org/issue46

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

theeshallnotknowethme added the comment: > Another option to consider would be a table lookup of a pre-computed table of > [1 << i for i in range(64)]. Does it have a significantly better performance compared to not having a t

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

Change by theeshallnotknowethme : -- type: -> performance ___ Python tracker <https://bugs.python.org/issue46407> ___ ___ Python-bugs-list mailing list Un

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +28831 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30628 ___ Python tracker <https://bugs.python.org/issu

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

theeshallnotknowethme added the comment: Note that `n` should not be over PY_SSIZE_T_MAX, else an error should occur. -- ___ Python tracker <https://bugs.python.org/issue46

[issue46407] optimizing `1 << n` or `2 ** n` and modulo-only operations

New submission from theeshallnotknowethme : Optimize calculating powers of 2 for integers. Does not include optimizing modular exponentiation because benchmarking shows current version of modular exponentiation is faster. Also optimizes any call with the structure `l_divmod(a, b, NULL, &

[issue46078] `ast.unparse` fails on `class C: i: int`… convert broken from `ast.AnnAssign` to `ast.Assign`

theeshallnotknowethme added the comment: This seems like just a problem of your library instead of a problem with Python. Are you sure this is the right place you're in? -- nosy: +February291948 ___ Python tracker <https://bugs.py

[issue45984] Error messages for invalid string prefixes and potential attribute accesses

theeshallnotknowethme added the comment: Can I know the reason for rejection? -- ___ Python tracker <https://bugs.python.org/issue45984> ___ ___ Python-bug

[issue45984] Error messages for invalid string prefixes and potential attribute accesses

Change by theeshallnotknowethme : -- resolution: -> rejected ___ Python tracker <https://bugs.python.org/issue45984> ___ ___ Python-bugs-list mailing list Un

[issue45984] Error messages for invalid string prefixes and potential attribute accesses

Change by theeshallnotknowethme : -- resolution: rejected -> ___ Python tracker <https://bugs.python.org/issue45984> ___ ___ Python-bugs-list mailing list Un

[issue45984] Error messages for invalid string prefixes and potential attribute accesses

theeshallnotknowethme added the comment: I actually didn't know bpo-45982 existed. -- ___ Python tracker <https://bugs.python.org/issue45984> ___ ___ Pytho

[issue45984] Error messages for invalid string prefixes and potential attribute accesses

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +28142 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29916 ___ Python tracker <https://bugs.python.org/issu

[issue45984] Error messages for invalid string prefixes and potential attribute accesses

New submission from theeshallnotknowethme : In the current version of CPython, this code: if datetime.now()strftime(...) != "19:50:00": return produces this error: File "", line 4 if datetime.now()strftime(...) != "19:50:00": return

[issue45907] Optimize literal comparisons and contains

theeshallnotknowethme added the comment: List and sets as right operands in literal contains are optimized to constant tuples and frozensets, and I'd like to take this optimization a step further. -- ___ Python tracker <https://bugs.py

[issue45907] Optimize literal comparisons and contains

theeshallnotknowethme added the comment: If this bug report isn't accepted, for how long would the TODO remain in `Python/ast_opt.c`? -- ___ Python tracker <https://bugs.python.org/is

[issue45907] Optimize literal comparisons and contains

theeshallnotknowethme added the comment: It doesn't seem to make sense why other operations on literals are optimized but these particular ones aren't optimized (much). -- ___ Python tracker <https://bugs.python.o

[issue45907] Optimize literal comparisons and contains

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +28042 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29810 ___ Python tracker <https://bugs.python.org/issu

[issue45907] Optimize literal comparisons and contains

New submission from theeshallnotknowethme : Most operations with literals are optimized as well, so why shouldn't the comparison/contain operators be? I created a new bug report for it because of this fact and the TODO in the `fold_compare` function in `Python/ast_

[issue45759] Improve error messages for non-matching `elif`/`else` statements

Change by theeshallnotknowethme : -- pull_requests: +28012 pull_request: https://github.com/python/cpython/pull/29775 ___ Python tracker <https://bugs.python.org/issue45

[issue45843] Optimizing constant comparisons/contains

Change by theeshallnotknowethme : -- title: Optimizing LOAD_CONST followed by COMPARE_OP (or IS_OP) -> Optimizing constant comparisons/contains ___ Python tracker <https://bugs.python.org/issu

[issue45843] Optimizing LOAD_CONST followed by COMPARE_OP (or IS_OP)

theeshallnotknowethme added the comment: Above tested using `timeit.main`. -- ___ Python tracker <https://bugs.python.org/issue45843> ___ ___ Python-bugs-list m

[issue45843] Optimizing LOAD_CONST followed by COMPARE_OP (or IS_OP)

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +27870 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29639 ___ Python tracker <https://bugs.python.org/issu

[issue45843] Optimizing LOAD_CONST followed by COMPARE_OP (or IS_OP)

New submission from theeshallnotknowethme : Result of `255581293 > 12938373 and 113314 < 2`: Unoptimized: 500 loops, best of 5: 42.6 nsec per loop Optimized: 2000 loops, best of 5: 14.4 nsec per loop -- components: Interpreter Core messages: 406582 nosy: February291948 pr

[issue45816] Python does not support standalone MSVC v143 (VS 2022) Build Tools

theeshallnotknowethme added the comment: Rephrasing: Python does not support building with standalone MSVC v143 Build Tools, which is the version of MS Build Tools under Visual Studio 2022 (version 17.0). Visual Studio 2022 is the latest stable release of Visual Studio [1]. [1] https

[issue45816] Python does not support building with Visual Studio 2022

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +27821 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29577 ___ Python tracker <https://bugs.python.org/issu

[issue45816] Python does not support building with Visual Studio 2022

New submission from theeshallnotknowethme : Python does not support building with Visual Studio 2022, which is the latest officially released stable version [1]. [1] https://devblogs.microsoft.com/visualstudio/visual-studio-2022-now-available/ -- components: Build messages: 406405

[issue45759] Improve error messages for non-matching `elif`/`else` statements

Change by theeshallnotknowethme : -- pull_requests: +27765 pull_request: https://github.com/python/cpython/pull/29513 ___ Python tracker <https://bugs.python.org/issue45

[issue45759] non-matching `elif`/`else` statements with uninformative errors

theeshallnotknowethme added the comment: I'd like to expand this to more than just `elif`/`else statements inside `if` statement blocks and make an error for other cases as well. I currently have a PR that has a general error to accommodate those cases. -- title: `elif` insid

[issue45760] Remove "PyNumber_InMatrixMultiply"

theeshallnotknowethme added the comment: Also with this, could anyone also remove the unused `VISIT_SLICE` macro in 'Python/compile.c'? Thanks. -- nosy: +February291948 ___ Python tracker <https://bugs.python.o

[issue45759] `elif` inside `if` block is a `SyntaxError`

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +27732 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29481 ___ Python tracker <https://bugs.python.org/issu

[issue45759] `elif` inside `if` block is a `SyntaxError`

New submission from theeshallnotknowethme : While fixing errors in a program, I encountered this: if a == b + 2: c = sqrt(b) + a**2 elif a == b + 3: SyntaxError: Invalid syntax It should be giving an `IndentationError` or a better error message at least

[issue45736] 2to3 does not support integer division fixing

Change by theeshallnotknowethme : -- versions: -Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45736> ___ ___ Python-bugs-list mailin

[issue45736] 2to3 does not support integer division fixing

Change by theeshallnotknowethme : -- versions: +Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45736> ___ ___ Python-bugs-list mailin

[issue45736] 2to3 does not support integer division fixing

theeshallnotknowethme added the comment: A correction to the discussion: The PR I made only fixes CONSTANT integer division, not any other. The left and right operands are checked for non-constants and then are checked for integerness (specifically checks for `NOT A FLOAT`s). After both

[issue45736] 2to3 does not support integer division fixing

theeshallnotknowethme added the comment: I have put some effort to make it work for constant integers. So this x = a ** 3 / 7 would not be changed, since it refers to a name whose value is not known. -- ___ Python tracker <ht

[issue45736] 2to3 does not support integer division fixing

theeshallnotknowethme added the comment: When 2to3 supports integer division fixing, there would be this behaviour: - x = 2 ** 8 / 5 / 7 + x = 2 ** 8 // 5 // 7 Basically convert any integer division to floor division. The PR I made only works for constant integers, and any improvement would

[issue45736] 2to3 does not support integer division fixing

Change by theeshallnotknowethme : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue45736> ___ ___ Python-bugs-list mailing list Un

[issue45736] 2to3 does not support integer division fixing

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +27694 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29440 ___ Python tracker <https://bugs.python.org/issu

[issue45736] 2to3 does not support integer division fixing

New submission from theeshallnotknowethme : Right now, 2to3 does not support integer division fixing. Supposing `test.py` is a file with these contents: x = 2 ** 8 / 5 / 7 Here's an example: C:\Users\admin> py -m lib2to3 test.py RefactoringTool: Skipping optional fixer: buffer Refacto

[issue45499] from __future__ import annotations is not mandatory in 3.11.0a1+

theeshallnotknowethme added the comment: test case: >>> a: A = 'test' Traceback (most recent call last): File "", line 1, in NameError: name 'A' is not defined. Did you mean: 'a'? -- ___ Py

[issue45499] from __future__ import annotations is not mandatory in 3.11.0a1+

New submission from theeshallnotknowethme : >>> import sys >>> import __future__ >>> __future__.annotations _Feature((3, 7, 0, 'beta', 1), (3, 11, 0, 'alpha', 0), 16777216) >>> sys.version_info sys.version_info(major=3, minor=11, micro

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

theeshallnotknowethme added the comment: *interpreter. -- ___ Python tracker <https://bugs.python.org/issue45202> ___ ___ Python-bugs-list mailing list Unsub

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

theeshallnotknowethme added the comment: Reverting the effects of 'from __future__ import barry_as_FLUFL' without exiting the compiler. -- ___ Python tracker <https://bugs.python.o

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

Change by theeshallnotknowethme : -- components: +Interpreter Core, Parser nosy: +lys.nikolaou, pablogsal ___ Python tracker <https://bugs.python.org/issue45

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

Change by theeshallnotknowethme : -- versions: -Python 3.10 ___ Python tracker <https://bugs.python.org/issue45202> ___ ___ Python-bugs-list mailing list Unsub

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

Change by theeshallnotknowethme : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue45202> ___ ___ Python-bugs-list mailing list Unsub

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

Change by theeshallnotknowethme : -- keywords: +patch pull_requests: +26762 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28349 ___ Python tracker <https://bugs.python.org/issu

[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

New submission from theeshallnotknowethme : Add a flag named 'CO_FUTURE_REVOLT_AND_REMOVE_BARRY_FROM_BDFL' assigned to `0x200` that can be activated with 'from __future__ import remove_barry_from_BDFL'. Reverts the effects of 'from __future__ import bar

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

New submission from theeshallnotknowethme : When I tried using `isinstance` with a type (e.g. `bool`) as the 1st argument and a parameterized generic in a tuple (e.g. '(`bool`, `list[bool]`)') as the 2nd argument, it raised a `TypeError`, 'isinstance() argument 2 cannot be a