[Python-Dev] Latest version of PEP 669 -- Low Impact Monitoring for CPython

Hi everyone, The latest version of PEP 669 is up. The discussion is happening at https://discuss.python.org/t/pep-669-low-impact-monitoring-for-cpython/13018, but I am following email, if you want to respond here. I'd like to get this into 3.12, so I'll probably submit the PEP to the steering

[Python-Dev] Re: code.replace() and Python 3.11 exception table

Hi Gabriele, On 01/04/2022 4:50 pm, Gabriele wrote: Does this mean that this line in the bytecode library is likely to fail with 3.11, with no way to fix it? You can pass the exception table the same way you pass all the other arguments. The exception table depends on the code, but that is

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

Hi, On 22/03/2022 6:07 pm, Victor Stinner wrote: Hi, I proposed two PRs to move the private C API (Include/cpython/) of PEP 523 "Adding a frame evaluation API to CPython" to the internal C API (Include/internals/): * https://github.com/python/cpython/pull/32052 *

[Python-Dev] Re: Compiling of ast.Module in Python 3.10 and co_firstlineno behavior

Hi Fabio, On 17/02/2022 7:30 pm, Fabio Zadrozny wrote: Em qui., 17 de fev. de 2022 às 16:05, Mark Shannon mailto:m...@hotpy.org>> escreveu: Hi Fabio, This happened as part of implementing PEP 626. The previous behavior isn't very robust w.r.t doc strings and co

[Python-Dev] Re: Compiling of ast.Module in Python 3.10 and co_firstlineno behavior

Hi Fabio, This happened as part of implementing PEP 626. The previous behavior isn't very robust w.r.t doc strings and compiler optimizations. OOI, why would you want to revert to the old behavior? Cheers, Mark. On 17/02/2022 5:52 pm, Fabio Zadrozny wrote: Hi all, I'm stumbling with an

[Python-Dev] Re: [Steering-council] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

Ditto ... On Fri, Mar 5, 2021 at 7:04 AM Mark Shannon mailto:m...@hotpy.org>> wrote: [...] In some cases, the PEP would have improved the situation. For example: sys.setrecursionlimit(5000) def f():      f()

[Python-Dev] Re: Python 3.11.0a4 is blocked

Hi Pablo, Issue 43683 should not have been marked as a release blocker, as it is a performance issue, not a bug. The related bug (which was a release blocker) is https://bugs.python.org/issue46009, and was fixed a while ago. Cheers, Mark. On 04/01/2022 11:12 pm, Pablo Galindo Salgado wrote:

[Python-Dev] Re: RFC on Callable Syntax PEP

OOI, of those 1577 Callable type hints, how many distinct Callable types? On 20/12/2021 7:52 am, Andrew Svetlov wrote: At my job, we have 1577 Callable type hints scattered in 1063 Python files. For comparison, this codebase also has 2754 dict annotations and 1835 list ones. On Mon, Dec 20,

[Python-Dev] Re: RFC on Callable Syntax PEP

Hi, Why not make Callable usable as a function decorator? The motivating example in the PEP is this: def flat_map( l: list[int], func: Callable[[int], list[int]] ) -> list[int]: Since, as the PEP claims, `Callable[[int], list[int]]` is hard to read, then give it a name

[Python-Dev] Re: [RELEASE] Python 3.11.0a3 is available

