[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 08:41, Chris Angelico escribiu: On Fri, Sep 25, 2020 at 4:25 PM Sergio Fenoll wrote: What I had in mind was that an IDE could use this information to show autocomplete options when writing except blocks. The other day I was writing some code like this: import requests try:

[Python-ideas] Re: Suggestion: annotated exceptions

24.09.20 11:47, Sergio Fenoll пише: > In the same vein as adding type annotations to code, I think it'd be > very useful to have exception "raises" annotations, i.e. a way to > annotate what exceptions a function raises. Again, like type > annotations, it shouldn't be mandatory nor actually be enfo

[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 09:12, Serhiy Storchaka escribiu: Did not the experience of C++ show that exceptions declaration was a bad idea? In C++ it was optional and is abandoned now. Java developers still suffer from necessary to declare all raised exception, or just declare the most general exception class

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 5:09 PM Sergio Fenoll wrote: > > O 25/09/20 ás 08:41, Chris Angelico escribiu: > > > It would have to not only look at get(), but everything that it calls. > > Either that, or you're back to the Java thing of "catch it or declare > > it", and we've seen from Java that that'

[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 10:02, Chris Angelico escribiu: On Fri, Sep 25, 2020 at 5:09 PM Sergio Fenoll wrote: O 25/09/20 ás 08:41, Chris Angelico escribiu: It would have to not only look at get(), but everything that it calls. Either that, or you're back to the Java thing of "catch it or declare it", an

[Python-ideas] Re: PEP 9999 (provisional): support for indexing with keyword arguments

Thanks for the PEP, and for pinging the numpy list about it. Some comments: Sequence unpacking remains a syntax error inside subscripts: Reason: unpacking items would result it being immediately repacked into a tuple A simple counter-example is [:, *args, :], which could be treated as [(slice(Non

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 6:14 PM Sergio Fenoll wrote: > I see what you mean now, and I agree. But surely there's a fairly big > overlap between > "exceptions I expect to raise" (from the POV of the callee) and > "exceptions I can handle" > (from the POV of the caller). Wouldn't it still be useful t

[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 10:56, Chris Angelico escribiu: There's the shallow "exceptions that I expect to raise", which is those explicitly listed within the function as raise statements; but that's not the whole story, since exceptions can be raised by anything that the function calls. So, no, I don't thi

[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 06:23, Stephen J. Turnbull escribiu: Sergio Fenoll writes: > In the same vein as adding type annotations to code, I think it'd > be very useful to have exception "raises" annotations, i.e. a way > to annotate what exceptions a function raises. I think you need to explain th

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 7:19 PM Sergio Fenoll wrote: > > O 25/09/20 ás 10:56, Chris Angelico escribiu: > > > There's the shallow "exceptions that I expect to raise", which is > > those explicitly listed within the function as raise statements; but > > that's not the whole story, since exceptions c

[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 11:34, Chris Angelico escribiu: On Fri, Sep 25, 2020 at 7:19 PM Sergio Fenoll wrote: O 25/09/20 ás 10:56, Chris Angelico escribiu: There's the shallow "exceptions that I expect to raise", which is those explicitly listed within the function as raise statements; but that's not th

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 7:46 PM Sergio Fenoll wrote: > I'm really failing to see what part of my logic is faulty. I know that > any exception that isn't handled can be raised. I know that is the > expected behaviour. I don't expect every function to exhaustively > document every single exception i

[Python-ideas] Re: Suggestion: annotated exceptions

> > I think it'd be very useful to have exception "raises" annotations, i.e. a way to annotate what exceptions a function raises. I personally think this would be wonderful, I've been meaning to suggest it here for some time, but haven't got around to it. I first found myself wanting this when

[Python-ideas] Re: Suggestion: annotated exceptions

O 25/09/20 ás 11:52, Chris Angelico escribiu: But requests.get() doesn't have a single raise statement anywhere in it. And if you dig through the entire source code for the requests package, you'll still only find a small number of the exceptions that might be raised. Errors come from anywhere, a

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 11:58, Samuel Colvin wrote: > I first found myself wanting this when I came back to python > having been writing rust. The Result type in rust is somewhat > similar to what's being suggested here. See > https://doc.rust-lang.org/std/result/ I do not know Rust and I'm not su

[Python-ideas] Re: Suggestion: annotated exceptions

Sorry I probably wasn't clear enough in what I was suggesting. > The main question here is why using a hint or a decorator should be > better than a simple documentation. For the same reason type hints are better than documentation - 1. static analysis can catch a multitude of potential errors

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 01:23:01PM +0900, Stephen J. Turnbull wrote: > Sergio Fenoll writes: > > > In the same vein as adding type annotations to code, I think it'd > > be very useful to have exception "raises" annotations, i.e. a way > > to annotate what exceptions a function raises. > > I th

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

I'd like to hear more about why the empty tuple has been selected as the default index. On Fri, Sep 25, 2020, 1:07 AM David Mertz wrote: > Is this a breaking change? It feels borderline. > > Keyword-only subscripts are permitted. The positional index will be the >> empty tuple: >> obj[spam=1, eg

[Python-ideas] Re: Suggestion: annotated exceptions

On 2020-09-25 at 13:44:36 +0100, Samuel Colvin wrote: > 2. We should have some easy way to say "let this error propagate", > rust uses very nice question mark at the end of a line syntax, python > could use something similar one day, until then a magic comment, > wrapper function or context funct

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote: > > O 25/09/20 ás 11:52, Chris Angelico escribiu: > > But requests.get() doesn't have a single raise statement anywhere in > > it. And if you dig through the entire source code for the requests > > package, you'll still only find a small number

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 13:46, Samuel Colvin wrote: > > Sorry I probably wasn't clear enough in what I was suggesting. > >> >> The main question here is why using a hint or a decorator should be >> better than a simple documentation. > > > For the same reason type hints are better than documentatio

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 14:15, Chris Angelico wrote: > Why? Do you really think you can enumerate EVERY possible way that > something might fail? Rust does a surprisingly good job of that, actually. But the point is that Python is not Rust, and the infrastructure Rust uses to allow it to manage c

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 14:44, Samuel Colvin wrote: > > Sorry I probably wasn't clear enough in what I was suggesting. > >> >> The main question here is why using a hint or a decorator should be >> better than a simple documentation. > > > For the same reason type hints are better than documentatio

[Python-ideas] Trash bin

That I hope it's not the place where this proposal will be sent. My idea is apparently simple: what if, anytime we create an object, instead of deleting it, we send it in a trash bin? If the object is, for some reason, recreated, we can take it from the trash bin. If there is no more memory, the t

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 15:57, Paul Moore wrote: > > On Fri, 25 Sep 2020 at 14:15, Chris Angelico wrote: > > > Why? Do you really think you can enumerate EVERY possible way that > > something might fail? > > Rust does a surprisingly good job of that, actually. But the point is > that Python is not

[Python-ideas] Re: Trash bin

On Sat, Sep 26, 2020 at 2:19 AM Marco Sulla wrote: > > That I hope it's not the place where this proposal will be sent. > > My idea is apparently simple: what if, anytime we create an object, > instead of deleting it, we send it in a trash bin? If the object is, > for some reason, recreated, we ca

[Python-ideas] Re: Suggestion: annotated exceptions

I strongly disagree that it's useless to document which Exceptions a function could raise; even in Python (which, for a few reasons, is not a language that's considered for safety-critical application). In Python, it is common practice to - at a high level in the call stack - trap Exceptions that

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 11:14:01PM +1000, Chris Angelico wrote: > On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote: > > Surely there has to be a better way of programming than running stuff, > > watching it fail, and then keeping track of how it fails so you can > > later handle that failure?

[Python-ideas] Re: Trash bin

On Fri, 2020-09-25 at 18:19 +0200, Marco Sulla wrote: > That I hope it's not the place where this proposal will be sent. > > My idea is apparently simple: what if, anytime we create an object, > instead of deleting it, we send it in a trash bin? If the object is, > for some reason, recreated, we c

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin wrote: > I do agree but maybe that suggests a different role for annotated > exceptions in Python. Rather than attempting to enumerate all possible > exceptions annotations could be used to document in a statically > analysable way what the "expected"

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 3:42 AM Steven D'Aprano wrote: > > In the list of all possible failures, will you include MemoryError? > > Sure, if I'm writing some sort of ultra-high availability server > application that is expected to run 24/7 for months at a time. > > while memory_in_reserve(): >

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 18:28, Samuel Colvin wrote: >> There's also the problem that you've explicitly acknowledged, that >> exception hints are *always* going to be inaccurate, in stark contrast >> to type hints which are expected to be correct when used. > > We should draw a distinction between t

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Thu, 24 Sep 2020 at 22:22, Guido van Rossum wrote: > - I recommend that you carefully look over the PEP as rendered on python.org > (link above) and try to fix any markup oddities. E.g. some comments are > line-wrapped, which looks ugly, and some bulleted lists have an extra blank > line abo

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote: > There may be practical difficulties in sticking exceptions into > annotations. Annotations already can be pretty long and bulky. But if > you are okay with functions documenting that they might raise a certain > exception, then *in principle*

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote: > > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin > wrote: > > I do agree but maybe that suggests a different role for annotated > > exceptions in Python. Rather than attempting to enumerate all possible > > exceptions annotations could be used

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 5:27 AM Oscar Benjamin wrote: > > On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote: > > > > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin > > wrote: > > > I do agree but maybe that suggests a different role for annotated > > > exceptions in Python. Rather than attempti

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 6:05 AM Ricky Teachey wrote: > I'd like to hear more about why the empty tuple has been selected as the > default index. > It makes sense to me: if more than one index is passed, they are passed as a tuple. so many classes need to handle tuples anyway. What other options

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 3:36 PM Christopher Barker wrote: > On Fri, Sep 25, 2020 at 6:05 AM Ricky Teachey wrote: > >> I'd like to hear more about why the empty tuple has been selected as the >> default index. >> > > It makes sense to me: if more than one index is passed, they are passed as > a t

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 3:03 PM Paul Moore wrote: > On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote: > > There may be practical difficulties in sticking exceptions into > > annotations. Annotations already can be pretty long and bulky. But if > > you are okay with functions documenting that

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On 2020-09-25 20:36, Christopher Barker wrote: On Fri, Sep 25, 2020 at 6:05 AM Ricky Teachey > wrote: I'd like to hear more about why the empty tuple has been selected as the default index. It makes sense to me: if more than one index is passed, they are pas

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 1:36 PM MRAB wrote: > It currently doesn't support multiple indexes, so there's no distinction > between one index that's a 2-tuple and 2 indexes: d[(1, 2)] == d[1, 2]. > yeah, but one index isn't in a 1-tuple (much discussed on this thread), so now we have the someone aw

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, 25 Sep 2020 at 05:55, David Mertz wrote: > Smuggling in a generic function calls in square brackets is undesirable (but > obviously not preventable at a language level). However, I feel like > keywords might very often "alter the behavior." > > For example, imagine we have a distributed

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 20:36, Chris Angelico wrote: > > On Sat, Sep 26, 2020 at 5:27 AM Oscar Benjamin > wrote: > > > > On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote: > > > > > > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin > > > wrote: > > > > I do agree but maybe that suggests a differ

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, 25 Sep 2020 at 14:07, Ricky Teachey wrote: > > I'd like to hear more about why the empty tuple has been selected as the > default index. It's still not settled. Steven proposed None, I propose empty tuple for affinity with *args behavior, others proposed no positional arg at all, but the

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 1:43 PM Steven D'Aprano wrote: > On Fri, Sep 25, 2020 at 11:14:01PM +1000, Chris Angelico wrote: > > On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote: > > > > Surely there has to be a better way of programming than running stuff, > > > watching it fail, and then keepin

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin wrote: > > There are many common bugs that arise as a result of exceptions that > are overlooked. There are also often simple ways to rewrite the code > so that it becomes exception free. For example in sympy: > > if x.is_positive: # never raises

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 4:57 PM Stefano Borini wrote: > On Fri, 25 Sep 2020 at 14:07, Ricky Teachey wrote: > > > > I'd like to hear more about why the empty tuple has been selected as the > default index. > > It's still not settled. Steven proposed None, I propose empty tuple > for affinity with

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 7:05 AM Wes Turner wrote: >> "Well, if I get an import error, I can add some more directories to >> sys.path and try adding the values again, that might fix it..." >> >> Who does that? Not me. And I bet you don't either. > > > "Defensive programming" / "Offensive programmin

[Python-ideas] Re: Suggestion: annotated exceptions

(Executing arbitrary code on a production server is debugging in production. Logging (additional information added to exceptions with 'raise _ from _`) may assist with root cause analysis and debugging on a different instance but IMHO logging is not debugging.) On Fri, Sep 25, 2020, 5:18 PM Chris

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 7:25 AM Wes Turner wrote: > > (Executing arbitrary code on a production server is debugging in production. > > Logging (additional information added to exceptions with 'raise _ from _`) > may assist with root cause analysis and debugging on a different instance but > IMHO

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

Ricky, I'd love new dunders too but it would explode in complexity. The likelihood of being approved is pretty much non-existent as far as I understand. If you want, we can write together a competing PEP with that solution, so that the Steering Council can have two ideas. I would not mind explorin

[Python-ideas] Re: Suggestion: annotated exceptions

What a worthless semantic distinction. You don't want to be executing code to determine why an Exception occurred because you do not trust support devs to access all of the data in the production system. "Exceptions happen" is true, but that's not satisfactory in an organization focused on qualit

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, 25 Sep 2020 at 22:05, Chris Angelico wrote: > > On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin > wrote: > > > > There are many common bugs that arise as a result of exceptions that > > are overlooked. There are also often simple ways to rewrite the code > > so that it becomes exception fr

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 8:17 AM Wes Turner wrote: > > What a worthless semantic distinction. > > You don't want to be executing code to determine why an Exception occurred > because you do not trust support devs to access all of the data in the > production system. > > "Exceptions happen" is tru

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 8:48 AM Oscar Benjamin wrote: > > On Fri, 25 Sep 2020 at 22:05, Chris Angelico wrote: > > > > On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin > > wrote: > > > > > > There are many common bugs that arise as a result of exceptions that > > > are overlooked. There are also of

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 8:09 PM Chris Angelico wrote: > On Sat, Sep 26, 2020 at 8:17 AM Wes Turner wrote: > > > > What a worthless semantic distinction. > > > > You don't want to be executing code to determine why an Exception > occurred because you do not trust support devs to access all of the

[Python-ideas] Re: Suggestion: annotated exceptions

On Sat, Sep 26, 2020 at 10:19 AM Wes Turner wrote: > > > > On Fri, Sep 25, 2020 at 8:09 PM Chris Angelico wrote: >> >> On Sat, Sep 26, 2020 at 8:17 AM Wes Turner wrote: >> > >> > What a worthless semantic distinction. >> > >> > You don't want to be executing code to determine why an Exception oc

[Python-ideas] Re: Suggestion: annotated exceptions

Depth-first-search for every callable, [property] descriptor, operator, __getitem__ On Fri, Sep 25, 2020 at 4:36 PM Wes Turner wrote: > > LSP servers and clients: https://langserver.org/ > - https://github.com/microsoft/python-language-server > - > https://code.visualstudio.com/api/language-ex

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 4:32 am, Oscar Benjamin wrote: annotations could be used to document in a statically analysable way what the "expected" exceptions are. A type checker could use those to check whether a caller is handling the *expected* exceptions But that would be inappropriate. Even if an exceptio

[Python-ideas] Re: Suggestion: annotated exceptions

Search upwards for what (if anything) is going to catch an Exception would be a mighty useful static/dynamic analysis thing. Is there anything that can do this? I'd hazard to guess that *most* apps will just crash and expect the process spawner (e.g. systemd, supervisord, not sysV init) to re-spaw

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 08:01:39PM +0100, Paul Moore wrote: > On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote: > > There may be practical difficulties in sticking exceptions into > > annotations. Annotations already can be pretty long and bulky. But if > > you are okay with functions documenti

[Python-ideas] Re: Suggestion: annotated exceptions

On Fri, Sep 25, 2020 at 04:58:00PM -0400, Wes Turner wrote: > On Fri, Sep 25, 2020 at 1:43 PM Steven D'Aprano wrote: > > Of course rare or unusual exceptions probably won't be discovered > > without a lot of testing, including stress testing, or not until the > > code goes out into production. Th

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

Quoting levels are a bit messed up in David's post, I've tried to fix them bu apologies if I'm attributing words to David that he didn't write. On Thu, Sep 24, 2020 at 07:04:31PM -1000, David Mertz wrote: > Is this a breaking change? It feels borderline. > > > Keyword-only subscripts are perm

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 05:05:52PM -0400, Ricky Teachey wrote: > * sheepishly, whispering mostly to myself * > > All of that could be solved with new dunders. What would be the signature of the new dunders? How will the new dunders be backwards compatible? Previous discussions on this required

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 09:53:41PM +0100, Stefano Borini wrote: > On Fri, 25 Sep 2020 at 05:55, David Mertz wrote: > > Smuggling in a generic function calls in square brackets is > > undesirable (but obviously not preventable at a language level). > > However, I feel like keywords might very o

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 4:36 PM Steven D'Aprano wrote: > > I.e. consider: > > >>> d = dict() > > >>> d[()] = "foo" > > >>> d > > {(): 'foo'} > > I agree with Ricky that the choice of empty tuple should be justified > better by the PEP, and alternatives (None, NotImplemented) discussed. > But I do

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 5:27 am, Wes Turner wrote: Safe coding styles (in other languages) do specify that *there may not be any unhandled exceptions*. I don't think a blind rule like that actually makes a program any safer. It encourages a coding style that covers up problems and carries on to produce ga

[Python-ideas] Re: Suggestion: annotated exceptions

On 2020-09-26 01:23, Greg Ewing wrote: On 26/09/20 4:32 am, Oscar Benjamin wrote: annotations could be used to document in a statically analysable way what the "expected" exceptions are. A type checker could use those to check whether a caller is handling the *expected* exceptions But that wou

[Python-ideas] Re: PEP 637 and keyword only subscripts

Change of subject line as I wish to focus on a single critical point of the PEP: keyword-only subscripts. TL;DR: 1. We have to pass a sentinel to the setitem dunder if there is no positional index passed. What should that sentinel be? * None * the empty tuple () * NotImplemented * somethi

[Python-ideas] Re: PEP 9999 (provisional): support for indexing with keyword arguments

Thanks Eric, On Fri, Sep 25, 2020 at 09:23:56AM +0100, Eric Wieser wrote: > Thanks for the PEP, and for pinging the numpy list about it. Some comments: > > Sequence unpacking remains a syntax error inside subscripts: > Reason: unpacking items would result it being immediately repacked into a > tu

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 6:06 PM Stefano Borini wrote: > Ricky, I'd love new dunders too but it would explode in complexity. > The likelihood of being approved is pretty much non-existent as far as > I understand. > > If you want, we can write together a competing PEP with that solution, > so that

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 7:26 am, Oscar Benjamin wrote: The suggestion ... was not that it would be a type-checking error to call the inverse function without catching the exception. It only becomes a type-checking error if a function calls the inverse function and claims not to raise the exception. This is

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Fri, Sep 25, 2020 at 8:26 PM David Mertz wrote: > E.g. we would have: > > newthing[(), foo=1, bar=4:5] == newthing[foo=1, bar=4:5] > Right, but we also have newthing[(2, 3), foo=1, bar=4:5] == newthing[2, 3, foo=1, bar=4:5] which seems exactly analogous. A disambiguation scheme that

[Python-ideas] Re: PEP 637 and keyword only subscripts

On Fri, Sep 25, 2020 at 11:50 PM Steven D'Aprano wrote: > TL;DR: > > 1. We have to pass a sentinel to the setitem dunder if there is no > positional index passed. What should that sentinel be? > Isn't there a problem with this starting assumption? Say that I have item dunder code of the signatu

[Python-ideas] Re: PEP 637 and keyword only subscripts

But this requires introspection. On Fri, Sep 25, 2020 at 22:46 Ricky Teachey wrote: > On Fri, Sep 25, 2020 at 11:50 PM Steven D'Aprano > wrote: > >> TL;DR: >> >> >> >> >> >> 1. We have to pass a sentinel to the setitem dunder if there is no >> >> >> positional index passed. What should that sen

[Python-ideas] Re: PEP 637 and keyword only subscripts

On Sat, Sep 26, 2020 at 1:51 AM Guido van Rossum wrote: > But this requires introspection. > I'm sorry Guido I'm staring at your message and reread mine several times and I don't understand where introspection is required. It seems like all the parser has to do is what it has always done-- pass

[Python-ideas] Re: PEP 637 and keyword only subscripts

On Fri, Sep 25, 2020, 5:49 PM Steven D'Aprano > Since both None and () are likely to be legitimate indexes, and > NotImplemented is less likely to be such, I think this supports using > NotImplemented. > I think your arguments for NotImplemented vs None or () are solid. But I'm having trouble cro