There's a long time issue of trying to differentiate mappings and sequences
in the C-API in a fast and reliable way.
Due to recent changes, we might be able to do so at last, by checking
tp_flags + str/bytes/bytearray which are considered unique.
This might be a breaking change in the Stable ABI
On Fri, Jan 14, 2022 at 9:50 AM Mark Dickinson wrote:
> On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote:
>
>> Division may still be problematic.
>>
>
> On that note: Python divisions are somewhat crippled even on x64. Assuming
> 30-bit digits, the basic building block that's needed for
Hi there,
before we begin the usual round of release notes, please do note that the three
new versions of Python released today do not contain Windows installers yet.
This is temporary, due to a more complex than expected code signing certificate
renewal.
We’ve held the releases all week while
]Mark Dickinson ]
>> Division may still be problematic.
Heh. I'm half convinced that heavy duty bigint packages are so often
written in assembler because their authors are driven insane by trying
to trick C compilers into generating "the obvious" machine
instructions needed.
An alternative to HW
ACTIVITY SUMMARY (2022-01-07 - 2022-01-14)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7202 ( +3)
closed 50906 (+81)
total 58108 (+84)
Open issues
On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote:
> Division may still be problematic.
>
On that note: Python divisions are somewhat crippled even on x64. Assuming
30-bit digits, the basic building block that's needed for multi-precision
division is a 64-bit-by-32-bit unsigned integer
On 13. 01. 22 16:23, Matthew Rahtz wrote:
Thanks for this feedback, Petr!
*First point (indexing assignment)*
Great catch; we hadn't thought about this. I agree it would be better to
keep these in sync.
I just tested this in our current CPython implementation, and can
confirm it looks like
*First point (indexing assignment)*
[Guido]
> Agreed. I just misremembered this, my bad! Please do the clarification
etc.
Will do.
*Second point (multiple TypeVarTuples)*
[Guido]
> I would love it for the cases where it's *not* ambiguous to just work
(once type checkers support it). I'd like
Yes, exactly.
Specifically, the "wrong" example in section 'Multiple Type Variable
Tuples: Not Allowed' suggests that maybe what is wrong is that `Generic`
was given more than one unpacked type variable tuple. The actual problem
is a consequence of that: `class Array` has more than one type
[Matthew]
> 1. The wording of the 'Multiple Type Variable Tuples: Not Allowed'
section - you're saying that we're being a bit imprecise here in saying
that we disallow multiple TypeVarTuples in a type parameter list, given
that in e.g. `def f(x: *Ts1, y: *Ts2)`, both Ts1 and Ts2 are members of
10 matches
Mail list logo
