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

e steering council in a month or so. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived

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

nothing new. The bytecode library already recomputes the consts, names, etc. TBH, calling `types.CodeType` didn't work for earlier versions either. It just sort of worked, some of the time. Cheers, Mark. https://github.com/MatthieuDartiailh/bytecode

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

t PEP 523 isn't used. Cheers, Mark. API: * _PyFrameEvalFunction type * _PyInterpreterState_GetEvalFrameFunc() * _PyInterpreterState_SetEvalFrameFunc() * (undocumented) _PyEval_EvalFrameDefault() The private API to get/set the eval function *is* documented at: https://docs.python.org/d

[Python-Dev] Re: PEP 682: Format Specifier for Signed Zero

PEP 682 (Format Specifier for Signed Zero) has been accepted! Please see https://discuss.python.org/t/accepting-pep-682-format-specifier-for-signed-zero/14088 Thanks to all involved, Mark ___ Python-Dev mailing list -- python-dev@python.org To

[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

[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 stumbli

[Python-Dev] Should we require IEEE 754 floating-point for CPython?

x27;s a Py_NO_NAN macro that builders can define to indicate that NaNs aren't supported, but the Python build is currently broken if Py_NO_NAN is defined (see https://bugs.python.org/issue46656). If the answer to the first question is "N

[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: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

rsion by comparing with an obviously-correct repeated-division-by-10 algorithm. Then again I'm not sure what's *lost* even if this optimization is > pointless -- surely it doesn't slow other divisions down enough to be > measurable. > Agreed. That at least is testable. I

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 16, 2022 at 12:08 PM Mark Dickinson wrote: > So gcc is anticipating divisions by 10 and introducing special-case > divide-by-reciprocal-multiply code for that case, and presumably the > profile generated for the PGO backs up this being a common enough case, so > we end

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

tions where you have a divisor not known at compile time but you know you're going to be using it often enough to compensate for the cost of computing the magic multiplier dynamically at run time. [1] https://libdivide.com -- Mark ___ Python-Dev

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sat, Jan 15, 2022 at 8:12 PM Tim Peters wrote: > Something is missing here, but can't guess what without seeing the > generated machine code.But I trust Mark will do that. > Welp, there goes my weekend. :-) $ python -m timeit -n 150 -s "x = 10**1000" "x//

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote: > Division may still be problematic. > On that note: Python divisions are somewhat crippled even on x64. Assuming 30-bit digits, the basic building block that's needed for multi-precision division is a 64-bit-by-32-bit unsig

[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: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

://en.wikipedia.org/wiki/ARM_architecture#Arithmetic_instructions: "ARM supports 32-bit × 32-bit multiplies with either a 32-bit result or 64-bit result, though Cortex-M0 / M0+ / M1 cores don't support 64-bit results.") Division may still be problematic. -- Mark

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

bots": there's a 32-bit Gentoo buildbot that's (implicitly) using 15-bit digits, and the GitHub Actions Windows/x86 build also uses 15-bit digits. I don't think we have anything that's explicitly using the `--enable-big-digits` option, though. -- Mark __

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

0-bit digits, then there's a case for at least making 30-bit digits the default, which would be a first step towards eventually dropping that support. GPS: I'm not immediately seeing the ABI issue. If you're able to dig up more information on that, I'd be interested to see it. Mark

[Python-Dev] Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

it` type, `a + b` can't currently safely (i.e., without undefined behaviour from overflow) be computed with the C type `sdigit`. With 30-bit digits and a 32-bit `digit` and `sdigit` type, `a + b` is safe. Mark *References* Related b.p.o. issue: https://bugs.python.org/issue45569 MinGW compatibili

[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, 20

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

s you are playing code golf, that shouldn't matter. Cheers, Mark. On 16/12/2021 5:57 pm, Steven Troxler wrote: Hello all, Thanks everyone for comments on our earlier thread [1] about callable type syntax. We now have a draft PEP [2] proposing an arrow-based syntax for callable type

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

rmance benchmarks](speed.python.org <http://speed.python.org>), compared to 3.10.0. Actually, it is quite a lot better than that at 19% on the standard benchmark suite :) https://gist.github.com/markshannon/0ddfb0b705d23b863477d7f7f9f00ef1

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

ad the PEP here: https://python.github.io/peps/pep-0669/ Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message a

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

are falsey) Excluding 1 < 2 seems inconsistent. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archi

[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 https://bugs.python.org/issu

[Python-Dev] Re: What is __int__ still useful for?

Meta: apologies for failing to trim the context in the previous post. -- Mark ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org

[Python-Dev] Re: What is __int__ still useful for?

python.org/issue44977 Mark On Thu, Oct 14, 2021 at 11:50 AM Serhiy Storchaka wrote: > 14.10.21 12:24, Eryk Sun пише: > > Maybe an alternate constructor could be added -- such as > > int.from_number() -- which would be restricted to calling __int__(), > > __index__(), and __

[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?

error RC1116: RC terminating after preprocessor errors [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj] Can anyone translate that into English for me? It suggests that there are errors in the preprocessor. But how do I tell what the error is? Cheers,

[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 th

[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, <mailto:gu...@python.org>> wrote: Hopefully anyone is still reading python-dev. I'm going to try to summarize the differences between the two proposals, even thoug

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

558 but is simpler and more consistent internally, at the expense of some minor C API backwards incompatibility issues. PEP 558 also has backwards incompatibility issues, but claims to be more compatible at the C API level. Cheers, Mark. ___ Python

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

ish". We need to say "won't fix" 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 c

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

yEval_GetLocals()` but I think the that is a small price to pay for simplicity and consistency. What do you think? Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://

[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)

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 be an internal implementation detail that we can add or remove depending on requirements. Thoughts? Cheers, Mark. ___ Python-D

[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

[Python-Dev] Comments on PEP 558

f locals Reducing the runtime overhead of trace hooks I'm confused by this part. Since `_PyFrame_FastToLocals` and friends do not alter the logical state of the frame object (or anything else), they should no-ops. It is `PyFrame_GetLocals()` that

[Python-Dev] Critique of PEP 657

d for most functions. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.or

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

interact poorly with debugging and profiling. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived

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

ope and updating the PEP accordingly. But that's just me and I don't know if others agree (hence the reason I'm suggesting this be Standards Track). Suppose it were a standards PEP, what would that mean if it were rejected? Rejection of a PEP is a choice in favor of an alternative

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

piler can't perform some optimizations due the constraints of providing the extended debug information. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.or

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

lob/master/tiers.md#tier-0 A few bytes more or less in the location table(s) is inconsequential. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/li

[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 in

[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 the

[Python-Dev] PEP 659: Specializing Adaptive Interpreter

offers better interpreter performance and is more suitable to a collaborative, open-source development model. As always, comments and suggestions are welcome. Cheers, Mark. Links: https://www.python.org/dev/peps/pep-0659/ https://github.com/facebookincubator/cinder https://github.com/pyston

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

https://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: ..

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

em as useful tools, not warp the rest of the language to fit them. Cheers, Mark. Quick summaries of type systems: https://en.wikipedia.org/wiki/Nominal_type_system https://en.wikipedia.org/wiki/Structural_type_system https://en.wikipedia.org/wiki/Duck_typing Or, if you're reall

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

ssion and maybe for us to implement some of the above "ideal implementation". Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailma

[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 deprecat

[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'

[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-in

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

unately, this is not what is implemented. E.g. `case int(1, real=1):` is accepted and works, as does `case int(real=0):`. Calling out Brandt to get his opinion. And thanks to Mark for finding these! The current implementation will reject any attribute being looked up more than once, by position

[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 har

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

icitly stating that it is *not* a container. Seq explicitly states that it *is* a sequence. So Child is just broken. That it is broken for pattern matching is consistent with it being broken in general. Cheers, Mark. ___ Python-Dev mailing list --

[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

[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)

Hi Guido, Thanks for the feedback. On 27/03/2021 10:15 pm, Guido van Rossum wrote: Hi Mark, Reading that spec will take some time. Can you please summarize the differences in English, in a way that is about as precise as PEP 634? I have some comments inline below as well. On Sat, Mar 27

[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 exten

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

those corner cases where there is a difference, it is to make pattern matching more robust. E.g. With PEP 653, pattern matching will work in the collections.abc module. With PEP 634 it does not. As always, all thoughts and comments are welcome. Cheers,

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

ircumstances it can make a lot of sense to do so, since the caller has probably finished with the reference and the callee needs a new one. Cheers, Mark. On 25/03/2021 4:27 pm, Victor Stinner wrote: Hi, A new Include/README.rst file was just added to document the 3 C API provided by CPyt

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

t;main". From a user's perspective the "main" branch is whatever their version of Python is built from. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https:

[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

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

? On 03/03/2021 7:19 pm, Python Steering Council wrote: Hi Mark, Thank you for submitting PEP 651. The Steering Council has spent the past two weeks reviewing PEP 651. After careful consideration, we have decided to reject the PEP. The following were the key points that led us to this decision

[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 this is

[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 th

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

h_kind__ = MATCH_DEFAULT` allows for arbitrary attribute extraction like this. Perhaps make it bit clearer? Not quite. It uses the instance dictionary to avoid capturing bound methods and other computed attributes. I'll make this more prominent. Cheers, Mark.

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

ually). The syntax is unchanged, and in most cases the semantics are the same. As always, comments and suggestions are welcome. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

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

s. Finally, I would ask for a change of name. The "Type" part is redundant, since it is a type annotation, and the "Guard" part is incorrect. It is only a guard when used, the function itself is a predicate that narrows the type of an argument. "Narrows" or &quo

[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

s, than one giant one with context-dependent behaviour. We have spent quite a lot of effort over the last few years streamlining the interpreter. Adding these extremely complex instructions would be a big backward step. Cheers, Mark. ___ Python-Dev maili

[Python-Dev] Re: Comments on PEP 558

**add new keys** to frame.f_locals, I am actually quite happy. Out of interest, why would you want to add new keys to the locals of a function frame? The function will never be able to use those values. The potential incompatibility Mark is referring to is the fact that even optimised f

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

be trusted, but that the test isn't testing the dis module at all. It is testing whether the output from the compiler has changed. A lot of the tests in test_dis do that. Cheers, Mark. Skip ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] More comments on PEP 558

return, as the f_locals field needs to be initialized on call and checked for non-NULL on return. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org

[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, and

[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 snapshot

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

good reason not to start using C11 now? Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at

[Python-Dev] Comments on PEP 558

fixing the bugs it proposes to fix. Why not just make `f_local` a direct view on the underlying frame? It would be simpler to understand, more robust, and should perform better. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsu

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

c-api/structures.html are part of the API Thoughts? Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archiv

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

ove this distinction. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.pytho

[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://

[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 unsubs

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

API, or requesting an alternative interface should the API be insufficient, then they can't really complain. Notice as well that the gdb helpers *are* an out-of-process tool. True, but they are in the standard library, so they are our responsibility to fix. Cheers, Mark. Of course, I

[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 (https://github.com/python/cpython/blob/master

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

erflow 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,

[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 smal

[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 PE

[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

[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 tha

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

a StackOverflow, without causing a VM crash: sys.setrecursionlimit(1_000_000) class X: def __add__(self, other): return self + other X() + 1 --- The full PEP can be found here: https://www.python.org/dev/peps/pep-0651 As always, comments are welcome

[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__

n the semantics" bugs. Submit your thoughts to https://bugs.python.org/issue42899, please. Cheers, Mark. On 12/01/2021 12:45 am, Guido van Rossum wrote: Ah never mind. Seems to be a real bug -- thanks for reporting! On Mon, Jan 11, 2021 at 2:57 PM Mats Wichmann <mailto:m...@wichma

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

ontents are visible to IDEs and editors. if m.case("StringNode(s)"): the pattern is just a string. case!(StringNode(s)): the pattern is validated Python syntax. 2. The transformation is done at compile time, so the generated code will execute in the correct context. B

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

On 20/11/2020 6:57 pm, Tobias Kohn wrote: Hi Daniel and Mark, Sorry for being slightly late to the party, but please let me add a few remarks of my own to the discussion here. *1. Must have precisely defined semantics* Yes, there are some aspects that we left open intentionally.  Most

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

o be slow. Knowing that there exists an efficient implementation, and how to achieve it, is important. Ideally the initial implementation should be efficient, but knowing that it could be is sufficient for acceptance. Cheers, Mark. ___ Python-De

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

Hi Daniel, On 20/11/2020 10:50 am, Daniel Moisset wrote: Hello again Mark, I took some time looking in more detail at your proposal, and these are my thoughts. I'm writing with the assumption that this proposal describes some "internal" representation of match statements

  1   2   3   4   5   6   7   8   9   10   >