[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/Tools/gdb/lib

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

don't imply that this should 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,

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

[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] 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] 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 https://docs.python.org/3/c-api/st

[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] 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] 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] 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] 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: 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... I

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

[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: 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] 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 reada

[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 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] 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 t

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

[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] 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 whatever

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

[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. The

[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] 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: >> > > Hi

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

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

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

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 otherwis

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

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 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 for

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

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 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: 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] 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 object

[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` quacked

[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] 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 offe

[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] 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 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] 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. --- The

[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] 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] 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] 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] 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 implie

[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] 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] 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 wast

[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] 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()` but

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

[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] 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 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] Semantics of __int__(), __index__()

Hi all, I was looking into http://bugs.python.org/issue17576 and I found that the semantics of __int__() and __index__() are not precisely defined in the documentation and that the implementation (CPython 3.4a) has some odd behaviour. Defining two classes: class Int1(int): def __init__(

Re: [Python-Dev] Semantics of __int__(), __index__()

On 02/04/13 01:44, Nick Coghlan wrote: On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson mailto:dicki...@gmail.com>> wrote: As written, int_check would do the wrong thing for bools, too: I definitely want int(True) to be 1, not True. For (2) and (4), it's not so clear. Are there u

Re: [Python-Dev] cpython: Introduce importlib.util.ModuleManager which is a context manager to

On 29/05/13 01:14, Brett Cannon wrote: On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote: On Tue, 28 May 2013 23:29:46 +0200 (CEST) brett.cannon wrote: +.. class:: ModuleManager(name) + +A :term:`context manager` which provides the module to load. The module will +either come

Re: [Python-Dev] PEP 450 adding statistics module

On 15/08/13 14:08, Steven D'Aprano wrote: On 15/08/13 21:42, Mark Dickinson wrote: The PEP and code look generally good to me. I think the API for median and its variants deserves some wider discussion: the reference implementation has a callable 'median', and variant callables 'median.low',

Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.

On 17/08/13 19:42, Antoine Pitrou wrote: On Sat, 17 Aug 2013 11:32:00 +0200 (CEST) raymond.hettinger wrote: http://hg.python.org/cpython/rev/2c9a2b588a89 changeset: 85218:2c9a2b588a89 user:Raymond Hettinger date:Sat Aug 17 02:31:53 2013 -0700 summary: Use a known unique o

Re: [Python-Dev] PEP 447: add type.__locallookup__

I'll look into it this evening. On 09/09/13 17:03, Guido van Rossum wrote: OK, how much time do you need? --Guido van Rossum (sent from Android phone) On Sep 9, 2013 8:44 AM, "Mark Shannon" mailto:m...@hotpy.org>> wrote: I would like time to investigate this further

Re: [Python-Dev] PEP 447: add type.__locallookup__

I would like time to investigate this further, but at the moment I think it will either make attribute lookup poorly defined or slow. Of the top of my head, the problem as a I see it is basically this: Currently, type.__getattribute__() is a fixed point in the lookup of attributes. The proposal

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 09/09/13 15:30, Ethan Furman wrote: On 07/30/2013 11:17 PM, Ronald Oussoren wrote: And something I forgot to ask: is anyone willing to be the BDFL-Delegate for PEP 447? *Bump*. It would be nice if this could make into 3.4. IMO, there are some issues that need to be addressed before PEP

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 09/09/13 22:25, Benjamin Peterson wrote: 2013/9/9 Mark Shannon : On 09/09/13 15:30, Ethan Furman wrote: On 07/30/2013 11:17 PM, Ronald Oussoren wrote: And something I forgot to ask: is anyone willing to be the BDFL-Delegate for PEP 447? *Bump*. It would be nice if this could make

Re: [Python-Dev] PEP 455: TransformDict

On 14/09/13 23:31, Eli Bendersky wrote: On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote: 14.09.13 20:41, Antoine Pitrou написав(ла): No good reason. What's the name? transform_func? transform_func looks... truncated. Why not transform_fu

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 09/10/13 00:33, Larry Hastings wrote: I've contributed a new PEP to humanity. I include the RST for your reading pleasure below, but you can also read it online here: http://www.python.org/dev/peps/pep-0457/ Overall I'm in favour. As a motivation for positional only parameters, consi

Re: [Python-Dev] frame evaluation API PEP

