On Thu, 14 Oct 2021 04:24:30 -0500
Eryk Sun wrote:
>
> > Note that PyNumber_Long() is now the only place inside the interpreter
> > calling the `nb_int` slot. But since it also has those undesirable code
> > paths accepting str and buffer-like objects, it's usable in fewer
> > situations than
On Wed, 13 Oct 2021 17:00:49 -0700
Guido van Rossum wrote:
> On Wed, Oct 13, 2021 at 4:56 PM Victor Stinner wrote:
>
> > Honestly, I don't understand well the difference between __int__() and
> > __index__().
> >
> > * https://docs.python.org/dev/reference/datamodel.html#object.__int__
> > *
On 10/14/21, Antoine Pitrou wrote:
> On Wed, 13 Oct 2021 17:00:49 -0700
> Guido van Rossum wrote:
>>
>> so int() can't call __trunc__ (as was explained earlier in
>> the thread).
I guess this was meant to be "*just* call __trunc__". It's documented
that the int constructor calls the
14.10.21 12:24, Eryk Sun пише:
> Maybe an alternate constructor could be added -- such as
> int.from_number() -- which would be restricted to calling __int__(),
> __index__(), and __trunc__().
See thread "More alternate constructors for builtin type" on Python-ideas:
Hello,
I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/) since
it was first proposed for Python 3.8. It's been deferred for some time and I'm
interested in seeing it in Python 3.11, but I know there were also a number of
objections which resulted in it being deferred
Thanks -- this is the kind of work that helps a PEP get accepted. I am
personally in favor of accepting PEP 505, and I hope that your work and the
discussion that will undoubtedly follow here will help convince the
Steering Council to accept it.
--Guido
On Thu, Oct 14, 2021 at 10:38 AM Doug
Oops, sorry for the slow reply - I'm not subscribed to this mailing list.
As Mehdi2277 says, this would indeed require the Map operator we'll introduce
in a future PEP.
But that's a good point about the `*Tuple[int, Ts]` syntax. I think the
interpretation of it that would be most consistent
I tried to implement this in CPython by modifying a downloaded source code, but
I can't seem to fix the problem of the "maybe" operators segfaulting when being
used with literal immutables. The maybe-assign/coalesce operators were
implemented successfully though.
Hello Doug,
On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding
Can you elaborate on that? Obviously it is not always appropriate to use
None, but I've never
Steven D'Aprano wrote:
> Hello Doug,
> On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> > I believe strong and valid arguments can be made about the use of None
> > being a fundamental flaw in some types of coding
> > Can you elaborate on that? Obviously it is not always appropriate
10 matches
Mail list logo
