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

[Patrick Reader]

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 add a `nonnonlocal` statement ;)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WMUK3XLP4GOR25ELCF3LUTAWT6YIPDSI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 need 
to be able to keep up with bytecode changes already so I think backwards 
compatibility isn't really a concern.

Unless you feel it's extremely important to follow PEP 387 (slippery slope?), 
I'd just say "to hell with it". Also, at least if it segfaults, people who 
haven't updated their code will know very quickly, whereas some other options 
might cause subtler bugs.

On 13/08/2021 18:24, Guido van Rossum wrote:
> In 3.11 we're changing a lot of details about code objects. Part of this is 
> the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine 
> Grained Error Locations in Tracebacks).
>
> As a result, the set of fields of the code object is changing. This is fine, 
> the structure is part of the internal API anyway.
>
> But there's a problem with two public API functions, PyCode_New() and 
> PyCode_NewWithPosArgs(). As we have them in the main (3.11) branch, their 
> signatures are incompatible with previous versions, and they have to be since 
> the set of values needed to create a code object is different. (The 
> types.CodeType constructor signature is also changed, and so is its replace() 
> method, but these aren't part of any stable API).
>
> Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the PEP 
> 387 stable ABI. What should we do?
>
> A. We could deprecate them, keep (restore) their old signatures, and create 
> crippled code objects (no exception table, no endline/column tables, qualname 
> defaults to name).
>
> B. We could deprecate them, restore the old signatures, and always raise an 
> error when they are called.
>
> C. We could just delete them.
>
> D. We could keep them, with modified signatures, and to heck with ABI 
> compatibility for these two.
>
> E. We could get rid of PyCode_NewWithPosArgs(), update PyCode() to add the 
> posonlyargcount (which is the only difference between the two), and d*mn the 
> torpedoes.
>
> F. Like (E), but keep PyCode_NewWithPosArgs() as an alias for PyCode_New() 
> (and deprecate it).
>
> If these weren't part of the stable ABI, I'd choose (E). But because they 
> are, I think only (A) or (B) are our options. The problem with (C) is that if 
> there's code that links to them but doesn't call them (except in some corner 
> case that the user can avoid), the code won't link even though it would work 
> fine. The problem with (D) is that if it *is* called by code expecting the 
> old signature it will segfault. I'm not keen on (A) since it can cause broken 
> code objects when used to copy a code object with some modified metadata 
> (e.g. a different filename), since there's no way to pass the exception table 
> (and several other fields, but the exception table is an integral part of the 
> code now).
>
> Code wanting to make slight modifications to code objects such as changing 
> co_name or co_filename should switch to the .replace() API, which is much 
> better at this (though calling it from C is a pain, it's possible). Code 
> wanting to synthesize code should be updated for each release; we should 
> probably require such code to be built with the internal API and use 
> _PyCode_New(), which takes a struct argument containing all the necessary 
> fields.
>
> Thoughts? I'm especially interested in Petr's opinion given that this is a 
> case where we'd like to deprecate something in the stable ABI.
>
> See also discussion in https://bugs.python.org/issue40222 
>  (esp. near the end).
>
> -- 
> --Guido van Rossum (python.org/~guido )
> /Pronouns: he/him //(why is my pronoun here?)/ 
> 
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NLGBBH6ZPW6O5K2MAUIXEGKLYCAU6NHK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 otherwise is just some form of undefined behaviour; 
for a human (or perhaps type-checker) reading it to think it's an iterator, it 
needs `__iter__`, but it's really something like passing an object of the wrong 
type to an unbound method - unenforced by the language (it used to be illegal 
in Py2)

2. in some way actually enforced: the iterator is required to have `__iter__` 
that returns self, and

While 1 is clearly what actually happens in CPython, was that the intended 
meaning? I'd think so - 1 is still a perfectly acceptable interpretation of 
"required" (even if "required" isn't the most clear way of expressing it). Even 
if it wasn't the original meaning, that's how I think it should now be 
interpreted because that's what it is de facto.

Do we know who originally wrote that line, so we could ask them? (The furthest 
I've traced it is 
https://github.com/python/cpython/commit/f10aa9825e49e8652f30bc6d92c736fe47bb134c
 but I don't have any knowledge of SVN or CVS (whichever was used at the time) 
to go further.)

Also, any user-defined iterator that doesn't also define __iter__ would be 
considered wrong and nobody would refuse to fix that. If it's already a bug 
anyway, why bother changing the behaviour and check that?

> A. It's not an iterator if it doesn't define `__next__`.
>
> B. It is strongly recommended that iterators also define `__iter__`.
>
> In "standards" language, I think (A) is MUST and (B) is merely OUGHT or maybe 
> SHOULD.
>
> On Tue, Sep 14, 2021 at 12:30 PM Brett Cannon  > wrote:
>
> Over in https://github.com/python/typeshed/issues/6030 
>  I have managed to kick up a 
> discussion over what exactly an "iterator" is. If you look at 
> https://docs.python.org/3/library/functions.html#iter 
>  you will see the docs 
> say it "Return[s] an iterator 
>  object." Great, but 
> you go the glossary definition of "iterator" at 
> https://docs.python.org/3/glossary.html#term-iterator 
>  you will see it says 
> "[i]terators are required to have an |__iter__()| 
>  method" 
> which neither `for` nor `iter()` actually enforce.
>
> Is there something to do here? Do we loosen the definition of "iterator" 
> to say they /should/ define __iter__? Leave it as-is with an understanding 
> that we know that it's technically inaccurate for iter() but that we want to 
> encourage people to define __iter__? I'm assuming people don't want to change 
> `for` and `iter()` to start requiring __iter__ be defined if we decided to go 
> down the "remove the __aiter__ requirement" from aiter() last week.
>
> BTW all of this applies to async iterators as well.
>
Patrick
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4EN4AUUYP2LQNTXI7CV5TJ2O33FJZVHK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

Hi there,

I've noticed that, when a frame's __builtins__ is a subclass of dict with an 
overridden __getitem__ method, this overriden method is not used by the 
IMPORT_NAME instruction to lookup __import__ in the dictionary; it uses the 
lookup function of normal dictionaries (via _PyDict_GetItemIdWithError). This 
is contrary to the behaviour of the similar LOAD_BUILD_CLASS, as well as the 
typical name lookup semantics of LOAD_GLOBAL/LOAD_NAME, which all use 
PyDict_CheckExact for a "fast path" before defaulting to PyObject_GetItem, 
which is unexpected.

Perhaps more seriously, if __builtins__ is not a dict at all, then it gets 
erroneously passed to some internal dict functions resulting in a mysterious 
SystemError ("Objects/dictobject.c:1440: bad argument to internal function") 
which, to me, indicates fragile behaviour that isn't supposed to happen.

I'm not sure if this intended, so I didn't want to open an issue yet. It also 
seems a highly specific use case and changing it would probably cause a bit of 
a slow-down in module importing so is perhaps not worth fixing. I just wanted 
to ask here in case this issue had been documented anywhere before, and to 
check if it might actually be supposed to happen before opening a bug report.

I cannot find evidence that this behaviour has changed at all in recent history 
and it seems to be the same on the main branch as in 3.9.6.

A short demo of these things is attached.

Links to relevant CPython code in v3.9.6:

IMPORT_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L5179

BUILD_CLASS: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2316

LOAD_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2488

LOAD_GLOBAL: https://github.com/python/cpython/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 have to keep a reference around instead of looking it up
# in __builtins__ (to prevent infinite recursion), but then there's no __class__ cell which
# breaks the lookup mechanism. Instead, just refer to dict by name
return self.dict.__getitem__(self, key)

__builtins__ = MyDict(vars(__builtins__))

int# prints "getting: int"
__import__ # prints "getting: __import__"
class X: pass  # prints "getting: __build_class__"
import math# does not print "getting: __import__" because it uses dictobject internal lookup



# try these individually in the Python shell, because they all error on their own

__builtins__ = "not a dictionary"

int# TypeError: string indices must be integers (because it's trying to do effectively `"not a dictionary"["int"]`)
__import__ # same error
class X: pass  # same error (trying to load __build_class__)
import math# SystemError: Objects/dictobject.c:1440: bad argument to internal function
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZQMF6XC76J4APJPB3X6PGATG6CV5NN44/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 suggest 
simply `(P) -> bool`, because P is already clearly a ParamSpec because it was 
declared as such. If `Concatenate[T, P]` is clear enough without special syntax 
decorating the `P`, so is `(T, P) ->`.

(I posted this as a comment on the document, but I'm reposting it here as well 
for visibility)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q6YI6DPSSKCGRBSZSFJMEYIQAORQEV5Q/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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

This combination of a shorthand syntax for simple callbacks and a longhand 
interface-style method for more complex signatures is the best option IMO.

It provides good flexibility, in the pragmatic sense of "there should be only 
one way to do it": there is a dead-simple way which is pretty good, and a more 
flexible way for more complex cases which is pretty easy to switch to if 
necessary.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XFE32UGDI4TAS6BREEHKLOYP3TZF6FFK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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)
  6 RETURN_VALUE

Given the following assumptions:

- a LOAD_FAST cannot possibly have any side-effects outside the interpreter 
stack [1]

- a POP_TOP immediately undoes LOAD_FAST's effects on the interpreter stack

I am wondering: why doesn't the peephole optimiser remove these opcode 
constructs?

Is it maybe because of PEP 626 - an introspection tool needs to know that the 
variable is being used there? Although surely in that case the peephole 
optimiser could just replace it with a single NOP? (c.f.: 
https://bugs.python.org/issue42719)

Or is one of my assumptions wrong?

[1]: global variables are probably supposed to have the same guarantee, but in 
practice this is not the case, which is why I'm focusing on the _FAST ones; see 
for example 
https://ato.pxeger.com/run?1=m72soLIkIz9vwYKlpSVpuhY3JyXnJBYXK_hWumQml2ikAAlNKy4FIEhJTVOIj09PLcksSc2Nj9coTs1J01HITq2EyoNAQVFmXomGUnFmSqpCalpaanKJoqKSJly6KLWktChPobi0ILVIQ1MP2TSQOVxcqRWpyRpKFUo6MPsrbA01NSEugzoQ5lAA

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/767FGRV4ZL5IVBHWSAW5TJGQMGQS244Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 the values completely manually)

On 10/10/2021 16:18, Facundo Batista wrote:
> El dom, 10 de oct. de 2021 a la(s) 11:50, Serhiy Storchaka
> (storch...@gmail.com) escribió:
>> 10.10.21 17:19, Facundo Batista пише:
>>> I have a long list of nums (several millions), ended up doing the following:
>>>
>>> struct.pack_into(f'{len(nums)}Q', buf, 0, *nums)
>> Why not use array('Q', nums)?
> You mean `array` from the `array` module? The only way I see using it
> is like the following:
>
 shm = shared_memory.SharedMemory(create=True, size=total_size)
 a = array.array('Q', nums)
 shm.buf[l_offset:r_offset] = a.tobytes()
> But I don't like it because of the `tobytes` call, which will produce
> a huge bytearray only to insert it in the shared memory buffer.
>
> That's why I liked `pack_into`, because it will write directly into
> the memory view.
>
> Or I'm missing something?
>
> Thanks!
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ONWPTKL3P6VOZEHUDCL7B6CZ5TI3DER6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 suite we'll optimize it away. 
> :-) (That is, *if* the optimizer can prove that it can't raise a name error.)
Perhaps a more realistic case that definitely doesn't require a check to 
prevent NameErrors would be optimising `STORE_FAST x LOAD_FAST x` for same x. 
But as Steven D'Aprano has just pointed out, they're FAST lookups anyway, so 
the benefit may well be minimal anyway.___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JNDLOPUWPELH55WL4B5YFDGRIMHOIF2P/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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

where nums is a plain Python iterable; it has to already be an array, so it 
still requires a copy.

On 10/10/2021 16:57, Serhiy Storchaka wrote:
> 10.10.21 18:18, Facundo Batista пише:
>> You mean `array` from the `array` module? The only way I see using it
>> is like the following:
>>
> shm = shared_memory.SharedMemory(create=True, size=total_size)
> a = array.array('Q', nums)
> shm.buf[l_offset:r_offset] = a.tobytes()
>> But I don't like it because of the `tobytes` call, which will produce
>> a huge bytearray only to insert it in the shared memory buffer.
>>
>> That's why I liked `pack_into`, because it will write directly into
>> the memory view.
>>
>> Or I'm missing something?
>shm.buf[l_offset:r_offset].cast('Q')[:] = a
>
> or
>
>shm.buf[l_offset:r_offset] = memoryview(a).cast('B')
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/A2XKNKG4C55VKII6VOXRR3XEP6VHIU43/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IAOHC7LGAKNXMIIGAZI3ALJ6MJVFEEBI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 explains it - thanks!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GLQ4LXLZZMRLDQQJTDM2CZOFNJ62I6JE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 glance, it looks like it 
might return an int; the latter is ugly.

I'd prefer a (soft?) keyword, like `(func (int) -> str)`. That keyword could be 
`def` or `lambda`, but those look like they might preclude custom callables. 
And just using `callable` seems like little improvement...

On 07/10/2021 17:41, S Pradeep Kumar wrote:
> Hello all,
>
> Typing-sig has been discussing user-friendly syntax for the type used to 
> represent callables. [1] Since this affects the Python language syntax, we 
> wanted to get some high-level feedback from you before putting up a detailed 
> PEP.
>
> TL;DR: We want to propose syntax for Callable types, e.g., `(int, str) -> 
> bool` instead of `typing.Callable[[int, str], bool]`. Questions: 1. Are there 
> concerns we need to keep in mind about such a syntax change? 2. Should we 
> propose syntax for additional features in the same PEP or in a future PEP?
>
>
> # Motivation
>
> Guido has pointed out that `Callable` is one of the most frequently used type 
> forms but has the least readable syntax. For example, say we have a callback 
> `formatter` that accepts a record and a list of permissions:
>
> ```python
> def print_purchases(
>     user,
>     formatter,  # <-- callback
> ):
>     <...>
>     output = formatter(record, permissions)
>     print(output)
> ```
>
> To give it a type, we currently have to write:
>
> ```python
> from typing import Callable
>
> def print_purchases(
>     user: User,
>     formatter: Callable[[PurchaseRecord, List[AuthPermission]], 
> FormattedItem]  # Hard to read.
> ) -> None:
>
>     <...>
>     output = formatter(record, permissions)
>     print(output)
> ```
>
> `Callable` can be hard to understand for new users since it doesn't resemble 
> existing function signatures and there can be multiple square brackets. It 
> also requires an import from `typing`, which is inconvenient. Around 40% of 
> the time [2], users just give up on precisely typing the parameters and 
> return type of their callbacks and just leave it as a blank Callable. In 
> other cases, they don't add a type for their callback at all. Both mean that 
> they lose the safety guarantees from typing and leave room for bugs.
>
> We believe that adding friendly syntax for Callable types will improve 
> readability and encourage users to type their callbacks more precisely. Other 
> modern, gradually-typed languages like TypeScript (JS), Hack (PHP), etc. have 
> special syntax for Callable types.
>
> (As a precedent, PEP 604 recently added clean, user-friendly syntax for the 
> widely-used `Union` type. Instead of importing `Union` and writing `expr: 
> Union[AddExpr, SubtractExpr], we can just write `expr: AddExpr | 
> SubtractExpr`.)
>
>
> # Proposal and Questions
>
> We have a two-part proposal and questions for you:
>
> 1. Syntax to replace Callable
>
> After a lot of discussion, there is strong consensus in typing-sig about 
> adding syntax to replace Callable. So, the above example would be written as:
> ```python
> def print_purchases(
>     user: User,
>     formatter: (PurchaseRecord, List[AuthPermission]) -> FormattedItem,
> ) -> None:
>
>     <...>
>     output = formatter(record, permissions)
>     print(output)
> ```
> This feels more natural and succinct.
>
> Async callbacks currently need to be written as
> ```
> from typing import Callable
>
> async_callback: Callable[[HttpRequest], Awaitable[HttpResponse]]
> ```
>
> With the new syntax, they would be written as
> ```
> async_callback: async (HttpRequest) -> HttpResponse
> ```
> which again seems more natural. There is similar syntax for the type of 
> decorators that pass on *args and **kwargs to the decorated function.
>
> Note that we considered and rejected using a full def-signature syntax like
> 
> (record: PurchaseRecord, permissions: List[AuthPermission], /) -> 
> FormattedItem
> 
> because it would be more verbose for common cases and could lead to subtle 
> bugs; more details in [3].
>
> The Callable type is also usable as an expression, like in type aliases 
> `IntOperator = (int, int) -> int` and `cast((int) -> int, f)` calls.
>
> **Question 1**: Are there concerns we should keep in mind about such a syntax 
> proposal?
>
>
>
> 2. Syntax for callback types beyond Callable
>
> `Callable` can't express the type of all possible callbacks. For example, it 
> doesn't support callbacks where some parameters have default values: 
> `formatter(record)` (the user didn't pass in `permissions`). It *is* possible 
> to express these advanced cases using Callback Protocols (PEP 544) [4] but it 
> gets verbose.
>
> There are two schools of thought on typing-sig on adding more syntax on top 
> of (1):
>
> (a) Some, 

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

[Patrick Reader]

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 can't tell you how many 
> times I've used the identifier "group" in my code, particularly when dealing 
> with regular expressions.
>
> Even making it a soft keyword, a la "await" in 3.5, would lead to ambiguity:
>
> group = KeyboardInterrupt
>
> try:
>     while True:
>     print("thou can only defeat me with Ctrl-C")
> except group as error:
>     print("lo, thou hast defeated me")
>
>
> //arry/
>
> On 10/6/21 2:12 AM, Barry Warsaw wrote:
>> What do the PEP authors think about `except group`?  Bikeshedding aside, 
>> that’s still the best alternative I’ve seen.  It’s unambiguous, 
>> self-descriptive, and can’t be confused with unpacking syntax.
>>
>> -Barry
>>
>>  wrote:
>>
>> I agree that *(E1, E2) looks like unpacking, how about
>>
>> except *E1 as error: ...
>> except (*E1, *E2) as error: ...
>>
>> even better would be if we could drop the braces:
>> except *E1, *E2 as error: ...
>>> [...]
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5N4FDYAW5AB2AXMGM6CBRSN6PK3IWMRD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 
>> `group`) and `try: .. except group E:` (catch exceptions of E into a group) 
>> in the same grammar worries me.
>>
>> 1a. It can be especially confusing if someone has a local/global variable 
>> called `group`.
>
> This is a valid point, also raised by Pablo over WhatsApp (which happens to 
> work today!). The particular hairy example has to do with your next point so 
> let's go there first...
>
>
>> 1b. Or, for example, if a user forgets to type `E` and leaves just `except 
>> group` it would fallback to the regular try..except behavior. And it would 
>> be a runtime error ("group" is undefined).
>
> Right. Worse yet, this wouldn't be a runtime error UNLESS user code raises an 
> exception within that try: block. Otherwise Python would happily take the 
> unbound name and run with it:
>
> >>> try:
> ...   ...
> ... except group:
> ...   ...
> ...
> Ellipsis
>
>
> When you raise:
>
> >>> try:
> ...   1/0
> ... except group:
> ...   ...
> ...
> Traceback (most recent call last):
>   File "", line 2, in 
> ZeroDivisionError: division by zero
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "", line 3, in 
> NameError: name 'group' is not defined
>
>
> This is pretty confusing and in my eyes disqualifies the "except group" 
> proposal. Pablo also claims it would be very hard to generate good error 
> messages due to this and I can see why. My initial idea here was to modify 
> this received `NameError` just like we do in other cases with the new "Did 
> you mean" helper:
>
> >>> arg = 1
> >>> ar
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'ar' is not defined. Did you mean: 'arg'?
> >>> def f():
> ...   ar
> ...
> >>> f()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 2, in f
> NameError: name 'ar' is not defined. Did you mean: 'arg'?
>
> We could potentially do something similar to generate better error messages 
> for "except group" confusion, right? Only *we can't* if `group` happens to be 
> bound as a name in a reachable scope which Larry points out is a popular 
> name. In this scenario any syntax errors would end up with terribly confusing 
> TypeErrors or AttributeErrors and so on. This is unacceptable.

Now a moot point, but this could be a SyntaxWarning.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PB4ANBGW4M3DZDQA6C2PPXUPGPBZ3JJZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 = (KeyboardInterrupt, MemoryError)
>> other_group = (KeyError, IndexError)
>>
>> try:
>>   ...
>> except group + other_group as error:
>>   ...
> Haha, let's see if we can write a Mersienne twister all inside an except 
> statement ‍
>
> Joking aside, since we allow any expression after 'except' 'group' then this 
> is indeed ambiguous. In theory! In practice, however, PEG is satisfied with 
> the first rule that matches entirely, so this is a matter of choosing correct 
> precedence. In this case, it seems it would make sense for "old-style" except 
> to come first because your (convoluted! 鸞) example is potentially useful, 
> whereas "except +TimeoutError:" is pure nonsense.
>
> I will prototype a PR for this just so we can play with it.
>
> - Ł
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LW4RJO5DTBO7CEYBTT2E7UTHCL6SCXK7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

> 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 options:

"string `code` string"

"string $(code) string"

The latter, $(), allows fully-featured nesting in the way Pablo is suggesting:

"string $(code "string2 $(code2) string2" code) string"

The former, using backticks, does not allow nesting directly, but it allows 
extra backslashes inside the backticks to escape the nested ones, like this:

"string `code "string2 \`code2\` string2" code` string"

This can be nested infinitely using lots of backslashes. Is this worth 
considering as another option? It doesn't have the disadvantage of complicating 
lexing (as much), although nesting with backslashes is quite ugly. IMO nesting 
things in f-strings would be ugly anyway, so I don't think that would matter 
too much.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R5NNGXYOU74VEXCBF7API7EFRGLN7MWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 any number of 
dynamically chosen exception types.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RGIAE2HMYQLPXWH5O5TNBNRXDQQ4UKAK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 *E as e:  //  except *(E1, E2) as e:
>> 2. except* E as e:  //  except* (E1, E2) as e:
> (The difference is in the whitespace around the *).
>
> At the moment * is a separate token so both are allowed, but we could 
> change that (e.g., make except* a token), and in any case we need to settle 
> on a convention that we use in documentation, etc.
> It is also not too late to opt for a completely different syntax if a 
> better one is suggested.
>
I don't think X[Y | Z] is close to any syntax match currently allows.

But... I have long thought that the interpreter's exception matching abilities 
were underused by the language. Maybe this is an opportunity for something else 
interesting, in general?

The problem being, besides the general extra complexity, that the match 
statement's variable capture semantics are different to the `as name` syntax 
already used by the except statement.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BFX2WFK4IFFUO2JRUBGKGLPPEFBRTIQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 imply that this is 
> splatting an arbitrary expression there - it looks like it will match any 
> number of dynamically chosen exception types.
>
(that could be a useful feature actually (so maybe the * syntax should be 
reserved??), but that's another discussion)___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EAPQS342PWERAKVS4XHFYYSXVOK6LFHZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 -c
> pass" [1][2], to make startup a bit faster.  Import of those modules
> is controlled by "-X frozen_modules=[on|off]".  Currently it defaults
> to "off" but we'd like to default to "on".  The blocker is the impact
> on contributors.  I expect many will make changes to a stdlib module
> and then puzzle over why those changes aren't getting used.  That's an
> annoyance we can avoid, which is the point of this thread.
>
> Possible solutions:
>
> 1. always default to "on" (the annoyance for contributors isn't big enough?)
> 2. default to "on" if it's a PGO build (and "off" otherwise)
> 3. default to "on" unless running from the source tree
>
> Thoughts?
>
> -eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YPENSVRAT2HKZSBX73ZWZYTLFIFFFDQT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 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 -c
>> pass" [1][2], to make startup a bit faster.  Import of those modules
>> is controlled by "-X frozen_modules=[on|off]".  Currently it defaults
>> to "off" but we'd like to default to "on".  The blocker is the impact
>> on contributors.  I expect many will make changes to a stdlib module
>> and then puzzle over why those changes aren't getting used.  That's an
>> annoyance we can avoid, which is the point of this thread.
>>
>> Possible solutions:
>>
>> 1. always default to "on" (the annoyance for contributors isn't big enough?)
>> 2. default to "on" if it's a PGO build (and "off" otherwise)
>> 3. default to "on" unless running from the source tree
>>
>> Thoughts?
>>
>> -eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6ALEB4NCYS32EOLR5PT25GYBDN7ZOYEO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

I didn't meant to bring back backticks, but to use the semantics they have in 
shell languages of using backslashes to escape nested substitutions, like this:

f"string {code f\"string2 \{code2\} string2\" code} string"

Upon reflection though, I agree that since we already use 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 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 <http://python.org/~guido> 
> <http://python.org/~guido>)
>
> WRT the similar syntax in bash (and similar shells), there are two 
> options:
>
> "string `code` string"
>
> "string $(code) string"
>
> The latter, $(), allows fully-featured nesting in the way Pablo is 
> suggesting:
>
> "string $(code "string2 $(code2) string2" code) string"
>
> The former, using backticks, does not allow nesting directly, but it 
> allows extra backslashes inside the backticks to escape the nested ones, like 
> this:
>
> "string `code "string2 \`code2\` string2" code` string"
>
> This can be nested infinitely using lots of backslashes. Is this worth 
> considering as another option? It doesn't have the disadvantage of 
> complicating lexing (as much), although nesting with backslashes is quite 
> ugly. IMO nesting things in f-strings would be ugly anyway, so I don't think 
> that would matter too much.
>
>
> F-strings are more like $(...), since the interpolation syntax uses {...} 
> delimiters. So it probably should work that way. JS interpolation works that 
> way too, see 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#nesting_templates
>  .
>
> I wouldn't want to do anything to bring `backticks` back in the language.
>
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him //(why is my pronoun here?)/ 
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7COOVJPGJMDLYRS2WNQZMMOGVMBJBQFK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 PEP 585 and PEP 604 syntax, but are going to do this
> in near future. It could save as from importing List, Tuple, Dict, Set,
> Union, Optional, but we still need to import Any, Sequence, Iterable,
> Iterator, AsyncIterator, Awaitable, TypeVar, and sometimes
> AsyncContextManager, NewType, cast, overload. Special syntax for
> callable type hints will not save game.
Sequence, Iterable, Iterator, AsyncIterator, Awaitable, AsyncContextManager are 
all in collections.abc not typing now. Of course it doesn't reduce total 
imports but it makes it less likely that you'll need to import typing.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PVF4G57RJ634QYFJ2HGI3QQ5RXB6J455/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Bug report

[Patrick Reader]

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 
probably be fixed

Patrick

On 21/07/2021 13:15, Nguyen Do Minh Duc 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/whatsnew/3.10.html 
>  which shows 404 error not 
> found nginx. Can you fix this?
>
> Sincerely
>
> xXPartOfMeXx
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/VOWYBW2OWVMHRDYNSIMHZSPNG7ATMCLU/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VGJKF5MMZTRYPXNUJ6JDMU4SCBUDAZFO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 one with total=False - 
and have one of those TypedDicts inherit from the other. This PEP 
introduces special forms Required[] and NotRequired[] to the "typing" 
module that can be used to directly mark individual items of a 
TypedDict as required or not-required. We have implementations for 
mypy, pyright, and pyanalyze.


Consensus on the PEP has been reached in typing-sig.

My understanding of the PEP process as described in PEP 1 [2] is that 
content review should be requested of core developers here in 
python-dev. So consider this my official request for comments! ^_^


I believe that after review & feedback from python-dev the next step 
would be to submit this PEP to the Steering Council. However it's not 
clear to me from [2] where I should actually do that when the time comes.
I think the names `Required` and `NotRequired` are too generic for 
something which can only be used in one context (`TypedDict`s), and it 
is not immediately obvious when reading code without context what the 
difference between `NotRequired` and `Optional` might be. Could they be 
put into a pseudo-module like `typing.io`, e.g. `TypedDict.Required`?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HSVVKLSFJAAONQXRFDZ4UUHRYKBM6GTU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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, 18 Jan 2022 at 20:32, Steve Dower  wrote:


Omitting the line of ^ where over x% (75%? 90%?) of characters on the
line would be marked would be fine by me.

It would also need to take into account cases where a line contains an 
inline comment, which does not contribute to the code producing the 
error, but where all of the rest of the line (the code) is the source of 
the error and highlighting it is not useful


# test.py:

code_that_causes_an_error # a comment

$ python3.11 test.py

Traceback (most recent call last):
  File "test.py", line 1, in 
    code_that_causes_an_error # a comment
    ^
NameError: name 'code_that_causes_an_error' is not defined

(the traceback shown is from a current `main` build)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F4FSJY7OIPHAH5I6YBHCFI4DP3XLNUJW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 team: see https://www.python.org/dev/security/


And Python is not like JavaScript (in the browser), where code is 
supposed to be run in a total sandbox. Python is not supposed to be a 
completely memory-safe language. You can always access memory manually 
using `ctypes`, or, ultimately, `/proc/self/mem`.


For this reason, a buffer overflow in CPython is a bug because it can 
cause a crash, not because it can cause a security vulnerability.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PLYRO6VSFNHIRD5FMSEK5RTZJNMTQG7G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Declarative imports

[Patrick Reader]

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
lazy import frameworks for Python have done hacks with
`__getattribute__` overrides.


The value is more than ease of implementation. Having syntax for
import expressions makes them statically analysable, which is
needed for type checkers and IDE autocompletion.


This has been brought up a few times and I don't get it. Currently a 
use of an imported module is perfectly analyzable by all the static 
type checkers I know of (e.g. mypy, Pyre, pyright). For the static 
analyzer it makes no difference if I have


import re
.
.
.
def foo(x):
    if re.match(r"blah", x): ...

or the hypothetical inline form:

def foo(x):
    if @re.match(r"blah", x): ...

But I also see value in being able to type out code that uses
modules not yet imported without breaking my flow to add an import
statement. I don't yet trust IDEs to do this because I've been
bitten by them doing so incorrectly in the past.


I have too.


I see no reason why @re.match(...) couldn't just be equivalent to 
__import__("re").match(...) (or a more optimised compiled version of 
that). Any side-effects of importing the module (of which there probably 
shouldn't be any for most modules) just happen at whenever the first 
time the @re.match(...) is evaluated.


After the first call, and unless __import__ is overloaded, I also don't 
think @re.match(...) would have to be significantly slower than 
re.match(...). The latter already has to look up a global variable 
(assuming the module was imported globally, which is almost always the 
case). I don't think it would be too hard to optimise and Quicken.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3P5KUDUZXOIEZSEWNV7UMVAQNGYPGXDF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/46D6DD3OEZEOH4CUPFKOSLVUG6MHV7BU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 I agree, it
should either be modified or removed.
There has already been some discussion on this at 
https://github.com/psf/gh-migration/issues/6.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VUIRK625UQVYPCYRE5WY73YZ465OQDY4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 
documented at https://docs.python.org/3.11/library/dis.html#opcode-RESUME___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N3YEND3N7J2NWXIRRYW2ERAVW6FVXYZY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
   open7146 ( +0)
   closed 51841 ( +0)
   total  58987 ( +0)

Open issues with patches: 2890


Most recent 15 issues with no replies (15)
==

#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258

#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256

#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253

#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252

#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251

#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244

#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242

#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241

#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238

#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236

#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228

#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222

#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219

#47218: adding name to lzmafile
https://bugs.python.org/issue47218

#47217: adding name to BZ2File
https://bugs.python.org/issue47217



Most recent 15 issues waiting for review (15)
=

#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256

#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255

#47254: enhanced dir?
https://bugs.python.org/issue47254

#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251

#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243

#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233

#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222

#47218: adding name to lzmafile
https://bugs.python.org/issue47218

#47217: adding name to BZ2File
https://bugs.python.org/issue47217

#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216

#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215

#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208

#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205

#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200

#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PNMW3MJ2K6FWBD3EOZOXF6QWEVWARHYM/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FEJXQMZMRLJDKL2W2YYFE46C7FIPSMC4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Patrick Reader]

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 
have been chosen over square braces, given that they are the most common option 
and appear in (afaik) the more popular languages in that list. I think the PEP 
should add a section about the choice of syntax in the rejected section, which 
can be expanded upon in Appendix A.

If you can't tell I'm in favor of angle brackets, I think the examples given in 
the PEP look a bit messy with so many parentheses and square braces in close 
proximity. Using angle brackets would make the distinction between typevars and 
function parameters clearer.


Another reason that square brackets should be preferred over angle 
brackets is the difficulty in parsing:


list>

is tokenised as list < list < int >> where the last token is a right 
shift operator, so the parser has to know that sometimes >> is used when 
two "angle bracket" groups are closed, instead of > >


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CNIEGWWROWN4Y4IPVH72CDKCFO3OSHLY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: __dunder__ = None

[Patrick Reader]

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 appropriate 
type (for example AttributeError for __setattr__)?

* Interpret value None the same way as an absent attribute?
What about binary operators (__add__, __eq__, etc)? Should they act as 
if they'd returned NotImplemented? Or immediately unconditionally raise 
a TypeError?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PLWKIT7FWXLKIGQXL3X5GFT3MGTC53R3/
Code of Conduct: http://python.org/psf/codeofconduct/