On 19/06/16 18:29, Brett Cannon wrote: On Sat, 18 Jun 2016 at 21:49 Guido van Rossum mailto:gu...@python.org>> wrote: Hi Brett, I've got a few questions about the specific design. Probably you know the answers, it would be nice to have them in the PEP. Once you're happy with m

Re: [Python-Dev] Idea: more compact, interned string key only dict for namespace.

Hi all, I think we need some more data before going any further reimplementing dicts. What I would like to know is, across a set of Python programs (ideally a representative set), what the proportion of dicts in memory at any one time are: a) instance dicts b) other namespace dicts (classe

[Python-Dev] Please reject or postpone PEP 526

Hi everyone, I think we should reject, or at least postpone PEP 526. PEP 526 represents a major change to the language, however there are, I believe, a number of technical flaws with the PEP. It is probable that with significant revisions it can be a worthwhile addition to the language, but

Re: [Python-Dev] Please reject or postpone PEP 526

On 02/09/16 19:04, Steven D'Aprano wrote: On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote: A good checker should be able to infer that x is a union type at the point that it's passed to spam, even without the type annotation. For example: def eggs(cond:bool): if cond:

Re: [Python-Dev] Please reject or postpone PEP 526

On 02/09/16 19:19, Steven D'Aprano wrote: On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote: "I'm not seeing what distinction you think you are making here. What distinction do you see between: x: int = func(value) and x = func(value) #type: int" Not sure whether I agree w

Re: [Python-Dev] Please reject or postpone PEP 526

On 02/09/16 20:33, Guido van Rossum wrote: On Fri, Sep 2, 2016 at 10:47 AM, Steve Dower wrote: "I'm not seeing what distinction you think you are making here. What distinction do you see between: x: int = func(value) and x = func(value) # type: int" Not sure whether I agree with

Re: [Python-Dev] Please reject or postpone PEP 526

On 04/09/16 11:57, Chris Angelico wrote: On Sun, Sep 4, 2016 at 8:52 PM, Mark Shannon wrote: The key difference is in placement. PEP 484 style variable = value # annotation Which reads to me as if the annotation refers to the value. PEP 526 variable: annotation = value Which reads very

Re: [Python-Dev] Please reject or postpone PEP 526

On 04/09/16 21:16, Guido van Rossum wrote: Everybody please stop panicking. PEP 526 does not make a stand on the behavior of type checkers (other than deferring to PEP 484). If you want to start a discussion about constraining type checkers please do it over at python-ideas. There is no rush as

[Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Hi, PEP 526 states that "This PEP aims at adding syntax to Python for annotating the types of variables" and Guido seems quite insistent that the declarations are for the types of variables. However, I get the impression that most (all) of the authors and proponents of PEP 526 are quite keen

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On 05/09/16 23:16, Greg Ewing wrote: Mark Shannon wrote: Unless of course, others may have a different idea of what the "type of a variable" means. To me, it means it means that for all assignments `var = expr` the type of `expr` must be a subtype of the variable, and for all u

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On 05/09/16 18:40, Guido van Rossum wrote: On Mon, Sep 5, 2016 at 8:26 AM, Mark Shannon wrote: PEP 526 states that "This PEP aims at adding syntax to Python for annotating the types of variables" and Guido seems quite insistent that the declarations are for the types of variables

Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?

On 24/05/17 11:07, Ben Hoyt wrote: Hi folks, I was looking at some `dis` output today, and I was wondering if anyone has investigated optimizing Python (slightly) by adding special-case bytecodes for common expressions or statements involving constants? [snip] Hi Ben, What you are suggesting

Re: [Python-Dev] PEP 544: Protocols - second round

On 24/05/17 14:31, Ivan Levkivskyi wrote: Hi all, After collecting suggestions in the previous discussion on python-dev https://mail.python.org/pipermail/python-dev/2017-March/thread.html#147629 and playing with implementation, here is an updated version of PEP 544. -- Ivan I really like this

Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?

On 25/05/17 03:47, Victor Stinner wrote: Hi Ben, I am not convinced that combining operations will have a significant impact in term of performance. Mark Shanon implemented that in his HotPy project. I don't think that I did ;) HotPy implemented a trace-based optimising interpreter, that pre

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

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

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

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

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

[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: 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 * https://github.com/python/cpyt

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

[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

<    1   2   3   4   5   >