On 08/12/2021 11:51 pm, Pablo Galindo Salgado wrote: * The [Faster Cpython Project](https://github.com/faster-cpython ) is already yielding some exciting results: this version of CPython 3.11 is ~12% faster on the geometric mean of the [PyPerformance

[Python-Dev] PEP 669: Low Impact Monitoring for CPython

Hi, I would like to announce latest PEP, PEP 669: Low Impact Monitoring for CPython. The aim of this PEP is to provide an API for profilers, debuggers and other tools to avoid the punitive overhead of using sys.settrace. If you have any interest in profilers, debuggers, coverage tools or

[Python-Dev] Re: Optimizing literal comparisons and contains

Hi, I am surprised by the insistence on this thread for excluding comparisons from constant folding. Why should we special case comparisons? Am I missing something here? We already constant fold a variety of expressions 0 * 7 '' * 7 True - True True * False (All the above are falsey)

[Python-Dev] Re: Optimizing literal comparisons and contains

On 28/11/2021 6:28 am, raymond.hettin...@gmail.com wrote: For the benefit of the audience on python-dev, you should also mention that this proposal and associated PR has been twice discussed and rejected on the tracker: https://bugs.python.org/issue45907

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

Another +1 for `except group` from me. On 04/10/2021 2:57 pm, Ammar Askar wrote: Throwing in another +1 for `except group`. It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking. Regards, Ammar On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou

[Python-Dev] How to decipher Windows errors on builds?

Hi, I'm getting build errors on Windows for https://github.com/python/cpython/pull/28386 The error message is: C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\um\winnt.h(253): error RC2188: D:\a\cpython\cpython\PCbuild\obj\311win32_Release\pythoncore\RCa01688(47) : fatal error

[Python-Dev] Re: PEP 667: Consistent views of namespaces

Hi Guido, On 23/08/2021 3:53 pm, Guido van Rossum wrote: On Mon, Aug 23, 2021 at 4:38 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Nick, On 22/08/2021 4:51 am, Nick Coghlan wrote: > If Mark's claim that PyEval_GetLocals() could not be fixed was true then

[Python-Dev] Re: PEP 667: Consistent views of namespaces

Hi Nick, On 22/08/2021 4:51 am, Nick Coghlan wrote: On Sun, 22 Aug 2021, 10:47 am Guido van Rossum, > wrote: Hopefully anyone is still reading python-dev. I'm going to try to summarize the differences between the two proposals, even though Mark already

[Python-Dev] PEP 667: Consistent views of namespaces

Hi all, I have submitted PEP 667 as an alternative to PEP 558. https://www.python.org/dev/peps/pep-0667/ Nick and I have agreed to disagree on the way to fix locals() and f_locals. We are both in agreement that it needs fixing. In summary, PEP 667 has roughly the same surface behavior as PEP

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

t; anyway. Do we need to do anything here to move forward on this issue? I've chatted with Larry and Mark Shannon, who have some additional thoughts and I'm sure will chime in. My only comment concerned performance. I won't claim that the cost of PEP 649 will be zero, but it won't be s

[Python-Dev] PEP 558, the simplest thing I could come up with

Hi Nick, Our discussion on PEP 558 got me thinking "What is the simplest thing that would work?". This is what I came up (in the form of a draft PEP): https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst It doesn't have O(1) len(f_locals), and it does break `PyEval_GetLocals()`

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

Hi Steve, On 29/07/2021 1:55 pm, Steve Dower wrote: On 7/29/2021 11:41 AM, Mark Shannon wrote: The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should

[Python-Dev] Repealing PEP 509 (Add a private version to dict)

Hi everyone, I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP. Before I do so, I would like to know if anyone thinks we should keep PEP 509. The dictionary version number is currently unused in CPython and just

[Python-Dev] Re: Comments on PEP 558

On 28/07/2021 1:03 am, Nick Coghlan wrote: On Wed, 28 Jul 2021, 1:50 am Mark Shannon, <mailto:m...@hotpy.org>> wrote: Hi Nick, On 27/07/2021 2:29 pm, Nick Coghlan wrote: > > > The reference documentation should be precise as well, since that is

[Python-Dev] Re: Comments on PEP 558

Hi Nick, On 27/07/2021 2:29 pm, Nick Coghlan wrote: (I'm not sure Mailman will get the threading right when I've received the original email directly, so apologies in advance if this reply creates a 2nd thread) On Mon, 26 Jul 2021 at 23:57, Mark Shannon wrote: Hi, First of all let me say

[Python-Dev] Comments on PEP 558

Hi, First of all let me say that I agree with the aims of PEP 558 and most of the design. I do find the wording of the PEP itself a bit confusing in a couple of places. This critique is based on my understanding of the PEP. If I am mistaken in my misunderstanding, then treat that as an

[Python-Dev] Critique of PEP 657

Hi, Apologies for my tardiness in doing this, but no one explicitly said it was too late to critique PEP 657... Critique of PEP 657 (Include Fine Grained Error Locations in Tracebacks) First of all I want to say that I

[Python-Dev] Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)

Hi, I was expected the announcement of a BDFL delegate for PEP 657, as the author is a steering council member. It seems that a PEP submitted by a SC member has been accepted by the SC with seemingly no external review. PEP 657 is likely to cause significant worsening of start up time and

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

