On Sun, Oct 24, 2021 at 6:03 AM Bluenix wrote:
>
> Hmm, I thought I responded to this on Gmail but it hasn't appeared here on
> the archive so I'll send it again..
>
> Is it known how much more/less the annotations impact performance compared to
> function defaults?
>
Basically, PEP 563
Hmm, I thought I responded to this on Gmail but it hasn't appeared here on the
archive so I'll send it again..
Is it known how much more/less the annotations impact performance compared to
function defaults?
--
Blue
___
Python-Dev mailing list --
On Sat, 2021-10-23 at 12:25 -0300, Joannah Nanjekye wrote:
> I remembered this issue on bpo with contracting opinions from when I first
> looked in 2019.
>
> See https://bugs.python.org/issue33439
Hi,
This script is currently not written in Python and hardcodes paths that are
incorrect on
On Sun, Oct 24, 2021 at 12:35 AM Marc Mueller wrote:
>
> > Bear in mind that these last ones are exactly equivalent to the "or"
> > operator, as they'll use the default if you have any falsy value.
> > variable = some_function(...) or []
>
> Isn't that in itself a good argument in favor of (??) ?
I remembered this issue on bpo with contracting opinions from when I first
looked in 2019.
See https://bugs.python.org/issue33439
--
Best,
Joannah Nanjekye
*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program."
(Off-topic)
On Sat, Oct 23, 2021 at 07:42 Steven D'Aprano wrote:
> I expect that people were using strings for forward references before
> PEP 484, but it was 484 that made it official.
I doubt it. We invented that specifically for mypy. I am not aware of any
prior art.
—Guido
>
> --
On Sat, Oct 23, 2021 at 09:49:10AM -0400, Larry Hastings wrote:
> It's an debatable point since "from future" behavior is always off by
> default. I'd certainly agree that libraries /should/ support stringized
> annotations by now, considering they were nearly on by default in 3.10.
> But I
Marc Mueller writes:
> True, but from my experience 'None' is just by far the most common
> default. Why not improve how we handle it?
The question is whether this is an improvement in the long run. When
some falsies are expected, in-range values, "if arg is None: ..." or
"x = default if arg
On 10/22/21 1:45 AM, Steven D'Aprano wrote:
Any other runtime annotation tool has to support strings, otherwise the
"from __future__ import annotations" directive will have already broken
it. If the tool does type-checking, then it should support stringified
annotations. They have been a
> Bear in mind that these last ones are exactly equivalent to the "or"
> operator, as they'll use the default if you have any falsy value.
> variable = some_function(...) or []
Isn't that in itself a good argument in favor of (??) ? By missing to add 'is
None', I would have already added a
On Sat, Oct 23, 2021 at 5:55 AM Bluenix wrote:
>
>
> > Is the performance of PEP 649 and PEP 563 similar enough that we can
> > outright discount it as a concern? Does anyone actually care about the
> > overhead of type annotations anymore? Are there other options to alleviate
> > this potential
11 matches
Mail list logo
