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

On 24/08/2021 06:27, Steven D'Aprano wrote: > Wouldn't that attempt to resolve global y, rather than local y? Unless > there is a change to the current behaviour of the compiler, I think you > need to fool the compiler: > >if False: y = 0 # anywhere inside the function is okay Time to

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

I'm a major consumer of these APIs as part of some commercial projects (unfortunately I can't discuss too much further) but we find it worth the effort of keeping up with CPython internal changes to continue using them. Option D seems like the best option from my point of view; any user would

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

I think there is also a distinction about the *current* meaning of "required" to be made, in "[i]terators are required to have an |__iter__()| method": "required" doesn't specify whether this is: 1. by convention, and doing

[Python-Dev] importing does not dispatch to __builtins__.__getitem__ to lookup __import__

n/blob/v3.9.6/Python/ceval.c#L2546 Thanks, Patrick Reader class MyDict(dict): # keep a reference around to avoid infinite recursion print = print dict = dict def __getitem__(self, key): self.print("getting:", key) # Can't use super here because we'd h

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

On 11/10/2021 16:45, Steven Troxler wrote: > https://docs.google.com/document/d/1oCRBAAPs3efTYoIRSUwWLtOr1AUVqc8OCEYn4vKYjGI/edit?usp=sharing I think ParamSpecs should not have any special syntax. `**P` looks way too much like kwargs, and any other syntax would be totally new precedent. I'd

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

On 11/10/2021 17:03, Steven Troxler wrote: > Personally, I think we should both adopt function-as-a-type and shorthand > syntax, and reject both the XOR and hybrid syntax because function-as-a-type > is convenient for expressing the same things (named, default-value, and > variadic args). +1

[Python-Dev] Why doesn't peephole optimise away operations with fast locals?

Consider sequences of bytecode operations on fast locals like the following: >>> def f(x):  # declare as parameter so that x is a fast local ... x ... >>> dis(f)   2   0 LOAD_FAST    0 (x)   2 POP_TOP   4 LOAD_CONST   0 (None)    

[Python-Dev] Re: Packing a long list of numbers into memory

You can take a memory view of the array directly: memoryview(array.array("Q", range(1000))) If your exact use-case is writing to a SharedMemory, then I don't think there is any simple way to do it without creating some intermediate memory buffer. (other than using struct.pack_into, or packing

[Python-Dev] Re: Why doesn't peephole optimise away operations with fast locals?

On 10/10/2021 18:33, Guido van Rossum wrote: > On Sun, Oct 10, 2021 at 10:28 AM Brandt Bucher wrote: > > the peephole optimizer shouldn’t be tasked with “fixing” poorly-written > or uncommon code… just improving common code. > Good point. > > As soon as this pattern appears in a benchmark

[Python-Dev] Re: Packing a long list of numbers into memory

This still isn't a completely direct write - you're still creating an array in between which is then copied into shm, whereas struct.pack_into writes directly into the shared memory with no intermediate buffer. And unfortunately you can't do shm.buf[l_offset:r_offset].cast('Q')[:] = nums

[Python-Dev] Re: Why doesn't peephole optimise away operations with fast locals?

On 10/10/2021 18:26, Brandt Bucher wrote: > The first reason is that this operation *does* have a side-effect: if a fast > local is unbound, the load will raise a NameError! > > def f(): > x # This should always raise. > x = None # This makes x a fast local. Ah, ok, that certainly

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

How would this work for a function that returns a function? Would you just put it on the def line like this? def foo() -> (int) -> str:     return some_function_from_int_to_str Or would it have to be: def foo() -> ((int) -> str): ... The former is a little confusing to read - at first

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

How about "except_group", or "exceptgroup"? That's definitely not ambiguous, and can certainly work as a soft keyword. On 06/10/2021 11:06, Larry Hastings wrote: > > It seems like, for this to work, "group" would have to become a keyword.  > This would play havoc with a lot of existing code.  I

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

On 06/10/2021 17:35, Łukasz Langa wrote: > >> On 6 Oct 2021, at 18:05, Yury Selivanov wrote: [...] >> I'll list a few reasons here: >> >> 1. `try: .. except group:` is a valid syntax today. And it will continue to >> be valid syntax. Having both `try: .. except group:` (catch exception >>

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

try:     ... except group (KeyError, ZeroDivisionError) as error:     ... With the precedence you suggest, now group(...) becomes a function call. On 06/10/2021 15:36, Łukasz Langa wrote: >> On 6 Oct 2021, at 16:01, Petr Viktorin wrote: >> >> What about this: >> >> group =

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

> The current restrictions will also confuse some users (e.g. those used to > bash, and IIRC JS, where the rules are similar as what Pablo is proposing). > -- > --Guido van Rossum (python.org/~guido ) WRT the similar syntax in bash (and similar shells), there are two

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

On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote: >> 1. except *E as e:  //  except *(E1, E2) as e: >> 2. except* E as e:  //  except* (E1, E2) as e: I vote #2, because `except *(e1, e2) as e:` could imply that this is splatting an arbitrary expression there - it looks like it will match

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