Hi Brett, On 26/05/2021 3:56 am, Brett Cannon wrote: On Tue., May 25, 2021, 12:58 Guido van Rossum, > wrote: On Tue, May 25, 2021 at 12:34 PM Brett Cannon mailto:br...@python.org>> wrote: I personally think it should be a Standards Track PEP. This PEP

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

Hi, On 17/05/2021 5:22 pm, Ammar Askar wrote: >> While nicer locations for errors is great, it won't be popular if it has >> a negative impact on performance. >> Locations need to tracked through the compiler. > > In performance sensitive contexts won't most code be pre-compiled into > pyc files

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

Hi everyone, I fully agree with the rationale for the PEP, better error messages always help. However, I think the proposed implementation could be misleading in some cases and wastes memory. Use one position, not one-and-a-half positions. ---

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

Hi Fabio, On 13/05/2021 7:11 pm, Fabio Zadrozny wrote: Em qua., 12 de mai. de 2021 às 14:45, Mark Shannon <mailto:m...@hotpy.org>> escreveu: Hi everyone, I would like to present PEP 659. This is an informational PEP about a key part of our plan to improve

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

Hi Terry, On 13/05/2021 8:20 am, Terry Reedy wrote: On 5/12/2021 1:40 PM, Mark Shannon wrote: This is an informational PEP about a key part of our plan to improve CPython performance for 3.11 and beyond. What is the purpose of this PEP?  It seems in part to be like a Standards Track PEP

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

Hi Terry, On 13/05/2021 5:32 am, Terry Reedy wrote: On 5/12/2021 1:40 PM, Mark Shannon wrote: This is an informational PEP about a key part of our plan to improve CPython performance for 3.11 and beyond. As always, comments and suggestions are welcome. The claim that starts

[Python-Dev] PEP 659: Specializing Adaptive Interpreter

Hi everyone, I would like to present PEP 659. This is an informational PEP about a key part of our plan to improve CPython performance for 3.11 and beyond. For those of you aware of the recent releases of Cinder and Pyston, PEP 659 might look similar. It is similar, but I believe PEP 659

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

://us.pycon.org/2021/schedule/presentation/80/ Cheers, Luciano PS. If you are aware of other languages that support more than one of these quadrants, please let me know! On Tue, Apr 20, 2021 at 6:53 PM Eric Casteleijn wrote: On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon wrote: ... PEP

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

Hi everyone, Once upon a time Python was a purely duck typed language. Then came along abstract based classes, and some nominal typing starting to creep into the language. If you guarded your code with `isinstance(foo, Sequence)` then I could not use it with my `Foo` even if my `Foo`

[Python-Dev] Memory use of PEP 563 vs PEP 649

Hi, There has been some discussion on this mailing list about the memory use of PEP 563 vs PEP 649. It doesn't matter. The memory use of either is small, and any measurements are merely measuring artifacts of the current implementations, and the current on-disk representation of code

[Python-Dev] Re: Making staticmethod callable, any oposite?

