One use case which seems significant to me but I don’t think has been
explicitly mentioned is annotations using a package with stubs where the
stubbed typing API is slightly different than the runtime API.
For example sometimes additional tape aliases are defined for convenience in
stubs
On 10/26/21 5:22 PM, Bluenix wrote:
* Functions having the same signature share the same annotation tuple.
Is this true with code that have a mutable default?
[... examples deleted...]
You're confusing two disjoint concepts.
First of all, all your examples experiment with default values
> * Functions having the same signature share the same annotation tuple.
Is this true with code that have a mutable default?
>>> def a(arg = []):
... arg.append('a')
... return arg
...
>>> def b(arg = []):
... arg.append('b')
... return arg
...
>>> a()
['a']
>>> a()
['a', 'a']
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 --
(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
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
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
> Any other runtime annotation tool has to support strings, otherwise the
> "from __future__ import annotations" directive will have already broken
> it.
Exactly- isn’t that it was deferred in 3.10, and may never be implemented?
I’ll leave it to the Pydantic developers to discuss that, but they
On Thu, Oct 21, 2021 at 09:36:20PM -0700, Christopher Barker wrote:
> On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano wrote:
>
> > Runtime type checkers already have to deal with forward refs that are
> > strings, as this is legal, and always will be:
> >
> > def function(arg:'Spam') -> Any:
Hello!
> This would affect code that expects annotations to always be strings, but such
> code would have to be poking directly at function objects (the
> __annotations__ attribute), instead of using the advertised ways of getting
> at annotations (like typing.get_type_hints()).
I would
Larry Hastings wrote:
> In Python, if you evaluate an undefined name, Python raises a
> NameError. This is so consistent I'm willing to call it a "rule".
Would it help the think of the function creation as catching that exception,
and then finishing construction with its own version of NaN?
On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano wrote:
> Runtime type checkers already have to deal with forward refs that are
> strings, as this is legal, and always will be:
>
> def function(arg:'Spam') -> Any: ...
>
> so we're not putting any extra burden on them. And we had already
>
On 10/21/21 1:17 AM, Steven D'Aprano wrote:
On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:
In Python, if you evaluate an undefined name, Python raises a
NameError. This is so consistent I'm willing to call it a "rule".
Various folks have proposed an exception to this "rule":
On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:
> In Python, if you evaluate an undefined name, Python raises a
> NameError. This is so consistent I'm willing to call it a "rule".
> Various folks have proposed an exception to this "rule": evaluating an
> undefined name in an
It's certainly not my goal to be misleading. Here's my perspective.
In Python, if you evaluate an undefined name, Python raises a
NameError. This is so consistent I'm willing to call it a "rule".
Various folks have proposed an exception to this "rule": evaluating an
undefined name in an
> On 20 Oct 2021, at 15:18, Thomas Wouters wrote:
>
> (For visibility, posted both to python-dev and Discourse.)
Since this got split into Discourse and python-dev, I wrote my take on the
issue on the blog so that I could post it in both spaces with proper formatting
and everything:
On Thu, Oct 21, 2021 at 10:35 AM Larry Hastings wrote:
> .
>
> Your proposal is one of several suggesting that type annotations are
> special enough to break the rules. I don't like this idea. But you'll be
> pleased to know there are a lot of folks in the "suppress the NameError"
> faction,
On Thu, Oct 21, 2021 at 12:06 PM Jelle Zijlstra
wrote:
> I would want this for my type checker, pyanalyze. I'd want to get the raw
> annotation and turn it into a type. For example, if the annotation is
> `List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at
> least still
El jue, 21 oct 2021 a las 10:31, Carl Meyer () escribió:
> On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
> wrote:
> > Sorry for the naive question but why doesn't "TYPE_CHECKING" work under
> PEP 649?
> >
> > I think I've seen others mention this but as the code object isn't
> executed until
On 10/21/21 5:42 PM, Damian Shaw wrote:
Sorry for the naive question but why doesn't "TYPE_CHECKING" work
under PEP 649?
I think I've seen others mention this but as the code object isn't
executed until inspected then if you are just using annotations for
type hints it should work fine?
On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
wrote:
> Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
> 649?
>
> I think I've seen others mention this but as the code object isn't executed
> until inspected then if you are just using annotations for type hints it
>
Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
649?
I think I've seen others mention this but as the code object isn't executed
until inspected then if you are just using annotations for type hints it
should work fine?
Is the use case wanting to use annotations for
On 10/21/21 5:01 AM, Henry Fredrick Schreiner wrote:
PEP 649 was about the same as the current performance, but PEP 563 was
significantly faster, since it doesn’t instantiate or deal with
objects at all, which both the current default and PEP 563 do.
I don't understand what you're saying
On Thu, Oct 21, 2021 at 1:08 PM Henry Fredrick Schreiner
wrote:
>
> > typing features from future Python versions
>
> I second both of these uses, but especially this (which seems to be missing
> from the original post), it’s been by far the main reason I’ve used this mode
> and I’ve seen this
> typing features from future Python versions
I second both of these uses, but especially this (which seems to be missing
from the original post), it’s been by far the main reason I’ve used this mode
and I’ve seen this used, and is the main feature to look forward to when
dropping Python 3.7
On Thu, Oct 21, 2021 at 6:38 AM Christopher Barker wrote:
>
> Thanks to the SC for such a thoughtful note. I really like where this is
> going.
>
> One thought.
>
> On Wed, Oct 20, 2021 at 6:21 AM Thomas Wouters wrote:
>>
>> Is the performance of PEP 649 and PEP 563 similar enough that we can
Thanks to the SC for such a thoughtful note. I really like where this is
going.
One thought.
On Wed, Oct 20, 2021 at 6:21 AM Thomas Wouters wrote:
>
>1.
>
>Is the performance of PEP 649 and PEP 563 similar enough that we can
>outright discount it as a concern? Does anyone actually
I'm sorry, I sent my last mail too early. Here are the rest of my thoughts.
Am 20.10.21 um 15:18 schrieb Thomas Wouters:
Keeping the future import and stringified annotations around is
certainly an option, but we’re worried about the cost of the
implementation, the support cost, and the
Am 20.10.21 um 15:18 schrieb Thomas Wouters:
By and large, the SC views PEP 649 as a better way forward. If PEP 563
had never come along, it would be a fairly easy decision to accept PEP
649. We are still inclined to accept PEP 649. That would leave the
consideration about what to do with
31 matches
Mail list logo