On 03/10/2021 16:54, Thomas Grainger wrote: > What about `except case ExceptionGroup[E1 | E2]:`? and use match semantics? > > On Sun, 3 Oct 2021, 16:50 Irit Katriel via Python-Dev, > wrote: > > > We wonder if people have a view on which of the following is > clearer/better: >> 1. except

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

On 03/10/2021 16:59, Patrick Reader wrote: > On 03/10/2021 16:47, Irit Katriel via Python-Dev wrote: >>> 1. except *E as e:  //  except *(E1, E2) as e: >>> 2. except* E as e:  //  except* (E1, E2) as e: > > I vote #2, because `except *(e1, e2) as e:` could impl

[Python-Dev] Re: The Default for python -X frozen_modules.

How about checking each non-frozen module's hash and/or and comparing it to that of the frozen module? Would that defeat the performance improvement of freezing? Is it just a terrible idea? On 27/09/2021 17:51, Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python

[Python-Dev] Re: The Default for python -X frozen_modules.

I accidentally a word. "... module's hash and/or *timestamp* and comparing it ..." On 27/09/2021 18:38, Patrick Reader wrote: > How about checking each non-frozen module's hash and/or and comparing it to > that of the frozen module? Would that defeat the performance improvemen

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

brackets which lend themselves to nesting, it probably does make more sense to use them for nesting. On 20/09/2021 21:25, Guido van Rossum wrote: > On Mon, Sep 20, 2021 at 1:07 PM Patrick Reader <_...@pxeger.com > <http://pxeger.com>> wrote: > > > The current

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

On 20/12/2021 22:34, Serhiy Storchaka wrote: > 20.12.21 21:28, Brett Cannon пише: >> As someone with use of this, would you find this useful (i.e. +1, +0)? >> Serhiy already said "no" in another thread. > In every file we import 5-10 or more names from the typing module. We > still does not use

[Python-Dev] Re: Bug report

This is because 3.10 is still in pre-release, which means the /3/ URL still uses the documentation for 3.9, which obviously does not contain a whatsnew page for the upcoming version. The correct URL is currently https://docs.python.org/3.10/whatsnew/3.10.html but the redirect should still

[Python-Dev] Re: RFC on PEP 655: Required[] and NotRequired[] for TypedDict

On 30/01/2022 05:15, David Foster wrote: This PEP [1] introduces syntax to mark individual keys of a TypedDict as either required or potentially-missing. Previously the only way to have a TypedDict with mixed required and non-required keys was to define two TypedDicts - one with total=True and

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

On 18/01/2022 20:41, Pablo Galindo Salgado wrote: We cannot base the computation on a % because is possible that the location markers are relevant but the variables, function names or constructs are just very large. I think that the idea of "spawns the whole line" is sensible, though. On Tue,

[Python-Dev] Re: About vulnerabilities in Cpython native code

On 06/01/2022 15:21, Petr Viktorin wrote: Sometimes there's a bug worth fixing, sometimes it's even an actual vulnerability, but in my experience, most of what tools find in CPython is not actionable. If you do find a security vulnerability, consider reporting it privately to the security

[Python-Dev] Re: Declarative imports

On 10/04/2022 15:52, Guido van Rossum wrote: On Sun, Apr 10, 2022 at 2:31 AM Daniel Pope wrote: On Fri, 8 Apr 2022, 17:44 Guido van Rossum, wrote: The interesting idea here seems to make "lazy imports" easier to implement by making them explicit in the code. So far, most

[Python-Dev] What is Modules/rotatingtree.c for?

I've just noticed Modules/rotatingtree.{h,c}, which don't seem to be used anywhere. Are they just dead code? If so, is there a reason they haven't been removed? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

[Python-Dev] Re: Summary of Python tracker Issues

On 15/05/2022 11:08, Paul Moore wrote: My understanding was that it would be updated to get its information from Github once the transition was complete. Is that not going to happen now? I'm not particularly bothered, as I only really skimmed the weekly email so it wouldn't be a great loss. But

[Python-Dev] Re: Python 3.11 bytecode and exception table

On 05/07/2022 09:22, Matthieu Dartiailh wrote: This surprised me on two levels: - first I have never seen the RESUME opcode and it is currently not documented RESUME occurs at the start of every function (and some other places), and is only used for some internal interpreter bookkeeping. It is

[Python-Dev] Re: Summary of Python tracker Issues

As a "temporary" solution to this problem, could the moderators just ban sta...@bugs.python.org from the list? On 17/06/2022 19:08, Python tracker wrote: ACTIVITY SUMMARY (2022-06-10 - 2022-06-17) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below,

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

On 13/07/2022 14:14, o.jacob.nils...@gmail.com wrote: Hi, I like this PEP but I couldn't find the motivation for using angle brackets over square braces (brackets?). The survey in Appendix A is great but lacks any conclusions. From that survey alone I would assume that angle brackets would

[Python-Dev] Re: __dunder__ = None

On 01/05/2022 06:20, Serhiy Storchaka wrote: The question is how to interpret value None: * Always raise TypeError (with changed message)? This is what happen currently when you set the method to None, this is the most compatible option. * Always raise an error, but allow to change it to more