[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-09-09 Thread Nick Coghlan
* to argue over names (the > > last stage of anything) but I do need to point out how that sounds to > > read". > > > https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ > > > > That's why I proposed: b

[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-09-09 Thread Nick Coghlan
t* look like the inverse operation for `int.from_bytes` was one advantage of calling the method `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC is right that `bytes.fromint` is a more comprehensible method name overall. -- Nick Coghlan | ncogh...@gmail.com | Bri

[Python-Dev] Re: PEP-535 (Rich comparison chaining) Discussion?

2021-09-01 Thread Nick Coghlan
On Wed, 1 Sep 2021, 7:18 am Senthil Kumaran, wrote: > On Tue, Aug 31, 2021 at 8:57 AM Angus Hollands wrote: > > >> Should look more like >> ```python >> x = np.array(...) >> y = x[2 < x < 8] >> ``` >> Is there any interest in pushing this PEP along? >> > > My personal opinion is, it is worth

[Python-Dev] Re: Making code object APIs unstable

2021-09-01 Thread Nick Coghlan
On Thu, 2 Sep 2021, 7:08 am Victor Stinner, wrote: > I saw Python projects injecting fake frames for XML and JSON parsers, > maybe also configuration file (.ini?) parsers. So text files which > have line numbers ;-) > > On Wed, Sep 1, 2021 at 7:33 PM Pablo Galindo Salgado > wrote: > > I don't

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

2021-09-01 Thread Nick Coghlan
On Tue, 31 Aug 2021, 2:52 am Brett Cannon, wrote: > > On Sun, Aug 29, 2021 at 2:01 PM Serhiy Storchaka > wrote: > >> >> > So my question is whether the discrepancy between what `async for` >> > expects and what `aiter()` expects on purpose? >> > https://bugs.python.org/issue31861

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

2021-08-26 Thread Nick Coghlan
On Fri, 27 Aug 2021, 2:33 am Guido van Rossum, wrote: > On Thu, Aug 26, 2021 at 2:31 AM Nick Coghlan wrote: > >> On Thu, 26 Aug 2021 at 18:29, Nick Coghlan wrote: >> [Guido wrote] >> > > PS. The mapping from varname to position should be on the code >> o

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

2021-08-26 Thread Nick Coghlan
f we make it work the same way as PyEval_LocalsToFast() works today. Specifically, it can reach out and clear cells in outer frames, including the __class__ cell used by zero-arg super(). I can't see anyone being super upset if we decide to change that and say that proxy.clear() leaves free variab

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

2021-08-26 Thread Nick Coghlan
On Thu, 26 Aug 2021 at 18:29, Nick Coghlan wrote: [Guido wrote] > > PS. The mapping from varname to position should be on the code object, not > > on the frame. This is how Mark does it (though his implementation would > > need to be extended to take cells into account). >

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

2021-08-26 Thread Nick Coghlan
gh his implementation would need to > be extended to take cells into account). It's taking cells into account that forces the lookup mapping to be on the frame: different executions of the same code object may reference different cell objects. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.

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

2021-08-21 Thread Nick Coghlan
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 did so in his PEP. But I'd like to start by > calling out the key point of contention. >

[Python-Dev] Re: Making code object APIs unstable

2021-08-16 Thread Nick Coghlan
On Tue, 17 Aug 2021, 4:30 am Guido van Rossum, wrote: > On Mon, Aug 16, 2021 at 9:30 AM Steve Dower > wrote: > >> On 8/16/2021 12:47 AM, Guido van Rossum wrote: >> > My current proposal is to issue a DeprecationWarning in PyCode_New() >> and >> > PyCode_NewWithPosArgs(), which can be turned

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

2021-08-14 Thread Nick Coghlan
"f_locals" is retrieved from the frame object. We still have plenty of time before 3.11b1, so we expect it will be a month or two before the two proposals are in a position to be compared directly. Cheers, Nick. On Fri, 30 Jul 2021, 5:25 pm Nick Coghlan, wrote: > > > On Fri, 3

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

2021-07-30 Thread Nick Coghlan
On Fri, 30 Jul 2021, 2:30 pm Nathaniel Smith, wrote: > > > > > For [proxy] versus [snapshot], a lot depends on what we think of > changing the semantics of exec(). [proxy] is definitely more consistent and > elegant, and if we could go back in time I think it's > what we'd have done from the

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

2021-07-29 Thread Nick Coghlan
On Fri, 30 Jul 2021, 6:05 am Mark Shannon, wrote: > 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

[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-07-29 Thread Nick Coghlan
On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote: > > Hello Nick, Ethan, > > The Python Steering Council reviewed PEP 467 -- Minor API improvements for > binary sequences at our 2021-07-26 meeting. > > Thank you for work on this PEP. We’re generally very favorable for adding > to Python 3.11

[Python-Dev] Re: Comments on PEP 558

2021-07-28 Thread Nick Coghlan
On Wed, 28 Jul 2021, 8:13 pm Mark Shannon, wrote: > > > 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, &g

[Python-Dev] Re: Comments on PEP 558

2021-07-27 Thread Nick Coghlan
On Wed, 28 Jul 2021, 1:50 am Mark Shannon, wrote: > Hi Nick, > > On 27/07/2021 2:29 pm, Nick Coghlan wrote: > > > > > > The reference documentation should be precise as well, since that is > > what other implementations will be following. > > > > Wh

[Python-Dev] Re: Comments on PEP 558

2021-07-27 Thread Nick Coghlan
else implicitly refresh the cache before relying on it (e.g. copying the proxy mapping works by refreshing the frame cache, then copying the cache). I assume there will be ways to improve the implementation to make explicit frame cache refreshes less necessary over time (hence the caveat along th

[Python-Dev] Re: types.Union or types.UnionType?

2021-07-25 Thread Nick Coghlan
On Sun, 25 Jul 2021, 9:26 pm Serhiy Storchaka, wrote: > In 3.10 the union type (the type of the result of the | operator for > types) was added (https://www.python.org/dev/peps/pep-0604/). It is > exposed as types.Union. There are differences between typing.Union and > types.Union: > > *

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

2021-07-23 Thread Nick Coghlan
On Sat, 24 Jul 2021, 9:37 am Larry Hastings, wrote: > > On 7/23/21 7:38 AM, Petr Viktorin wrote: > > (In both C & C++, the size of an `enum` is implementation-defined. That's > unlikely to be a problem in practice, but one more point against enum.) > > > True, but there's always the old trick of

[Python-Dev] Re: Bug report

2021-07-23 Thread Nick Coghlan
On Fri, 23 Jul 2021, 2:22 am Ee Durbin, wrote: > On Wed, Jul 21, 2021 at 7:45 PM Kyle Stanley wrote: > >> On Wed, Jul 21, 2021 at 12:19 PM Nguyen Do Minh Duc < >> gd.minhduc1...@gmail.com> wrote: >> >>> Hi, >>> >>> When I find what's new in 3.10 beta in >>>

[Python-Dev] Re: Bug report

2021-07-22 Thread Nick Coghlan
On Thu, 22 Jul 2021, 9:47 am Kyle Stanley, wrote: > On Wed, Jul 21, 2021 at 12:19 PM Nguyen Do Minh Duc < > gd.minhduc1...@gmail.com> wrote: > >> Hi, >> >> When I find what's new in 3.10 beta in >> https://docs.python.org/whatsnew/3.10.html >> It redirected me to

[Python-Dev] Re: PEP 558: Defined semantics for locals()

2021-07-22 Thread Nick Coghlan
On Thu, 22 Jul 2021, 6:01 pm Petr Viktorin, wrote: > > > On 21. 07. 21 14:18, Nick Coghlan wrote: > > On Mon, 19 Jul 2021 at 21:32, Petr Viktorin wrote: > >> The proposal assumes that in the future, ``PyLocals_Get``, and thus > >> ``locals()``, will never

[Python-Dev] Re: RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

2021-07-21 Thread Nick Coghlan
> behavior, while the last shows the final result: Since the enum output changes were reverted for 3.10, replacing "3.9" with "3.10" in the tables may make it a little clearer that there was no intermediate step between 3.9 and 3.11. Cheers, Nick. -- Nick Coghlan | nc

[Python-Dev] Re: PEP 558: Defined semantics for locals()

2021-07-21 Thread Nick Coghlan
the associated PEP changes to the review PR at https://github.com/python/peps/pull/2038/files Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an em

[Python-Dev] Re: PEP 558: Defined semantics for locals()

2021-07-21 Thread Nick Coghlan
On Wed, 21 Jul 2021, 10:30 am Guido van Rossum, wrote: > On Tue, Jul 20, 2021 at 4:52 AM Nick Coghlan wrote: > [Petr] > >> >> int PyLocals_GetReturnBehavior(); # better name? >> > [Nick] > >> > We've used "Kind" for similar APIs elsewhere,

[Python-Dev] Re: PEP 558: Defined semantics for locals()

2021-07-20 Thread Nick Coghlan
On Mon, 19 Jul 2021 at 22:08, Nick Coghlan wrote: > On Mon, 19 Jul 2021, 9:32 pm Petr Viktorin, wrote: >> The proposal assumes that in the future, ``PyLocals_Get``, and thus >> ``locals()``, will never gain another kind of return value, however >> unlikely that is. >

[Python-Dev] Re: PEP 558: Defined semantics for locals()

2021-07-19 Thread Nick Coghlan
On Mon, 19 Jul 2021, 9:32 pm Petr Viktorin, wrote: > Thanks, Nick! This looks wonderful. > I do have a nitpick, below: > > On 18. 07. 21 7:59, Nick Coghlan wrote: > [...]> > > Changes to the stable C API/ABI > > --- > > >

[Python-Dev] PEP 558: Defined semantics for locals()

2021-07-18 Thread Nick Coghlan
haven't been merged to the web version yet. Suggested clarifications to the text of the PEP that don't affect the overall design can be added as comments on that PR rather than being added to the mailing list thread. = PEP: 558 Title: Defined semantics for locals() Autho

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-30 Thread Nick Coghlan
On Tue, 29 Jun 2021, 12:45 am Ethan Furman, wrote: > On 6/28/21 6:54 AM, Nick Coghlan wrote: > > > * Enum repr() changing back to the historical behaviour, unless you opt > in to the > > new behaviour with the global enum decorator: definite +1 here > > Quest

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Nick Coghlan
On Mon, 28 Jun 2021, 11:54 pm Nick Coghlan, wrote: > So my vote would be to revert both the repr() and str() changes on IntEnum > (et al) for 3.10, and then switch to the new str() approach for those > classes in 3.11. > Sorry, I missed including the requested rationale: * if the

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

2021-06-28 Thread Nick Coghlan
On Mon, 28 Jun 2021, 6:02 pm Ethan Furman, wrote: > I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum > str() in 3.10 and another in 3.11 is less than > ideal, so this new thread is to collect comments about Enum and it's str() > and repr() and whether the changes take >

[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

2021-06-27 Thread Nick Coghlan
On Mon, 28 Jun 2021, 12:44 am Nick Coghlan, wrote: > > For the other proposal, I think you're stuck from a backwards > compatibility point of view - the default needs to be the current > behaviour, with some way to opt out of using the symbolic str > representation. >

[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

2021-06-27 Thread Nick Coghlan
On Thu, 24 Jun 2021, 12:58 pm Ethan Furman, wrote: > TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be > `int.__str__` > > IntEnum and IntFlag are becoming more common in the stdlib. They > currently show up in > > * http > * re > * signal > * ssl > * socket > > to name

[Python-Dev] Re: Proposal: declare "unstable APIs"

2021-06-07 Thread Nick Coghlan
On Fri, 4 Jun 2021, 4:17 am Gregory P. Smith, wrote: > Overall agreement. Your list of ast and code objects and bytecode > instructions are things that I'd _hope_ people already consider unstable so > declaring them as such just makes sense if we're not doing that already. > Another example of

[Python-Dev] Re: name for new Enum decorator

2021-05-29 Thread Nick Coghlan
On Sat, 29 May 2021, 7:27 am Ethan Furman, wrote: > On 5/28/21 12:43 AM, Petr Viktorin wrote: > > On 28. 05. 21 5:24, Ethan Furman wrote: > > >> class FlagWithMasks(IntFlag): > >> DEFAULT = 0x0 > >> > >> FIRST_MASK = 0xF > >> FIRST_ROUND = 0x0 > >>

[Python-Dev] Re: March Steering Council update.

2021-05-18 Thread Nick Coghlan
Thanks for the update! I know this request is a little ironic coming from me, but would it be possible to state the PEP titles the first time they're mentioned each month? Cross referencing is a little awkward when reading the summary on a phone rather than a full computer. Cheers, Nick. On

[Python-Dev] Re: Using FutureWarning for last version before deletion.

2021-05-15 Thread Nick Coghlan
On Tue, 11 May 2021, 7:57 pm Petr Viktorin, wrote: > > > On 11. 05. 21 11:08, Inada Naoki wrote: > > On Tue, May 11, 2021 at 5:30 PM Petr Viktorin wrote: > >> > >> Test tools should treat DeprecationWarning as error by default [0][1]. > >> So even if end users don't really see it, I don't

[Python-Dev] Re: Speeding up CPython

2021-05-14 Thread Nick Coghlan
On Fri, 14 May 2021, 1:47 am Stéfane Fermigier, wrote: > > > On Thu, May 13, 2021 at 8:42 AM Abdur-Rahmaan Janhangeer < > arj.pyt...@gmail.com> wrote: > >> Actual quote by "a Python Software Foundation fellow and contrib- >> utor to Python infrastructure projects" >> > > Ah, this is what you

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

2021-05-14 Thread Nick Coghlan
On Sat, 15 May 2021, 5:39 am Tal Einat, wrote: (snip useful feature summary) The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is > what I've been using for years, and I now think that it isn't good > enough. This not having a nice repr is what started this thread. > > I'd also

[Python-Dev] Re: Can't sync cpython main to my fork

2021-05-07 Thread Nick Coghlan
On Fri, 7 May 2021, 8:13 am Ethan Furman, wrote: > On 5/6/21 7:14 AM, Jelle Zijlstra wrote: > > > Maybe others have different workflows, but I don't see much of a need > > for keeping your fork's main branch up to date. > > I will occasionally do a `git push origin main` just to shut up the >

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

2021-05-07 Thread Nick Coghlan
On Sat, 8 May 2021, 8:53 am Pablo Galindo Salgado, wrote: > > One thought: could the stored column position not include the > indentation? Would that help? > > The compiler doesn't have access easy access to the source unfortunately > so we don't know how much is the indentation. This can make

[Python-Dev] Re: On the migration from master to main

2021-05-07 Thread Nick Coghlan
On Tue, 4 May 2021, 10:50 am Łukasz Langa, wrote: > > On 4 May 2021, at 02:04, Łukasz Langa wrote: > > Having renamed the branch in my fork first, the exact sequence I used on > my own clone was: > > ❯ git checkout master > ❯ git branch -m master main > ❯ git fetch origin > ❯ git branch -u

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

2021-04-24 Thread Nick Coghlan
On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, wrote: > > So I now suspect that my knee-jerk answer is wrong. Am I going too far > down the rabbit hole? Should I *just* make the change for user classes > and leave builtin classes untouched? What do you think? > I'd suggest kicking the can down

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

2021-04-23 Thread Nick Coghlan
On Fri, 23 Apr 2021, 12:34 pm Inada Naoki, wrote: > > I think using ABC to distinguish sequence or mapping is a bad idea. > > There are three policies: > > a) Use duck-typing; just us it as sequence. No type check at all. > b) Use strict type checking; isinstance(x, list) / isinstance(x, (list,

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

2021-04-23 Thread Nick Coghlan
On Sat, 24 Apr 2021, 10:02 am Skip Montanaro, wrote: > > Practically speaking, one issue I have is how easy it is to write >> isinstance or issubclass checks. It has historically been much more >> difficult to write and maintain a check that something looks like a duck. >> >> `if hasattr(foo,

[Python-Dev] Re: Relaxing the annotation syntax

2021-04-17 Thread Nick Coghlan
On Mon, 12 Apr 2021, 1:48 pm Guido van Rossum, wrote: > > At the very least I recommend that the SC take this into account when they > consider PEP 649. Accepting it has some nice benefits when it comes to the > scoping rules for annotations -- but it would forever close the door for > the

[Python-Dev] Re: How about using modern C++ in development of CPython ?

2021-04-17 Thread Nick Coghlan
On Sun, 18 Apr 2021, 2:47 am Antoine Pitrou, wrote: > On Sun, 18 Apr 2021 02:13:57 +1000 > Nick Coghlan wrote: > > > > If > > they want automatic resource management, then we want them working out > how > > to lift the affected code out of C and into Python (for

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

2021-04-17 Thread Nick Coghlan
On Sun, 18 Apr 2021, 1:59 am Jelle Zijlstra, wrote: > El sáb, 17 abr 2021 a las 8:30, Nick Coghlan () > escribió:. > >> >> Metaclass __prepare__ methods can inject names into the class namespace >> that the compiler doesn't know about, so yeah, it unfortunately has to

[Python-Dev] Re: How about using modern C++ in development of CPython ?

2021-04-17 Thread Nick Coghlan
On Sat, 17 Apr 2021, 3:51 am , wrote: > Guys, the issue is that I most of the time see that somebody used C++ for > one or two times, did not understand it and left with bad taste ... > I've got more than a decade and a half of experience with both C++ (dating back to the relatively low quality

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

2021-04-17 Thread Nick Coghlan
On Fri, 16 Apr 2021, 3:14 pm Larry Hastings, wrote: > > Anyway I assume it wasn't "fixable". The compiler would presumably > already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL > would be cheaper every time for a global or builtin. The fact that it > already doesn't do so

[Python-Dev] Re: PEP-0467: Minor API improvements for binary sequences

2021-04-17 Thread Nick Coghlan
Thanks for picking this back up! The deferral section can go away now that you're actively working on it again, and +1 from me on the resolution of the previously open questions (although I wouldn't be particularly upset if the SC considered bchr redundant, given that "bchr = bytes.fromord" is a

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

2021-04-02 Thread Nick Coghlan
On Wed, 31 Mar 2021 at 11:01, Barry Warsaw wrote: > > Kind of :) > > PEP 648 would definitely allow us to deprecate the executable part of pth > files. I let my own biases leak in to my response because I would like to > find a way to replace the sys.path feature of pth with something much

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

2021-03-30 Thread Nick Coghlan
On Wed, 31 Mar 2021, 3:15 am Barry Warsaw, wrote: > . We would like to eventually go farther, including deprecation of pth > files entirely, but that is outside the scope of this PEP. > Please don't, since that would force everyone to start using PEP 648 just to extend sys.path, which would be

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

2021-03-29 Thread Nick Coghlan
On Mon, 29 Mar 2021, 7:47 pm Mark Shannon, wrote: [Guido wrote] > > > > Also, I think that we should probably separate this out in two separate > > flag sets, one for subjects and one for class patterns -- it is pretty > > confusing to merge the flag sets into a single value when their > >

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Nick Coghlan
On Sun, 28 Mar 2021, 12:34 am Irit Katriel via Python-Dev, < python-dev@python.org> wrote: > > Hi Paul, > > IIUC, you are saying that exception group should not be a builtin type > because it is (1) complex (2) special-purposed. Instead, you propose that > we make exception handling pluggable.

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-26 Thread Nick Coghlan
On Sat, 27 Mar 2021, 9:24 am Guido van Rossum, wrote: > Everyone, > > Given the resounding silence I'm inclined to submit this to the Steering > Council. While I'm technically a co-author, Irit has done almost all the > work, and she's done a great job. If there are no further issues I'll send >

[Python-Dev] Re: Python history: origin of the arrow annotation

2021-03-11 Thread Nick Coghlan
On Fri, 5 Mar 2021, 9:10 pm Steven D'Aprano, wrote: > I was curious how and why return annotations use the arrow `->` symbol, > so I went spelunking into the depths of the Python-Ideas and Python-Dev > mailing lists. > > Much to my surprise, I couldn't find any discussion or debate about it. >

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

2021-02-27 Thread Nick Coghlan
the system path by default, so commands provided by user level package installs didn't work without the user adjusting their PATH. The CPython Windows installer also doesn't adjust PATH by default (for good reasons). And unlike a venv, "python -m" doesn't let you ensure that the code exec

[Python-Dev] Re: [python-committers] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

2021-02-08 Thread Nick Coghlan
On Tue, 9 Feb 2021, 6:21 am Python Steering Council, < steering-coun...@python.org> wrote: > After much deliberation, the Python Steering Council is happy to announce > that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, > collectively known as the Pattern Matching PEPs. We

[Python-Dev] Re: Comments on PEP 558

2021-02-03 Thread Nick Coghlan
On Wed, 3 Feb 2021, 10:16 pm Sven R. Kunze, wrote: > Hi Mark, > > I've been working on a project heavily relying on frame.f_locals. > > Are you planning to remove it? > No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated

[Python-Dev] Re: Comments on PEP 558

2021-01-30 Thread Nick Coghlan
On Sun, 31 Jan 2021 at 14:09, Nick Coghlan wrote: > On Sat, 30 Jan 2021, 10:55 pm Nick Coghlan, wrote: >> On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote: >>> The break in compatibility with locals() seems much more intrusive, yet >>> you are OK with that (as

[Python-Dev] Re: Comments on PEP 558

2021-01-30 Thread Nick Coghlan
On Sat, 30 Jan 2021, 10:55 pm Nick Coghlan, wrote: > > > On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote: > >> >> > >> The break in compatibility with locals() seems much more intrusive, yet >> you are OK with that (as am I). >> > > PyEva

[Python-Dev] Re: Comments on PEP 558

2021-01-30 Thread Nick Coghlan
On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote: > 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 i

[Python-Dev] Re: More comments on PEP 558

2021-01-30 Thread Nick Coghlan
On Sat, 30 Jan 2021, 10:22 pm Mark Shannon, wrote: > 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

[Python-Dev] Re: Comments on PEP 558

2021-01-29 Thread Nick Coghlan
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 writes go to bot

[Python-Dev] Re: Improve CPython tracing performance

2021-01-29 Thread Nick Coghlan
On Wed, 20 Jan 2021 at 19:22, Victor Stinner wrote: > > Reply to an old thread. > > On Sat, Oct 31, 2020 at 8:02 AM Nick Coghlan wrote: > > > Debuggers and profilers usually only care of specific frames or > > > function calls (ex: 10% of function calls or eve

[Python-Dev] Re: Comments on PEP 558

2021-01-29 Thread Nick Coghlan
On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote: > Hi > > It is a lot more complex, because you need to worry about coherency. > 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 writes go to both the frame

[Python-Dev] Re: Comments on PEP 558

2021-01-29 Thread Nick Coghlan
On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, wrote: > > 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

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

2021-01-27 Thread Nick Coghlan
lear that up: https://github.com/python/peps/pull/1783/files Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

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

2021-01-27 Thread Nick Coghlan
Hmm, I need to review the state of my PEP PRs, as what's in the main repo definitely isn't up to date. The tracing mode distinction should be long gone, but is still mentioned in the text on python.org. Cheers, Nick. On Wed, 27 Jan 2021, 10:03 pm Nick Coghlan, wrote: > Note that PEP

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

2021-01-27 Thread Nick Coghlan
Note that PEP 558 already doesn't change behaviour in tracing mode any more though - that idea didn't survive the first round of review. Cheers, Nick. On Wed, 27 Jan 2021, 9:58 pm Nick Coghlan, wrote: > As far as I'm aware, the design is in a potentially acceptable state, I > just stall

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

2021-01-27 Thread Nick Coghlan
As far as I'm aware, the design is in a potentially acceptable state, I just stalled out completely on the boring bits of finishing the implementation of the write-through proxy: * implement & test the rest of the mutable mapping methods * refactor to properly share code with the odict

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

2021-01-16 Thread Nick Coghlan
On Wed, 13 Jan 2021, 12:35 pm Larry Hastings, wrote: > > On 1/12/21 5:28 PM, Brett Cannon wrote: > > The other thing to keep in mind is we are talking about every module, > class, and function getting 64 bytes ... which I bet isn't that much. > > Actually it's only every module and class.

[Python-Dev] Re: __init_subclass__ and metaclasses

2021-01-16 Thread Nick Coghlan
On Tue, 12 Jan 2021, 11:55 am Ethan Furman, wrote: > On 1/7/21 4:56 AM, Nick Coghlan wrote: > > > Both EnumMeta and ABCMeta should probably be relying on `__set_name__` > > for their per-member set up work these days, rather than deferring > > that work unt

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-11 Thread Nick Coghlan
On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky, wrote: > And I patiently continue this thread, hoping that people whose argument > would be along the lines of "I teach Python, and I don't want to teach > my students 2 ways of doing the same thing, and which way use when. Why, > if PEP634 offers

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-09 Thread Nick Coghlan
On Sun, 10 Jan 2021, 2:55 am Paul Moore, wrote: > On Sat, 9 Jan 2021 at 14:54, Nick Coghlan wrote: > > [...] > > And I've already said I'd be fine with making the colon mandatory if the > SC share that view. > > So the response to my comment that omitting the colo

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-09 Thread Nick Coghlan
On Sat, 9 Jan 2021, 8:50 pm Paul Sokolovsky, wrote: > > > > The key difference relative to PEP 634 is that even when the code > > author uses the shorthand form, *readers* will still get at least the > > "as" keyword as a prompt, > > Ok, so let's summarize the alternatives: > > 1. PEP634, which

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-09 Thread Nick Coghlan
On Sun, 10 Jan 2021, 12:54 am Nick Coghlan, wrote: > > > On Sun, 10 Jan 2021, 12:22 am Paul Moore, wrote: > >> On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote: >> >> >> The dictionary destructuring can act as an example. We know Nick's >> position: &

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-09 Thread Nick Coghlan
On Sun, 10 Jan 2021, 12:22 am Paul Moore, wrote: > On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote: > > > So, opposing Nick's proposal on the basis that it "looks like a set" is > > just like opposing set literals on the basis they they "look like a > > dict". > > That's not what I was doing

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-08 Thread Nick Coghlan
On Sat, 9 Jan 2021, 7:07 am Joseph Martinot-Lagarde, wrote: > Paul Sokolovsky wrote: > > Hello, > > On Tue, 5 Jan 2021 20:37:27 +1000 > > Nick Coghlan ncogh...@gmail.com wrote: > > > object(host=as host, port=as port}:", but that > > > couldn't ever

[Python-Dev] Re: __init_subclass__ and metaclasses

2021-01-07 Thread Nick Coghlan
Both EnumMeta and ABCMeta should probably be relying on __set_name__ for their per-member set up work these days, rather than deferring that work until after __new__ returns. Cheers, Nick. ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] Re: __init_subclass__ and metaclasses

2021-01-05 Thread Nick Coghlan
her than a CPython implementation detail, then metaclasses could write: cls_cell = namespace["__classcell__"] @property def defining_class(obj): return cls_cell.get() namespace[defining_class.fget.__name__] = defining_class Cheers, Nick. -- Nick Coghlan | ncogh...@

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-05 Thread Nick Coghlan
On Mon, 4 Jan 2021 at 18:38, Paul Moore wrote: > > On Sun, 3 Jan 2021 at 23:38, Nick Coghlan wrote: > > > > The instance attribute syntax arose from trying to deal with two problems > > from class patterns in PEP 634: > > > > * "ATTR=TARGET" using &

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-03 Thread Nick Coghlan
On Mon, 4 Jan 2021, 4:34 am Ethan Furman, wrote: > On 1/3/21 8:50 AM, Paul Moore wrote: > > > Personally, I read it and was horribly confused. > > >> case object{.host as host, .port as port}: > >> pass > > Leading periods is a big no-go for me, for all the reasons listed

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-03 Thread Nick Coghlan
On Mon, 4 Jan 2021, 2:50 am Paul Moore, wrote: > On Sun, 3 Jan 2021 at 16:26, Barry Scott wrote: > > I read the above and believe I know what it meant without needing to > read the PEP in detail. > > I like that a lot. > > Personally, I read it and was horribly confused. I worked out most of >

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-03 Thread Nick Coghlan
On Mon, 4 Jan 2021, 2:19 am Barry Scott, wrote: > > I quickly read 642 v3 and missed an explanation about why the syntax to > match a string object is > str{} and not str. Are you saying that I MUST use {} so that when case is > parsed its clear that its a class > with no constraints? > Yes.

[Python-Dev] PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-03 Thread Nick Coghlan
ort = optional_port case __ as m: raise TypeError(f"Unknown address format: {m!r:.200}") port = int(port) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list --

[Python-Dev] Re: SC 2020 recommendation for PEP 634

2020-12-12 Thread Nick Coghlan
oks up "x" as an instance attribute and binds "y" as a local variable). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

2020-11-29 Thread Nick Coghlan
On Sun., 29 Nov. 2020, 6:31 am Paul Ganssle, wrote: > Considering the people involved and the nature of the list, I suspect that > adding a new @python.org mailing list would be better than discourse. In > my experience, it's very difficult to just follow a single topic on the > discourse, and

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-15 Thread Nick Coghlan
On Sun., 15 Nov. 2020, 5:25 pm Guido van Rossum, wrote: > But Point(x as a) already has a meaning in PEP 634; it’s a positional > argument captured in x *and* in a. (Previously spelled as Point(a := x). > The phrase ‘as a’ can be added after any pattern to *also* capture it in > ‘a’. More

[Python-Dev] Re: Configure Python initialization (PyConfig) in Python

2020-11-14 Thread Nick Coghlan
s in the current master branch! Nice! I remember the work you put in getting runtime reconfiguration working again for 3.7.1, so it's cool to see that capability maturing even further. > Nick Coghlan recently withdrew his PEP 432 since PEP 587 was rejected. s/rejected/accepted/ :) > It made me

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

2020-11-14 Thread Nick Coghlan
rts to look a bit more strange when matching sequences, though: match seq: case as first, *middle, as last: ... # Or should that be "*as middle"? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-14 Thread Nick Coghlan
ble to a similar solution (i.e. spell the capture patterns for those cases with `as`, not `:` or `=`). Cheers, Nick. P.S. I've started my TODO list for v3 at https://github.com/ncoghlan/peps/issues/6 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-14 Thread Nick Coghlan
irrefutable pattern) case {"x" as a, "y" as b): ... # A mapping with "x" & "y" keys, capturing those to "a" and "b" case {"x":__, "y":__}: ... # A mapping with "x

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-14 Thread Nick Coghlan
es in spelling (double-underscore vs single-underscore for wildcards), or slight changes in how constructs are defined (the inferred constraints for literals and attribute lookups get redefined as syntactic sugar for their explicit counterparts, rather than being first class constructs in their own ri

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-14 Thread Nick Coghlan
38 AM Baptiste Carvello < > devel2...@baptiste-carvello.net> wrote: > >> Hi, >> >> Le 08/11/2020 à 07:47, Nick Coghlan a écrit : >> > Hi folks, >> > >> > I have updated PEP 642 significantly based on the feedback received >> > over the

[Python-Dev] Re: My thoughts on Pattern Matching.

2020-11-12 Thread Nick Coghlan
On Wed., 11 Nov. 2020, 8:10 am Brett Cannon, wrote: > > > On Mon, Nov 9, 2020 at 10:40 PM Tobias Kohn wrote: > >> One of the simplest patterns is without doubt the literal pattern that >> essential only matches itself (e.g., ``case 123:`` or ``case >> 'abc':``). Any future unification of

[Python-Dev] Re: My thoughts on Pattern Matching.

2020-11-07 Thread Nick Coghlan
On Sat., 7 Nov. 2020, 9:56 am Greg Ewing, wrote: > On 7/11/20 4:03 am, Thomas Wouters wrote: > > > It's also why I'm not in favour of PEP 642 and other proposals for > > solving some of the problems in the Structural Pattern Matching proposal > > (sigils, etc): it widens the gap instead of

[Python-Dev] PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-07 Thread Nick Coghlan
SkippedBinding node into the AST so most of the compiler doesn't need to care how the wildcard is spelled in the surface syntax), but I doubt those are going to matter to most folks in deciding which of the proposals on offer they prefer (or if they'd prefer continue without any pattern matching syntax a

  1   2   3   4   5   6   7   8   9   10   >