On Sun, Apr 25, 2021 at 10:30 AM Brett Cannon wrote:
> I know I would be curious, especially if backwards compatibility can be
> solved reasonably (for those that haven't lived this, deferred execution
> historically messes up code relying on import side-effects and trackbacks are
> weird as
On Sat., Apr. 24, 2021, 20:55 Carl Meyer, wrote:
> Hi Larry,
>
> This is a creative option, but I am optimistic (now that the SC
> decision has removed the 3.10 deadline urgency) that we can find a
> path forward that is workable for everyone and doesn't require a
> permanent compiler feature
Hi Larry,
This is a creative option, but I am optimistic (now that the SC
decision has removed the 3.10 deadline urgency) that we can find a
path forward that is workable for everyone and doesn't require a
permanent compiler feature flag and a language that is permanently
split-brained about
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
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
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,
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
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
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.
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]}' = ()
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
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
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
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
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
16 matches
Mail list logo