ble fixes this issue. ``` @staticfunction def open(...): ... ``` Now open defined in Python behaves like C function. We don't need OpenWrapper anymore. This has already been committed by Guido's approval. staticmethod is callable, and OpenWrapper is just an alias of open and deprecated in mast

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Brandt, On 04/04/2021 1:34 am, Brandt Bucher wrote: Mark Shannon said: I was relying on the "reference" implementation, which is also in the PEP. Can you please stop putting scare quotes around "reference implementation"? You've done it twice now, and it's been a w

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Guido, On 02/04/2021 10:05 pm, Guido van Rossum wrote: On Fri, Apr 2, 2021 at 12:43 PM Brandt Bucher <mailto:brandtbuc...@gmail.com>> wrote: Mark Shannon wrote: > On 02/04/2021 7:19 am, Brandt Bucher wrote: > > I agree that self-matching classes shoul

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Brandt, On 02/04/2021 8:41 pm, Brandt Bucher wrote: Mark Shannon wrote: On 02/04/2021 7:19 am, Brandt Bucher wrote: I agree that self-matching classes should absolutely allow keyword matches. I had no idea the PEP forbade it. PEP 634 allows it. PEP 634 says: For a number of built

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Brandt, On 02/04/2021 7:19 am, Brandt Bucher wrote: Guido van Rossum wrote: Well, now I have egg on my face, because the current implementation does reject multiple occurrences of the same identifier in __match_args__. We generate an error like "TypeError: C() got multiple sub-patterns

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Guido, On 02/04/2021 2:38 am, Guido van Rossum wrote: On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon <mailto:m...@hotpy.org>> wrote: On 31/03/2021 9:53 pm, Guido van Rossum wrote: > On Wed, Mar 31, 2021 at 12:08 PM Mark Shannon mailto:m...@hotpy.org> > <

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Guido, On 31/03/2021 9:53 pm, Guido van Rossum wrote: On Wed, Mar 31, 2021 at 12:08 PM Mark Shannon <mailto:m...@hotpy.org>> wrote: [snip] Apart from that, I think the semantics are so similar once you've added __match_seq__/__match_map__  to PEP 634 that is hard to

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On 31/03/2021 11:31 pm, Brandt Bucher wrote: Guido van Rossum wrote: On Wed, Mar 31, 2021 at 2:14 PM Brandt Bucher brandtbuc...@gmail.com wrote: (One change from my last email: it doesn't allow `__match_map__` / `__match_seq__` to be set to `False`... only `True`. This prevents some

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Guido, On 31/03/2021 6:21 pm, Guido van Rossum wrote: On Wed, Mar 31, 2021 at 2:30 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: > - Add new `__match_seq__` and `__match_map__` special attributes, corresponding to new public `Py_TPFLAGS_MATCH_SEQ` and `Py_TPFLA

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Brandt, On 30/03/2021 11:49 pm, Brandt Bucher wrote: Hi Mark. I've spoken with Guido, and we are willing to propose the following amendments to PEP 634: - Require `__match_args__` to be a tuple. I think we're all in agreement on this one. Let's just do it. - Add new `__match_seq__`

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Brandt, On 30/03/2021 5:25 pm, Brandt Bucher wrote: Overall, I am still uncomfortable with PEP 653, and would probably not support its acceptance. Although it has thankfully become a much less radical proposal than it was a few weeks ago (thanks, Mark, for your attention to our

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

, 2021 at 10:16 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Oscar, Thanks for the feedback. On 27/03/2021 4:19 pm, Oscar Benjamin wrote: > On Sat, 27 Mar 2021 at 13:40, Mark Shannon mailto:m...@hotpy.org>> wrote: >> > >

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi Oscar, Thanks for the feedback. On 27/03/2021 4:19 pm, Oscar Benjamin wrote: On Sat, 27 Mar 2021 at 13:40, Mark Shannon wrote: Hi Mark, Thanks for putting this together. As the 3.10 beta is not so far away, I've cut down PEP 653 down to the minimum needed for 3.10. The extensions

[Python-Dev] Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

Hi everyone, As the 3.10 beta is not so far away, I've cut down PEP 653 down to the minimum needed for 3.10. The extensions will have to wait for 3.11. The essence of the PEP is now that: 1. The semantics of pattern matching, although basically unchanged, are more precisely defined. 2.

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

Hi Victor, I'm with you 100% on not returning borrowed references, doing so is just plain dangerous. However, is a blanket ban on stealing references the right thing? Maybe the problem is the term "stealing". The caller is transferring the reference to the callee. In some circumstances it

[Python-Dev] New name for the development branch [was Steering Council update for February]

Hi, Why choose "main" as a replacement for "master"? It's the development branch, shouldn't we call it "development" or "dev"? We give release branches meaningful names, so why give the development branch the not-so-meaningful name "main". From a user's perspective the "main" branch is

[Python-Dev] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

Hi Antoine, On 05/03/2021 4:07 pm, Antoine Pitrou wrote: On Fri, 5 Mar 2021 15:03:59 + Mark Shannon wrote: There are two issues here. Portability and changes to behaviour. Regarding portability, I have to admit that PEP is rather vague. That's my fault; I should have done more

[Python-Dev] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

Hi, Thanks for taking the time to consider the PEP. Although the PEP was rejected, I still believe that the safety guarantees in PEP 651 are worth adding to Python in the future. To do that (maybe for 3.11), I need to understand your concerns better. Would you clarify a few points for me?

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Tobias, On 19/02/2021 5:57 pm, Tobias Kohn wrote: > Hi Mark, > > Quoting Mark Shannon mailto:m...@hotpy.org>>: > >> [...] >> >> If you had published these "more complicated, powerful protocols", you >> might be able to claim that thi

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi Brandt, On 18/02/2021 5:32 pm, Brandt Bucher wrote: Thanks for taking the time to work on this, Mark. Overall, I'm skeptical of this proposal. It seems like it takes a lot of "simple" things and makes them quite complex, and takes many "static" things and makes them quite dynamic. I feel

[Python-Dev] Re: PEP 653: Precise Semantics for Pattern Matching

Hi, I wish I'd read this before replaying your last email On 18/02/2021 6:49 pm, Brandt Bucher wrote: Brandt Bucher wrote: For a pattern with no positional subpatterns, such as like `C()` or `C(x=x, y=y, z=z)`: ... It also appears that we lose a lot of expressive "idioms" by requiring

[Python-Dev] PEP 653: Precise Semantics for Pattern Matching

Hi everyone, I'd like to announce a new PEP. https://www.python.org/dev/peps/pep-0653/ It builds on PEP 634 (Structural Pattern Matching: Specification), adding: More precise semantics. A bit more customization for complex classes. Its also a bit more robust and should be faster (eventually).

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

Hi, First of all, sorry for not commenting on this earlier. I only became aware of this PEP yesterday. I like the general idea of adding a marker to show that a boolean function narrows the type of one (or more?) of its arguments. However, the suggested approach seems clunky and impairs

[Python-Dev] Re: Concerns about PEP 634

Hi Daniel, On 06/02/2021 7:47 pm, Daniel Moisset wrote: Hi Mark, I think some of these issues have already been raised and replied (even if no agreement has been reached). but this is a good summary, so let me reply with a summary of responses for this. > On Sat, 6 Feb 2021 at 15:51, M

[Python-Dev] Concerns about PEP 634

Hi, Since a decision on PEP 634 is imminent, I'd like to reiterate some concerns that I voiced last year. I am worried about the semantics and implementation of PEP 634. I don't want to comment on the merits of pattern matching in general, or the proposed syntax in PEP 634 (or PEP 640 or PEP

[Python-Dev] Re: Comments on PEP 558

Hi Sven, On 04/02/2021 9:06 am, Sven R. Kunze wrote: On 03.02.21 23:37, Nick Coghlan wrote: No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated snapshot. As long as it is possible to **write** to existing keys to **add

[Python-Dev] Re: Constructing expected_opinfo_* lists in test_dis.py

Hi Skip, On 01/02/2021 9:50 pm, Skip Montanaro wrote: Guido> Maybe these lines in test_dis.py? ... Skip> Thanks, I'll take a look. I was expecting there'd be a standalone Skip> script somewhere. Hadn't considered that comments would be hiding Skip> code. Indeed, that did the trick, however...

[Python-Dev] More comments on PEP 558

Hi Nick, A couple more issues with PEP 558, as I see it. Lack of specification - There is no specification section in PEP 558. Much of PEP 558 describes the differences between the current behavior and what PEP 558 proposes. These differences are often intermingled with

[Python-Dev] Re: Comments on PEP 558

Hi Nick, On 30/01/2021 4:44 am, Nick Coghlan wrote: On Sat, 30 Jan 2021 at 10:30, Nick Coghlan wrote: On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote: With a direct proxy coherency is not an issue. For things in the frame, it *is* a direct proxy - reads pull from the frame object

[Python-Dev] Re: Comments on PEP 558

Hi Nick, On 29/01/2021 1:21 pm, Nick Coghlan wrote: On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, <mailto:m...@hotpy.org>> wrote: Hi Nick, Regarding `f_locals` PEP 558 states: """ Instead of being a direct reference to the internal dynamic snaps

[Python-Dev] Why aren't we allowing the use of C11?

Hi everyone, PEP 7 says that C code should conform to C89 with a subset of C99 allowed. It's 2021 and all the major compilers support C11 (ignoring the optional parts). C11 has support for thread locals, static asserts, and anonymous structs and unions. All useful features. Is there a good

[Python-Dev] Comments on PEP 558

Hi Nick, Regarding `f_locals` PEP 558 states: """ Instead of being a direct reference to the internal dynamic snapshot used to populate the independent snapshots returned by locals(), frame.f_locals will be updated to instead return a dedicated proxy type (implemented as a private subclass

[Python-Dev] Does the C-API include C structs not explicitly documented?

Hi everyone, Are C structs part of the C-API if the struct is only included in a header, but not documented? I have always assumed not, but it isn't clear. This question arose in https://github.com/python/cpython/pull/24298 Obviously, any structs listed in

[Python-Dev] Resurrecting PEP 558 (defined semantics for locals())

Hi, PEP 558 seems to be dormant, if not abandoned. There are at least two open issues for bugs resulting from the currently weird and inefficient behavior of `f_locals` and `locals()`. See https://bugs.python.org/issue30744 for an example of undesirable behaviour. PEP 588, or something like

[Python-Dev] Re: PEP 651: Robust Overflow Handling, version 2

Hi Guido, On 22/01/2021 5:20 am, Guido van Rossum wrote: On Wed, Jan 20, 2021 at 9:16 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: I've updated the PEP in light of my experiments and feedback. The new API is simpler and a bit more backwards compatible. https://www.p

[Python-Dev] PEP 651: Robust Overflow Handling, version 2

Hi, I've updated the PEP in light of my experiments and feedback. The new API is simpler and a bit more backwards compatible. https://www.python.org/dev/peps/pep-0651/ Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

uld be a show stopper or similar, but it should be taken into consideration along all the other pros and cons. Regards from cloudy London, Pablo Galindo Salgado On Wed, 20 Jan 2021 at 15:12, Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Pablo, On 19/01/2021 6:46 pm, Pablo

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

Hi Pablo, On 19/01/2021 6:46 pm, Pablo Galindo Salgado wrote: Hi Mark, Thanks for gathering this proposal! Looks very interesting. I have some preliminary questions: how is this going to affect the "py-bt" command of the gdb helpers

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

is here: https://github.com/python/cpython/compare/master...markshannon:pep-overflow-implementation Cheers, Mark. On Tue, Jan 19, 2021 at 5:38 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 4:15 pm, Antoine Pitrou wrote: On Tue, 19 Jan 2021 15:54:39 + Mark Shannon wrote: On 19/01/2021 3:40 pm, Antoine Pitrou wrote: On Tue, 19 Jan 2021 13:31:45 + Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 3:43 pm, Sebastian Berg wrote: On Tue, 2021-01-19 at 13:31 +, Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 3:40 pm, Antoine Pitrou wrote: On Tue, 19 Jan 2021 13:31:45 + Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. On the principle, no objection

[Python-Dev] Re: PEP 651 -- Robust Overflow Handling

On 19/01/2021 2:38 pm, Terry Reedy wrote: On 1/19/2021 8:31 AM, Mark Shannon wrote: Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that machine stack

[Python-Dev] PEP 651 -- Robust Overflow Handling

Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that machine stack overflow is treated differently from runaway recursion. This would allow programs to set

[Python-Dev] Re: 3.10 change (?) for __bool__

Hi Rob, On 13/01/2021 12:18 pm, Rob Cliffe wrote: On 12/01/2021 15:53, Mark Shannon wrote: In master we convert `if x: pass` to `pass` which is equivalent, unless bool(x) has side effects the first time it is called. This is a recent change. Can you please confirm that this optimisation

[Python-Dev] Re: 3.10 change (?) for __bool__

Hi everyone, Should the optimizer eliminate tests that it can prove have no effect on the control flow of the program, even if that may eliminate some side effects in __bool__()? For several years we have converted if a and b: ... to if a: if b: ...

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

Hi Eric, On 23/11/2020 9:32 pm, Eric V. Smith wrote: On 11/23/2020 3:44 PM, David Mertz wrote: I have a little bit of skepticism about the pattern matching syntax, for similar reasons to those Larry expresses, and that Steve Dower mentioned on Discourse. Basically, I agree

[Python-Dev] Re: The semantics of pattern matching for Python

guess about what the other authors of 634-636 would agree, but they may correct me if I'm wrong. On Mon, 16 Nov 2020 at 14:44, Mark Shannon <mailto:m...@hotpy.org>> wrote: (...) I believe that a pattern matching implementation must have the following properties: * T

[Python-Dev] Preconditions for accepting any pattern matching PEP

Hi, I'd like to request that any pattern matching PEP and its implementation meet certain standards before acceptance. As one of the maintainers of the AST-to-bytecode part of the compiler and the bytecode interpreter, I don't want to be in the situation where we are forced to accept a

[Python-Dev] Re: The semantics of pattern matching for Python

rbitrary" to "preserving insertion order") and can be done later one I think it is important that *all* implementations, including the first, respect the exact semantics as defined. The first implementation should be reasonably efficient, but doesn't have to be super q

[Python-Dev] Re: The semantics of pattern matching for Python

nd I don't think it will. I'm not familiar enough with ever corner of PEP 634 to do that. I could add a general "how to" guide though. It fairly straightforward conceptually but, as you know, the devil is in the details. Cheers, Mark. --Guido On Mon, Nov 16, 2020 at 6:41 AM Ma

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

globals and function-locals, class-locals and non-locals are unchanged. I'd probably want to emit a syntax warning for non-locals, as the semantics are a bit weird). Cheers, Mark. On 17/11/2020 9:55 am, Mark Shannon wrote: Hi, I'm wondering why ``` x = "value" try:     1/0 except Exce

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

On 17/11/2020 10:22 am, Cameron Simpson wrote: On 17Nov2020 09:55, Mark Shannon wrote: I'm wondering why ``` x = "value" try: 1/0 except Exception as x: pass ``` does not restore "value" to x after the `except` block. Because the except is not a new scope.

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

Hi Chris, On 17/11/2020 11:03 am, Chris Angelico wrote: On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote: `try...except` is no different. ... The only wrinkle in the case of `try...except` is that the error variable is deleted, even if it wasn't actually used. If you look at the

[Python-Dev] Why does "except Ex as x" not restore the previous value of x?

Hi, I'm wondering why ``` x = "value" try: 1/0 except Exception as x: pass ``` does not restore "value" to x after the `except` block. There doesn't seem to be an explanation for this behavior in the docs or PEPs, that I can find. Nor does there seem to be any good technical reason

[Python-Dev] The semantics of pattern matching for Python

Hi everyone, There has been much discussion on the syntax of pattern matching for Python (in case you hadn't noticed ;) Unfortunately the semantics seem to have been somewhat overlooked. What pattern matching actually does seems at least as important as the syntax. I believe that a

[Python-Dev] Questions about about the DLS 2020

Hi Tobias, A couple of questions about the DLS 2020 paper. 1. Why do you use the term "validate" rather than "test" for the process of selecting a match? It seems to me, that this is a test, not a validation, as no exception is raised if a case doesn't match. 2. Is the error in the ast

[Python-Dev] Re: Speeding up CPython

Hi Thomas, I have to assume that this isn't a rejection of my proposal, since I haven't actually made a proposal to the SC yet :) Thanks for the feedback though, it's very valuable to know the SC's thinking on this matter. I have a few comments inline below. On 04/11/2020 12:27 pm,

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

Hi Brandt, On 30/10/2020 4:09 pm, Brandt Bucher wrote: Can we discuss whether we want pattern matching in Python and the broader semantics first, before dealing with low level details? This is a huge step backward. These discussions have already taken place, over the last 10 years. So

[Python-Dev] Thoughts on PEP 634 (Structural Pattern Matching)

Hi everyone, PEP 634/5/6 presents a possible implementation of pattern matching for Python. Much of the discussion around PEP 634, and PEP 622 before it, seems to imply that PEP 634 is synonymous with pattern matching; that if you reject PEP 634 then you are rejecting pattern matching.

[Python-Dev] Re: Accepting PEP 626

Hi Pablo, On 29/10/2020 11:08 am, Pablo Galindo Salgado wrote: > The new semantics may well result in some slowdowns. That's stated in the PEP.I don't think I can reliably isolate the effects of the (very slight) change in the behavior of f_lineno. Ok, then let's make at least we measure

[Python-Dev] Re: Accepting PEP 626

no) def test(): print_line() sys._getframe(0).f_trace = True print_line() print_line() test() $ python3.9 ~/test/test.py 7 8 8 With PEP 626 this is required to print: 7 9 10 Cheers, Mark. Cheers, Pablo On Thu, 29 Oct 2020, 09:47 Mark Shannon, &

[Python-Dev] Re: Accepting PEP 626

is the case before merging the    implementation (with the pyperformance test suite, for example). Performance compared to what? The current behavior of `f_lineno` is ill-defined, so mimicking it would be tricky. What's the reason for supposing that it will be slower? Cheers, Mark. Congratu

  1   2   3   4   5   >