[Python-Dev] Re: Python Software Foundation Board of Directors Election 2022

ev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/UDX2JHQZHICWWWMUGD3LBH32ABHWVCZC/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

+ #define Py_USING_UNSTABLE_API #elif Py_VERSION_HEX+0 >= 0x030b # CPython 3.11.x #define Py_BUILD_CORE #endif #include "Python.h" So maybe it would be worth asking the SC for an exception to the beta freeze, and allow the unstable API tier to land during the b

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

On Sat, 30 Apr 2022, 3:02 am Guido van Rossum, wrote: > > I think picking "semi-stable" would be giving in to the OCD nerd in all of > us. :-) While perhaps technically less precise, "unstable" is the catchy > name with the right association. (And yes, we should keep it stable within > bugfix rel

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

On Sat, 23 Apr 2022, 11:17 am Larry Hastings, wrote: > > > Just a quick note from me on the proto-PEP and the two proposed > implementations. When I started exploring this approach, I didn't suspect > it'd require such sweeping changes to be feasible. Specifically, I didn't > think I was going

[Python-Dev] Re: PEP 687 – Isolating modules in the standard library

On Tue, 12 Apr 2022, 3:59 am Guido van Rossum, wrote: > In the sentence starting with > > Types whose methods need access to their module instance will be converted > to heap types[...] > > please emphasize (bold!) "whose methods need access to their module > instance". > > Also emphasize this pa

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

On Sun, 10 Apr 2022, 8:44 am Eric V. Smith, wrote: > On 4/9/2022 4:28 PM, Terry Reedy wrote: > > On 4/9/2022 5:09 AM, Arfrever Frehtes Taifersar Arahesis wrote: > >> > >> Not only deletion, but also random assignments: > > > > Ok. Change "Manual deletion of entries from sys.modules" to "Direct >

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

On Thu, 7 Apr 2022, 8:02 pm Petr Viktorin, wrote: > > This applies to: > > - Functions added in PEP 523 > - PyCode_New, PyCode_NewWithPosOnlyArgs > - Ideally anything documented as subject to change between minor > releases. (To be kind to users, if something is added later we should > again have

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

On Thu, 7 Apr 2022, 8:02 pm Petr Viktorin, wrote: > So here's my proposal: > > - This API stays with the regular public API (Include/cpython/), but to > use it you'll need to #define Py_USING_UNSTABLE_API (name up for > bikeshedding). > I'm fine with the rest of what you suggest, but I don't thi

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

On Wed, 6 Apr 2022, 7:05 am Victor Stinner, wrote: > On Sun, Apr 3, 2022 at 3:29 PM Nick Coghlan wrote: > > The changes you've made have been excellent, and the existing 3 > categories (stable public ABI, stable public API, unstable internal API) > cover the vast majority o

[Python-Dev] Re: Make HAMT available to python script

On Sun, 3 Apr 2022, 12:58 pm Steven D'Aprano, wrote: > > I haven't considered pickling, or deep-copying. I don't think there is > any way to get access to the underlying dict and modify it, except > perhaps via ctypes, so I think it is as immutable as it is possible to > get from Python code. Fee

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

On Fri, 1 Apr 2022, 6:47 pm Victor Stinner, wrote: > On Wed, Mar 30, 2022 at 5:42 PM Guido van Rossum wrote: > > I'm not convinced that advertising an API as being Unstable (in the > documentation?) is going to solve any kind of problem. People love to > use private APIs, and they do it simply b

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Tue, 29 Mar 2022, 9:44 am Toshio Kuratomi, wrote: > One thing about talking about "make urllib more like requests" that is > different than any of the other libs, though, is that requests aims to be > easier to use than anything else (which I note Chris Barker called out as > why he wanted url

[Python-Dev] Re: Enhancing generic type documentation in the standard library

On Wed, 30 Mar 2022, 3:49 am Brett Cannon, wrote: > > > On Mon, Mar 28, 2022 at 3:58 PM Luciano Ramalho > wrote: > >> >> Documenting the generic types in the standard library is a much >> smaller task than turning the typing PEPs into specs. It seems like a >> good next step on the way to better

[Python-Dev] Re: A memory map based data persistence and startup speedup approach

(belated follow-up as I noticed there hadn't been a reply on list yet, just the previous feedback on the faster-cpython ticket) On Mon, 21 Feb 2022, 6:53 pm Yichen Yan via Python-Dev, < python-dev@python.org> wrote: > > Hi folks, as illustrated in faster-cpython#150 [1], we have implemented a > m

[Python-Dev] Re: New PEP website is horrible to read on mobile device

On Thu, 17 Mar 2022, 10:29 am Inada Naoki, wrote: > I can reproduce it. I reported it on > https://github.com/python/peps/issues/2437 Summarising the issues identified there for the thread: the gist is that some elements in some PEPs (mainly tables and code blocks) could result in the initial r

[Python-Dev] Re: PEP 684: A Per-Interpreter GIL

On Thu, 10 Mar 2022, 12:12 pm Eric Snow, wrote: > > On Wed, Mar 9, 2022 at 10:58 AM Petr Viktorin wrote: > > This PEP definitely makes per-interpreter GIL sound possible :) > > > > > > “Main interpreter” should be defined. > > +1 > > > (Or maybe the term should be > > avoided instead -- always h

[Python-Dev] Re: Improvements to the sys.path initialization documentation

On Mon, 7 Mar 2022, 7:42 pm Victor Stinner, wrote: > On Fri, Mar 4, 2022 at 1:37 PM Eryk Sun wrote: > > I don't understand. The site packages directories, including virtual > > environments, are a site extension. > > I propose to change that. Move all code related to sys.path from the > site mod

[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?

On Tue, 15 Feb 2022, 2:57 am Petr Viktorin, wrote: > >> > >> Yes. > >> On older Python versions, where the public API wasn't yet available, > >> those backports use private API. If we change the private API in a > >> point release, the backport will break. > > > > Do you have an example of this?

[Python-Dev] Re: PEP 677 (Callable Type Syntax): Final Call for Comments

On Thu, 13 Jan 2022, 2:24 pm Dennis Sweeney, wrote: > Like others expressed, I don't like the idea of the typing and non-typing > parts of Python separating. > > Has anyone considered adding a new special method like `__arrow__` or > something, that would be user-definable, but also defined for t

[Python-Dev] Re: my plans for subinterpreters (and a per-interpreter GIL)

On Wed, 15 Dec 2021, 3:18 am Eric Snow, wrote: > Hi all, > > I'm still hoping to land a per-interpreter GIL for 3.11. There is > still a decent amount of work to be done but little of it will require > solving any big problems: > > * pull remaining static globals into _PyRuntimeState and PyInter

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On Tue, 28 Sep 2021, 6:55 am Brett Cannon, wrote: > > > On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev < > python-dev@python.org> wrote: > >> >> However the stable ABI is still a second class citizen as it is still >> not possible (AFAIK) to specify a wheel name that doesn't need to

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Mon, 4 Oct 2021, 5:23 pm Antoine Pitrou, wrote: > On Sat, 2 Oct 2021 13:27:03 +0100 > Paul Moore wrote: > > On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > > > > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 > > > > > I agree with the comment made on that i

[Python-Dev] Re: f-strings in the grammar

On Mon, 20 Sep 2021, 9:19 pm Pablo Galindo Salgado, wrote: > Hi, > > I have started a project to move the parsing off-strings to the parser and > the grammar. Appart > from some maintenance improvements (we can drop a considerable amount of > hand-written code), > there are some interesting thing

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

gt; > Gregory dislikes the name: "I don't *like* 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/DGJWM3VMNMDBUTGYG72H5W

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

already has that covered. Cheers, Nick. P.S. The fact that it *didn'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 comprehe

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

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 dis

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

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 th

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

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

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

; is *super weird* if 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.c

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

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

not on > the frame. This is how Mark does it (though 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 cel

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

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

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 into

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

paying it every time "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: >

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

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 star

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

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 ha

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

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 the

[Python-Dev] Re: Comments on PEP 558

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

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

er don't rely on the cache being up to date at all (because they can use the fast_refs mapping instead, implicitly updating any affected cache entries along the way), or else implicitly refresh the cache before relying on it (e.g. copying the proxy mapping works by refreshing the frame cache,

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

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: > > * typing.U

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

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

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 >>> https://docs.python.org/whatsnew/3.10.

[Python-Dev] Re: Bug report

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 https://docs.python.org/3/whatsne

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

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

ows the old and new > 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. -- N

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

and added 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

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

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 elsew

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

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

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

hon/peps/pull/2038/files that 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 Tit

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

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

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

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

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

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

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. > Al

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

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 just

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

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 a

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

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.

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 Tue

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

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 consid

[Python-Dev] Re: Speeding up CPython

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 were

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

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 pe

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

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

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

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 li

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

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 origi

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

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.

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.

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, 'c

[Python-Dev] Re: Relaxing the annotation syntax

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 "relax

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

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

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 h

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

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

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 i

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

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 t

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

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 more

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

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)

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

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

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]

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

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. > I

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

bian didn't put the user's local bin directory on 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

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

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

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 snapsho

[Python-Dev] Re: Comments on PEP 558

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 am I

[Python-Dev] Re: Comments on PEP 558

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). >> > > PyEval_

[Python-Dev] Re: Comments on PEP 558

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

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

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 both the fr

[Python-Dev] Re: Improve CPython tracing performance

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 even a s

[Python-Dev] Re: Comments on PEP 558

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

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 re

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

PEP to try to clear 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-l

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

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

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

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

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

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 implementat

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

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. Functi

[Python-Dev] Re: __init_subclass__ and metaclasses

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 until after

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

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 jus

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

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

  1   2   3   4   5   6   7   8   9   10   >