[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

On 5/1/22 15:44, Paul Bryan wrote: Can someone state what's currently unpalatable about 649? It seemed to address the forward-referencing issues, certainly all of the cases I was expecting to encounter. Carl's talk was excellent here; it would be lovely if he would chime in and reply. 

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

FWIW, I'm in agreement.  My "forward class" proposal(s) were me trying to shine a light to find a way forward; I'm in no way adamant that we go that direction.  If we can make 649 palatable without introducing forward declarations for classes, that's great!  If in the future we discover more

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

On 4/26/22 09:31, MRAB wrote: On 2022-04-26 06:32, Larry Hastings wrote: Note that this spelling is also viable:     class C I don't like that because it looks like you've just forgotten the colon. Perhaps:     class C: ... That's not a good idea.  Every other place in Python where

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

On 4/25/22 23:56, Ronald Oussoren wrote: A problem with this trick is that you don’t know how large a class object can get because a subclass of type might add new slots. This is currently not possible to do in Python code (non-empty ``__slots__`` in a type subclass is rejected at runtime),

[Python-Dev] Proto-PEP part 4: The wonderful third option

Sorry, folks, but I've been busy the last few days--the Language Summit is Wednesday, and I had to pack and get myself to SLC for PyCon,   I'll circle back and read the messages on the existing threads tomorrow.  But for now I wanted to post "the wonderful third option" for forward class

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/22 08:57, Eric V. Smith wrote: On 4/23/2022 9:55 AM, Jelle Zijlstra wrote: However, it doesn't solve the problem for base classes. For example, str is conceptually defined as `class str(Sequence["str"]):`. A forward reference can't make `str` defined when the bases are evaluated,

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/22 06:55, Jelle Zijlstra wrote: So to reiterate, your proposal would be to write this as: forward class B:     pass class A:     value: B continue class B:     value: A Not quite; the "forward class" statement doesn't have a colon or a class body.  This would be written as:

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

I should have said "numpy_forward", not "numpy.forward". I changed my mind at the last second as I was writing that email, and momentarily forgot that when you import x.y you implicitly import x. /arry On Sat, Apr 23, 2022, 01:53 Larry Hastings wrote: > > On 4/23

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/22 03:10, Terry Reedy wrote: On 4/22/2022 11:16 PM, Larry Hastings wrote: So I still prefer "forward class". I don't think it's as clear as "forward class" 'forward class' for an incomplete class is not at all clear to me.  It is not clear to me which part

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/22 01:14, Steven D'Aprano wrote: On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote: But rather than speculate further, perhaps someone who works on one of the static type analysis checkers will join the discussion and render an informed opinion about how easy or hard

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/23/22 00:53, Steven D'Aprano wrote: It's a "forward-declared class object".  It's the real class object, but it hasn't been fully initialized yet, and won't be until the "continue class" statement. The only thing that makes it not fully initialised is that it has a bozo bit dunder

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 23:41, Mehdi2277 wrote: My main question for this approach is how would this work with type checkers? It would be new syntax for Python, so type checkers would have to understand it. Is there any restriction that forward class's continuation must appear in same module? No.

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 22:03, Chris Angelico wrote: Anyhow, [a forward-defined class object is] a class, with some special features (notably that you can't instantiate it). Yes.  Specifically, here's my intention for "forward-defined class objects": you can examine some generic dunder values (__name__,

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 20:58, Steven D'Aprano wrote: On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote: This PEP proposes an additional syntax for declaring a class which splits this work across two statements: * The first statement is `forward class`, which declares the class and binds

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 19:36, Terry Reedy wrote: On 4/22/2022 9:13 PM, Larry Hastings wrote: forward class X() New keywords are a nuisance.  And the proposed implementation seems too complex. My proposed implementation seemed necessary to handle the complexity of the problem.  I would welcome

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 19:17, Chris Angelico wrote: I'm unsure about the forward class. How is it different from subclassing an ABC? They're just different objects.  A subclass of an ABC is either itself another abstract base class, which will never be instantiatable, or a non-abstract class, which is

[Python-Dev] Proto-PEP part 3: Closing thoughts on "forward class", etc.

Just a quick note from me on the proto-PEP and the two proposed implementations.  When I started exploring this approach, I didn't suspect it'd require such sweeping changes to be feasible. Specifically, I didn't think I was going to propose changing the fundamental mechanism used to create

[Python-Dev] Proto-PEP part 2: Alternate implementation proposal for "forward class" using a proxy object

Here's one alternate idea for how to implement the "forward class" syntax. The entire point of the "forward class" statement is that it creates the real actual class object.  But what if it wasn't actually the "real" class object?  What if it was only a proxy for the real object? In this

[Python-Dev] Proto-PEP part 1: Forward declaration of classes

This document is a loose proto-PEP for a new "forward class" / "continue class" syntax.  Keep in mind, the formatting is a mess. If I wind up submitting it as a real PEP I'll be sure to clean it up first. /arry -- PEP : Forward declaration of

[Python-Dev] Re: Defining tiered platform support

On 3/14/22 20:31, Brett Cannon wrote: On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner wrote: It would be great to have the list of supported platforms per Python version! I could see the table in PEP 11 being copied into the release PEPs. By "release PEPs", you mean the

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

On 2/22/22 6:00 PM, Eric Snow wrote: On Sat, Feb 19, 2022 at 12:46 AM Eric Snow wrote: Performance --- A naive implementation shows `a 4% slowdown`_. Several promising mitigation strategies will be pursued in the effort to bring it closer to performance-neutral. See the `mitigation`_

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On 2/21/22 22:06, Chris Angelico wrote: On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote: While I don't think it's fine to play devil's advocate, given the choice between "this will help a common production use-case" (pre-fork servers) and "this could hurt a hypothetical

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On 2/21/22 21:44, Larry Hastings wrote: While I don't think it's fine to play devil's advocate," Oh!  Please ignore the word "don't" in the above sentence.  I /do/ think it's fine to play devil's advocate. Sheesh, //arry/ ___

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

mes this could waste a significant amount of memory), I think the former is more important. //arry/ On 2/20/22 06:01, Antoine Pitrou wrote: On Sat, 19 Feb 2022 12:05:22 -0500 Larry Hastings wrote: On 2/19/22 04:41, Antoine Pitrou wrote: On Fri, 18 Feb 2022 14:56:10 -0700 Eric Snow wrote: On Wed, Feb

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On 2/19/22 04:41, Antoine Pitrou wrote: On Fri, 18 Feb 2022 14:56:10 -0700 Eric Snow wrote: On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings wrote: He suggested(*) all the constants unmarshalled as part of loading a module should be "immortal", and if we could rejigger how we

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

I experimented with this at the EuroPython sprints in Berlin years ago.  I was sitting next to MvL, who had an interesting observation about it.  He suggested(*) all the constants unmarshalled as part of loading a module should be "immortal", and if we could rejigger how we allocated them to

[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)

On 1/26/22 3:02 PM, Victor Stinner wrote: Hi, My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME() macros. This change breaks M2Crypto and mecab-python3 projects in code generated by SWIG. I tried two solutions to prevent SWIG accessing PyDescrObject members directly:

[Python-Dev] Re: The current state of typing PEPs

On 11/29/21 7:10 PM, Inada Naoki wrote: Anyone against making a statement that "PEP 563 will never be the default behavior"? I think only the SC is empowered to make such a statement. Then, we do not need to decide "PEP 563 or 649". We can focus on whether we can replace "stock semantics +

[Python-Dev] Re: The current state of typing PEPs

On 11/29/21 2:56 PM, Barry Warsaw wrote: PEP 563 and 649 have visible effects that even within that domain can have important side effects. For example, PEP 563’s loss of local scope, which even “de-stringify-ing” can’t recover. This is what we need help with. Well, sure.  If PEP 563 and

[Python-Dev] Oh look, I've been subscribed to python/issues-test-2 notifications again

I guess this is part of the migration from bpo to GitHub issues? Maybe the initial work could be done in a private repo, to cut down on the spurious email notifications to literally everybody subscribed to cpython?  Which is a lot of people. //arry/

[Python-Dev] Re: Naming convention for AST types

Hey, as public mailing list mistakes go, that one's pretty mild. //arry/ On 10/28/21 6:35 PM, Jeremiah Vivian wrote: Sorry for the two replies, I didn't think the first one would be sent. ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

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

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

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

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

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

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

ld have to iterate over every value in an annotation to look for this special value. As a consumer of annotations at runtime, I'd definitely prefer that they raise NameError rather than silently substitute in this alternative value. //arry / On 10/21/21 8:01 PM, Guido van Rossum wrote: On Thu,

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

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?

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

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

[Python-Dev] Re: Python multithreading without the GIL

Oops! Sorry everybody, I meant that to be off-list. Still, I hope you at least enjoyed my enthusiasm! /arry On Tue, Oct 12, 2021, 12:55 Larry Hastings wrote: > > (off-list) > > > On 10/11/21 2:09 PM, Sam Gross wrote: > > The ccbench results look pretty good: about

[Python-Dev] Re: Python multithreading without the GIL

(off-list) On 10/11/21 2:09 PM, Sam Gross wrote: The ccbench results look pretty good: about 18.1x speed-up on "pi calculation" and 19.8x speed-up on "regular expression" with 20 threads (turbo off). The latency and throughput results look good too. JESUS CHRIST //arry/

[Python-Dev] Re: Python multithreading without the GIL

On 10/7/21 8:52 PM, Sam Gross wrote: I've been working on changes to CPython to allow it to run without the global interpreter lock. Before anybody asks: Sam contacted me privately some time ago to pick my brain a little.  But honestly, Sam didn't need any help--he'd already taken the

[Python-Dev] Re: PEP 654 except* formatting

On 10/6/21 2:34 PM, Łukasz Langa wrote: On 6 Oct 2021, at 12:06, Larry Hastings <mailto:la...@hastings.org>> wrote: It seems like, for this to work, "group" would have to become a keyword. No, just like `match` and `case` didn't have to. This would play havoc with a l

[Python-Dev] Re: PEP 654 except* formatting

It seems like, for this to work, "group" would have to become a keyword.  This would play havoc with a lot of existing code.  I can't tell you how many times I've used the identifier "group" in my code, particularly when dealing with regular expressions. Even making it a soft keyword, a la

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/12/21 8:25 AM, Guido van Rossum wrote: Maybe we could specialize the heck out of this and not bother with a function object? In the end we want to execute the code, the function object is just a convenient way to bundle defaults, free variables (cells) and globals. But co_annotation has

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 5:15 AM, Chris Angelico wrote: On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: This approach shouldn't break reasonable existing code. That said, this change would be observable from Python, and pathological code could notice and break. For example: def

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 5:21 AM, Inada Naoki wrote: But memory footprint and GC time is still an issue. Annotations in PEP 649 semantics can be much heavier than docstrings. I'm convinced that, if we accept PEP 649 (or something like it), we can reduce its CPU and memory consumption. Here's a slightly

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger <mailto:tagr...@gmail.com>> wrote: Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something like

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 12:02 AM, Thomas Grainger wrote: I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/9/21 8:25 PM, Inada Naoki wrote: Currently, reference implementation of PEP 649 has been suspended. We need to revive it and measure performance/memory impact. Perhaps this sounds strange--but I don't actually agree. PEP 563 was proposed to solve a forward-references problem for the

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/10/21 11:15 AM, Thomas Grainger wrote: Although the co_annoations code could intercept the NameError and replace return a ForwardRef object instead of the resolved name No, it should raise a NameError, just like any other Python code.  Annotations aren't special enough to break the

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/10/21 11:09 AM, Damian Shaw wrote: Could PEP 649 be modified to say that if a NameError is raised the result is not cached and therefore you can inspect it later at runtime to get the real type once it is defined? Wouldn't that then allow users to write code that allows for all use cases

[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

On 7/23/21 7:38 AM, Petr Viktorin wrote: (In both C & C++, the size of an `enum` is implementation-defined. That's unlikely to be a problem in practice, but one more point against enum.) True, but there's always the old trick of sticking in a value that forces it to be at least 32-bit:

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

On 6/3/21 4:20 AM, Chris Johns wrote: Might be out of context here, but IMHO "." shouldn't be assumed to be the current directory anyway. As someone who has ported python to a system where it isn't, these assumptions tend to cause problems. That sounds miserable.  What does "." signify on

[Python-Dev] Re: Critique of PEP 657 -- Include Fine Grained Error Locations in Tracebacks

On 5/18/21 5:25 AM, Pablo Galindo Salgado wrote: Yet another problem that I found: One integer is actually not enough to assign IDs. One unsigned integer can cover 4,294,967,295 AST nodes, but is technically possibleto have more than that in a single file. Surely you could use a 64-bit int

[Python-Dev] Re: The repr of a sentinel

On 5/13/21 10:46 AM, Eric V. Smith wrote: >>> MISSING I think a repr of just "MISSING", or maybe "dataclasses.MISSING" would be better. I literally just went down this road--for a while there was a special sentinel value for the eval_str parameter to inspect.get_annotations().  The repr

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On 5/9/21 3:00 AM, M.-A. Lemburg wrote: BTW: For better readability, I'd also not output the lines for every stack level in the traceback, but just the last one, since it's usually clear where the call to the next stack level happens in the upper ones. Playing devil's advocate: in the

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote: Given that column numbers are not very big compared with line numbers, we plan to store these as unsigned chars or unsigned shorts. We ran some experiments over the standard library and we found that the overhead of all pyc files is: * If we use

[Python-Dev] Re: In what tense should the changelog be written?

On 4/30/21 4:51 AM, Victor Stinner wrote: On Fri, Apr 30, 2021 at 6:57 AM Larry Hastings wrote: Function and class names should not be followed by parentheses, unless demonstrating an example call. Oh, I love putting parentheses when mentionning a function: "foo() now does thigs new

[Python-Dev] Re: In what tense should the changelog be written?

by parentheses, unless demonstrating an example call. Slapping my forehead, //arry/ On 4/29/21 9:50 PM, Larry Hastings wrote: I'll wait to see if anybody else has contrary opinions, but for now here's a first draft: Your NEWS entry should be written in the present tense, and should

[Python-Dev] Re: In what tense should the changelog be written?

when spam happens,” because that isn’t clear about whether that’s the before or after behavior.) On Thu, Apr 29, 2021 at 17:37 Ethan Furman <mailto:et...@stoneleaf.us>> wrote: On 4/29/21 7:57 PM, Larry Hastings wrote:  > When one writes one's "blurb" for the ch

[Python-Dev] In what tense should the changelog be written?

When one writes one's "blurb" for the changelog, in what tense should it be?  I mostly see entries in present tense: bpo-43660: Fix crash that happens when replacing sys.stderr with a callable that can remove the object while an exception is being printed. Patch by Pablo Galindo.

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/24/21 8:09 AM, Petr Viktorin wrote: On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts. The latter was more delicate than the former

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/24/21 7:11 AM, Nick Coghlan wrote: On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, <mailto:la...@hastings.org>> wrote: So I now suspect that my knee-jerk answer is wrong.  Am I going too far down the rabbit hole? Should I /just/ make the change for user classes and leav

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for both.  I have this much working, including

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/23/21 9:26 PM, Guido van Rossum wrote: This is happening, right? Adding a default `__annotations = {}` to modules and classes. (Though https://bugs.python.org/issue43901 seems temporarily stuck.) It's happening, and I wouldn't say it's stuck.  I'm

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On 4/20/21 10:03 AM, Mark Shannon wrote: If you guarded your code with `isinstance(foo, Sequence)` then I could not use it with my `Foo` even if my `Foo` quacked like a sequence. I was forced to use nominal typing; inheriting from Sequence, or explicitly registering as a Sequence. If I'm

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On 4/20/21 10:03 AM, Mark Shannon wrote: Then came PEP 563 and said that if you wanted to access the annotations of an object, you needed to call typing.get_type_hints() to get annotations in a meaningful form. This smells a bit like enforced static typing to me. I'm working to address

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

@python.org/thread/AWKVI3NRCHKPIDPCJYGVLW4HBYTEOQYL/ Here's kind of where we left it: On 1/12/21 7:48 PM, Guido van Rossum wrote: On Tue, Jan 12, 2021 at 6:35 PM Larry Hastings <mailto:la...@hastings.org>> wrote: On 1/12/21 5:28 PM, Brett Cannon wrote: The other thing to keep in m

[Python-Dev] Re: PEP 563 in light of PEP 649

On 4/19/21 1:37 PM, Ethan Furman wrote: On 4/19/21 10:51 AM, Larry Hastings wrote: Something analogous /could/ happen in the PEP 649 branch but currently doesn't.  When running Inada Noki's benchmark, there are a total of nine possible annotations code objects.  Except, each function

[Python-Dev] Re: PEP 563 in light of PEP 649

Oops: where I said nine, I should have said, twenty-seven.  3-cubed.  Should have had my coffee /before/ posting.  Carry on! //arry/ On 4/19/21 10:51 AM, Larry Hastings wrote: I noticed something this morning: there's another way in which Inada Naoki's benchmark here is--possibly

[Python-Dev] Re: PEP 563 in light of PEP 649

timization naturally takes advantage of that.  PEP 649 doesn't.  Should it? Would this really be beneficial to real-world code bases? Cheers, //arry/ On 4/16/21 12:26 PM, Larry Hastings wrote: Please don't confuse Inada Naoki's benchmark results with the effect PEP 649 would have on a real-

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

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__&qu

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

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]}' = ()

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

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

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

ays gets you the real annotations values, every time. Cheers, //arry/ On 4/18/21 7:06 AM, Jelle Zijlstra wrote: El sáb, 17 abr 2021 a las 20:45, Larry Hastings (<mailto:la...@hastings.org>>) escribió: The heart of the debate between PEPs 563 and 649 is the question: wha

[Python-Dev] PEP 563 and 649: The Great Compromise

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 value. Actually, let me amend that slightly. 

[Python-Dev] Re: PEP 563 in light of PEP 649

Obviously that's a bug.  Can you send me this test case?  Anything works--Github, private email, whatever is most convenient for you.  Thank you! //arry/ On 4/16/21 11:22 PM, Inada Naoki wrote: ## memory error on co_annotations I modifled py_compile to add `from __future__ import

[Python-Dev] Re: PEP 563 in light of PEP 649

On 4/16/21 5:00 PM, Guido van Rossum wrote: (3) Ditto run with Larry's branch (PEP 649, assuming it's on by default there -- otherwise, modify the source by inserting the needed future import at the top) The co_annotations stuff in my branch is gated with "from __future__ import

[Python-Dev] Re: PEP 563 in light of PEP 649

Please don't confuse Inada Naoki's benchmark results with the effect PEP 649 would have on a real-world codebase.  His artifical benchmark constructs a thousand empty functions that take three parameters with randomly-chosen annotations--the results provides some insights but are not

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/15/21 9:24 PM, Inada Naoki wrote: Unlike simple function case, PEP 649 creates function object instead of code object for __co_annotation__ of methods. It cause this overhead. Can we avoid creating functions for each annotation? As the implementation of PEP 649 currently stands, there

[Python-Dev] Re: In support of PEP 649

On 4/15/21 6:09 PM, Barry Warsaw wrote: On Apr 15, 2021, at 17:47, Oscar Benjamin wrote: Would it be problematic to postpone making __future__.annotations the default? This is a good question, and I think the SC would really like to know if anybody has objections to postponing this to 3.11.

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/15/21 2:02 PM, Sebastián Ramírez wrote: ## Questions I'm not very familiar with the internals of Python, and I'm not sure how the new syntax for `Union`s using the vertical bar character ("pipe", "|") work. But would PEP 649 still support things like this?: def run(arg: int | str = 0):

[Python-Dev] Re: In support of PEP 649

On 4/15/21 2:49 PM, Paul Ganssle wrote: I haven't followed this closely enough — if PEP 649 were accepted today, would it even be ready for use before the 3.10 code freeze (which is in a few weeks)? Perhaps I'm a poor judge of the quality of my own code.   But I'd say I have a working

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Thanks for doing this!  I don't think PEP 649 is going to be accepted or rejected based on either performance or memory usage, but it's nice to see you confirmed that its performance and memory impact is acceptable. If I run "ann_test.py 1", the annotations are already turned into

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/14/21 1:42 PM, Baptiste Carvello wrote: Are there specific annoyances associated with quoting always, apart from the 2 more characters? Yes.  Since the quoted strings aren't parsed by Python, syntax errors in these strings go undetected until somebody does parse them (e.g. your static

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

ithub.com/python/steering-council/issues <https://github.com/python/steering-council/issues> as ready for pronouncement, so we have not started officially discussing this PEP yet. -Brett On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings mailto:la...@hastings.org>> wrote:

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/14/21 10:44 AM, Guido van Rossum wrote: besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits,

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: To be honest, the most pressing issue with annotations is the clumsy way that type variables have to be introduced. The current convention, `T = TypeVar('T')`, is both verbose (why do I have to repeat the name?) and widely misunderstood (many help

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 1:52 PM, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings <mailto:la...@hastings.org>> wrote: On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 3:28 PM, Terry Reedy wrote: On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + code

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression. To be honest, the most pressing issue with

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 4:50 PM, Inada Naoki wrote: PEP 563 solves all problems relating to types not accessible in runtime. There are many reasons users can not get types used in annotations at runtime: * To avoid circular import * Types defined only in pyi files * Optional dependency that is slow to

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 4:50 PM, Inada Naoki wrote: As PEP 597 says, eval() is slow. But it can avoidable in many cases with PEP 563 semantics. PEP 597 is "Add optional EncodingWarning".  You said PEP 597 in one other place too.  Did you mean PEP 649 in both places? Cheers, //arry/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/11/21 7:55 PM, Paul Bryan wrote: PEP 563 also requires using ``eval()`` or ``typing.get_type_hints()`` to examine annotations. Code updated to work with PEP 563 that calls ``eval()`` directly would have to be updated simply to remove the ``eval()`` call. Code using

[Python-Dev] PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

LOAD_NAME opcodes to function normally. I look forward to your comments, //arry/ PEP: 649 Title: Deferred Evaluation Of Annotations Using Descriptors Author: Larry Hastings Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Jan-2021 Post-History: 11-Jan-2021, 11-Apr

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

On 3/27/21 4:23 PM, Jelle Zijlstra wrote: Now, PEP 649 doesn't actually fix this at the moment, since it still resolves all annotations in the global scope, but that's easily fixed by removing the special case in

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 2/27/21 2:37 AM, Paul Moore wrote: On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: Whenever I've used except Exception or stronger, it was a sanitary barrier around code that might well do unpredictable or even stupid things. Adding a new kind of exception that I hadn't predicted --

[Python-Dev] Happy 30th Birthday, Python!

I guess we forgot to observe it yesterday, but: February 19, 1991, was the day Guido first posted Python 0.9.1 to alt.sources: https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ Happy 30th birthday, Python! //arry/ ___

[Python-Dev] Re: Python 0.9.1

On 2/17/21 4:45 PM, Brett Cannon wrote: If we can get a clean copy of the original sources I think we should put them up under the Python org on GitHub for posterity. Call me crazy, but... shouldn't they be checked in?  I thought we literally had every revision going back to day zero.  It

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

I don't work on these sorts of codebases, and I don't use type hints or static type checking.  So I'm not really qualified to judge how bad / widespread a problem this is.  It's my hope that the greater Python core dev / user community can ascertain how serious this is. My main observation

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On 2/14/21 2:34 PM, Guido van Rossum wrote: On Sun, Feb 14, 2021 at 12:51 PM David Mertz > wrote: On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith mailto:g...@krypto.org>> wrote: *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return

  1   2   3   4   5   6   7   8   9   >