On 4/17/21 8:43 PM, Larry Hastings wrote:
TBD: how this interacts with PEP 649. I don't know if it means we
only do this, or if it would be a good idea to do both this and 649.
I just haven't thought about it. (It would be a runtime error to set
both "o.__str_annotations__" and "o.__co_annot
Hi Samuel,
I have a naive question about pydantic. IIRC there's something in your
tracker about not being able to handle recursive definitions correctly with
PEP 563. But I must be misremembering, because PEP 563 actually makes that
easier, not harder. Without PEP 563, how does it handle classes l
As far as I know, both Pydantic and marshmallow start using annotation
for runtime type after PEP 563 is accepted. Am I right?
When PEP 563 is accepted, there are some tools using runtime type in
annotation, but they are not adopted widely yet.
But we didn't have any good way to emit DeprecationWa
What about creating a new syntax for annotating metadata? For example,
`type_hint :: metadata` could be equivalent to `Annotated[type_hint,
"metadata"]`, and if we wanted type guards to look like TypeScript they could
look like this:
```
def is_str_list(val: List[object]) -> bool :: is List
I'd like to chime in with an example of how PEP 563 breaks code that uses
dataclasses.
I've written a library instant_api (https://github.com/alexmojaki/instant_api)
that is heavily inspired by FastAPI but uses dataclasses for complex types
instead of pydantic. The example at the beginning of t
On Sun, Apr 18, 2021 at 10:49 AM Christopher Barker
wrote:
> On Sun, Apr 18, 2021 at 10:12 AM Larry Hastings
> wrote:
>
>> On 4/18/21 9:14 AM, Richard Levasseur wrote:
>>
>> Alternatively: what if the "trigger" to resolve the expression to an
>> object was moved from a module-level setting to th
Christopher Barker wrote:
> ... folks don't want annotations to hurt run-time performance,
> particularly when they are being used primarily for
> pre-run-time static type checking.
So are we looking for three separate optimization levels at compile time?
Base level: evaluate everything, keep
On 4/17/2021 11:43 PM, Larry Hastings wrote:
The heart of the debate between PEPs 563 and 649 is the question: what
should an annotation be? Should it be a string or a Python value? It
seems people who are pro-PEP 563 want it to be a string, and people who
are pro-PEP 649 want it to be a
I think there is a point to be made for requiring a function call to resolve
annotations, in regard to the ongoing discussion about relaxing the annotation
syntax
(https://mail.python.org/archives/list/python-dev@python.org/message/2F5PVC5MOWMGFVOX6FUQOUC7EJEEXFN3/)
Type annotation are still a
On Sun, Apr 18, 2021 at 10:12 AM Larry Hastings wrote:
> On 4/18/21 9:14 AM, Richard Levasseur wrote:
>
> Alternatively: what if the "trigger" to resolve the expression to an
> object was moved from a module-level setting to the specific expression?
> e.g.
>
> I genuinely don't understand what yo
Thanks Larry,
This seems to be going in a good direction.
I do note another motivator -- folks don't want annotations to hurt
run-time performance, particularly when they are being used primarily for
pre-run-time static type checking. Which makes sense. And PEP 649 seems to
affect perfromance.
W
On 4/18/21 9:14 AM, Richard Levasseur wrote:
Alternatively: what if the "trigger" to resolve the expression to an
object was moved from a module-level setting to the specific
expression? e.g.
def foo(x: f'{list[int]}') -> f'{str}':
bar: f'{tuple[int]}' = ()
@pydantic_or_whatever_that_need
On 4/18/21 9:10 AM, Damian Shaw wrote:
Hi Larry, all, I was thinking also of a compromise but a slightly
different approach:
Store annotations as a subclass of string but with the required frames
attached to evaluate them as though they were in their local context.
Then have a function "get_a
You're right, losing visibility into the local scope (and outer function
scopes) is part of why I suggest the behavior be compile-time
selectable. The pro-PEP-563 crowd doesn't seem to care that 563 costs
them visibility into anything but global scope; accepting this loss of
visibility is p
On 16 Apr 2021, at 19:38, Jelle Zijlstra wrote:
El vie, 16 abr 2021 a las 10:01, Walter Dörwald
()
escribió:
On 16 Apr 2021, at 16:59, Guido van Rossum wrote:
If you look deeper, the real complaints are all about the backwards
incompatibility when it comes to locally-scoped types in annotati
On Sat, Apr 17, 2021 at 8:46 PM Larry Hastings wrote:
>
> The heart of the debate between PEPs 563 and 649 is the question: what
> should an annotation be? Should it be a string or a Python value? It
> seems people who are pro-PEP 563 want it to be a string, and people who are
> pro-PEP 649 wan
Hi Larry, all, I was thinking also of a compromise but a slightly different
approach:
Store annotations as a subclass of string but with the required frames
attached to evaluate them as though they were in their local context. Then
have a function "get_annotation_values" that knows how to evaluate
El sáb, 17 abr 2021 a las 20:45, Larry Hastings ()
escribió:
>
> The heart of the debate between PEPs 563 and 649 is the question: what
> should an annotation be? Should it be a string or a Python value? It
> seems people who are pro-PEP 563 want it to be a string, and people who are
> pro-PEP 6
18 matches
Mail list logo
