Change by Berry Schoenmakers :
--
keywords: +patch
pull_requests: +22889
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24055
___
Python tracker
<https://bugs.python.org/issu
New submission from Berry Schoenmakers :
The async REPL introduced in Python 3.8 is very nice for quick tests and
experiments, supporting top-level "await" (see
https://bugs.python.org/issue37028). I'm using it often when developing code
that heavily relies on Python'
Berry Schoenmakers added the comment:
Maybe a use case in this direction: int(x, base=10).
Because, if you type
int(x='3', base=12)
you get
TypeError: 'x' is an invalid keyword argument for int()
and x needs to be a positional-only to p
Berry Schoenmakers added the comment:
There seems to be a slight mixup with the built-in pow() function in Python
3.8.2.
Currently, under https://docs.python.org/3/library/functions.html#pow it says:
Changed in version 3.9: Allow keyword arguments. Formerly, only
positional
Berry Schoenmakers added the comment:
Well, I'm basically using a run method defined as a shorthand for
self.loop.run_until_complete (without closing loop, reusing it throughout). It
would be nice if asyncio.run could simply be used instead, but I understand
you're saying this
Berry Schoenmakers added the comment:
The current implementation of asyncio.run() is focused quite a bit on one-shot
use. After the call returns, the default event loop is even gone: calling
asyncio.get_event_loop() gives "RuntimeError: There is no current event loop in
thread '
Berry Schoenmakers added the comment:
In pure Python this seems to be the better option to compute inverses:
def modinv(a, m): # assuming m > 0
b = m
s, s1 = 1, 0
while b:
a, (q, b) = b, divmod(a, b)
s, s1 = s1, s - q * s1
if a != 1:
raise ValueEr
Berry Schoenmakers added the comment:
> Is there a clear reason for your expectation that the xgcd-based algorithm
> should be faster?
Yeah, good question. Maybe I'm assuming too much, like assuming that it should
be faster;) It may depend a lot on the constants indeed, but ult
Berry Schoenmakers added the comment:
> ... to see `pow(a, p-2, p)` beat a pure Python xgcd for computing the inverse.
OK, I'm indeed assuming that modinv() is implemented efficiently, in CPython,
like pow() is. Then, it should be considerably faster, maybe like this:
>>&
Berry Schoenmakers added the comment:
Agreed, extending pow(value, n, modulus) to negative n would be a great
addition!
To have modinv(value, modulus) next to that also makes a lot of sense to me, as
this would avoid lots of confusion among users who are not so experienced with
modular
Berry Schoenmakers added the comment:
I had the same reservations but after rethinking it several times concluded
that the modulus argument would fit really well.
Indeed, Mathematica doesn't support the Modulus option for the Product[]
function. But they don't even support it for
New submission from Berry Schoenmakers :
It's nice to see the arrival of the prod() function, see PR11359.
Just as for the built-in pow(x, y[, z]) function it would be very useful to
have an optional argument z for computing integer products modulo z. Typical
use case in cryptography
Berry Schoenmakers added the comment:
Thanks for the suggestion, Mark.
I was not so sure, and the Nosy List for this issue is already quite extensive,
so considered you guys as an appropriate audience for my first comment on this
platform.
But I will also look into opening a separate issue
Berry Schoenmakers added the comment:
Nice to see the arrival of the prod() function.
Just as for the built-in pow(x, y[, z]) function it would be very useful to
have an optional argument z for computing products modulo z. Typical use case
in cryptography would be:
prod((pow(x, y, z) for x
14 matches
Mail list logo
