[Python-ideas] Re: Adding a "once" function to functools

On May 1, 2020, at 09:51, Tom Forbes wrote: >  >> You’ve written an exactly equIvalent to the double-checked locking for >> singletons examples that broke Java 1.4 and C++03 and led to us having once >> functions in the first place. >> … but what about on Jython, or PyPy-STM, or a future

[Python-ideas] Re: is a

On the subject of custom infix operators, there are at least two packages on PyPI that allow you to do this already: https://pypi.org/project/funcoperators/ https://pypi.org/project/infix/ On Sat, May 2, 2020 at 12:51 AM Steven D'Aprano wrote: > On Fri, May 01, 2020 at 07:41:57PM -0700, Andrew

[Python-ideas] Re: is a

On Fri, May 01, 2020 at 07:41:57PM -0700, Andrew Barnert wrote: > The most obvious way to do it is borrowing straight out of Haskell, so this: > > x `spam` y > > … compiles to exactly the same code as this: > > spam(x, y) I really, really want to like that syntax, but I can't. The

[Python-ideas] Introduce 100 more built-in exceptions

Executive summary: 1. Don't distinguish exceptions if it won't make a difference to how you handle them (Andrew also makes this point, and I think it's implicit in MAL's post about exception vs. the reason as well). 2. Usefully introducing more fine-grained exceptions requires that

[Python-ideas] Re: Introduce 100 more built-in exceptions

Steven D'Aprano writes: > It took me far too long to learn the difference between > UnicodeEncodingError and UnicodeDecodingError. Or is it > UnicodeEncodeError and UnicodeDecodeError? That's why we provide UnicodeNothingInTheMiddleError. ;-) ___

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 01, 2020 at 09:23:20AM -0700, Christopher Barker wrote: > I'm not sure how this could reasonably work, but maybe we could standardize > that all Exceptions have an .errno attribute, and a standard mapping > between the errorno and a message, or, > > Even if most Exceptions would

[Python-ideas] Re: is a

I guess I need to remind folks about the reasons why infix operators are useful. It's not (primarily) about the lack of parentheses or the resemblance to English (oh horror). It's about the *associative property*. For example, it's a good idea to use a binary operator for string concatenation,

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 01, 2020 at 06:59:01PM -0700, Andrew Barnert wrote: > >> For example, in 2.x, to get the filename that failed to open, you had > >> to regex .args[0], and that sucked. > > > > Why would you parse the error message when you already have the > > file name? > > > > try: > >f

[Python-ideas] Re: Function to avoid a global variable

On Sat, May 2, 2020 at 10:17 AM Terry Reedy wrote: > > On 5/1/2020 7:30 PM, Chris Angelico wrote: > > > @static(called=0) > > def other_function(): > > me.called += 1 > > ... > > > > Obviously the name "me" can't be used, as it'd break a bunch of code, > > but conceptually this would be

[Python-ideas] Re: is a

On May 1, 2020, at 15:35, Steven D'Aprano wrote: > > but if it is all functions, then I think you have no choice but to > either live with it or shift languages, because the syntax for functions > is too deeply baked into Python to change now. Actually, I’m pretty sure Python could add infix

[Python-ideas] Re: Introduce 100 more built-in exceptions

On May 1, 2020, at 16:32, Steven D'Aprano wrote: > > On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas > wrote: >>> On May 1, 2020, at 09:24, Christopher Barker wrote: >>> Maybe it's too late for this, but I would love it if ".errno or similar" >>> were more

[Python-ideas] Re: zip(x, y, z, strict=True)

On Thu, Apr 30, 2020 at 07:58:16AM -0700, Christopher Barker wrote: > Imagine someone that uses zip() in code that works for a while, and then > discovers a bug triggered by unequal length inputs. > > If it’s a flag, they look at the zip docstring, and find the flag, and > their problem is

[Python-ideas] Re: zip(x, y, z, strict=True)

On Tue, Apr 28, 2020 at 02:46:35PM -, Brandt Bucher wrote: > Over the course of the last week, it has become surprisingly clear > that this change is controversial enough to require a PEP. I cannot imagine why you were surprised about that. Did you already forget about the experience of

[Python-ideas] Re: Introduce 100 more built-in exceptions

> On May 1, 2020, at 14:34, Christopher Barker wrote: > > But it seems clear that "doing a big revamp if all the Exceptions and adding > alot more subclasses" is not supported. Which doesn't means that a few more > expansions wouldn't be excepted. > > So folks that like this idea may be best

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas wrote: > On May 1, 2020, at 09:24, Christopher Barker wrote: > > > > Maybe it's too late for this, but I would love it if ".errno or similar" > > were more standardized. As it is, every exception may have it's own way to

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 01, 2020 at 11:30:17PM +0200, Alex Hall wrote: > Specifically the PEP says: > > > Another proposed idiom, per-module shadowing of the built-in zip with some > > subtly different variant from itertools, is an anti-pattern that shouldn't > > be encouraged. > > > > I think the PEP is

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 01, 2020 at 05:16:00PM -0300, Soni L. wrote: > >I say again, YAGNI. Give an actual use-case for the excessive > >generality of your proposal - namely, the ability to provide a custom > >function. And show that it's better with zip than just with a custom > >generator function. > > we

[Python-ideas] Re: is a

Hi Gavin, You have Reply To set to your personal email address instead of allowing replies to go to the list for everyone to contribute to the discussion. Was that intentional? On Fri, May 01, 2020 at 04:53:31PM -, gbs--- via Python-ideas wrote: > In cases where it makes sense to do

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 12:28 PM Andrew Barnert wrote: > > Maybe it's too late for this, but I would love it if ".errno or similar" > were more standardized. As it is, every exception may have it's own way to > find out more about exactly what caused it, and often you are left with > parsing the

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 1, 2020 at 10:58 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > A separate function can be used in third-party libraries immediately, as > long as there’s an available backport (whether that’s more-iterools, or a > trivial zip39 or whatever) that they can

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 1, 2020 at 5:55 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On May 1, 2020, at 11:19, Brandt Bucher wrote: > > > > I have pushed a first draft of PEP 618: > > > > https://www.python.org/dev/peps/pep-0618 > > The document says “… with nobody challenging the

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

> but the main > benefit is, again, being able to get the iterated values which were > silently swallowed by zip when the iteration stopped. I don't think the call back idea is terrible, however, it doesn't really seem to have a usecase that isn't covered by zip_longest with a sentinel. Now as

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On May 1, 2020, at 11:19, Brandt Bucher wrote: > > I have pushed a first draft of PEP 618: > > https://www.python.org/dev/peps/pep-0618 The document says “… with nobody challenging the use of the word ‘strict’”, but people did challenge it, and even more people just called it “equal” instead

[Python-ideas] Re: is a

On May 1, 2020, at 10:27, gbs--- via Python-ideas wrote: > > In cases where it makes sense to do explicit type checking (with ABCs or > whatever), I really detest the look of the isinstance() function. > > if isinstance(thing, Fruit) and not isinstance(thing, Apple): > > Yucky. I think

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-01 4:43 p.m., Chris Angelico wrote: On Sat, May 2, 2020 at 5:21 AM Soni L. wrote: > > > > On 2020-05-01 3:41 p.m., Chris Angelico wrote: > > On Sat, May 2, 2020 at 4:38 AM Soni L. wrote: > > > > > > > > > > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote: > > > > I have pushed a

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 05/01/2020 02:19 AM, Steven D'Aprano wrote: Best practice is to put try...except around only a *single* operation which may raise what you want to catch. Of course that's easier said than done, especially since nearly anything can raise nearly anything. The follow-on to that is to only

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Sat, May 2, 2020 at 5:21 AM Soni L. wrote: > > > > On 2020-05-01 3:41 p.m., Chris Angelico wrote: > > On Sat, May 2, 2020 at 4:38 AM Soni L. wrote: > > > > > > > > > > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote: > > > > I have pushed a first draft of PEP 618: > > > > > > > >

[Python-ideas] Re: Introduce 100 more built-in exceptions

On May 1, 2020, at 09:24, Christopher Barker wrote: > > Maybe it's too late for this, but I would love it if ".errno or similar" were > more standardized. As it is, every exception may have it's own way to find > out more about exactly what caused it, and often you are left with parsing > the

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-01 3:41 p.m., Chris Angelico wrote: On Sat, May 2, 2020 at 4:38 AM Soni L. wrote: > > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote: > > I have pushed a first draft of PEP 618: > > > > https://www.python.org/dev/peps/pep-0618 > > > > Please let me know what you think – I'd love

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 01/05/2020 19:10, Brandt Bucher wrote: I have pushed a first draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any *new* feedback that hasn't yet been addressed in the PEP! Not sure whether you class this as new, but I think

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Sat, May 2, 2020 at 4:38 AM Soni L. wrote: > > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote: > > I have pushed a first draft of PEP 618: > > > > https://www.python.org/dev/peps/pep-0618 > > > > Please let me know what you think – I'd love to hear any *new* feedback > > that hasn't yet

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On 2020-05-01 3:10 p.m., Brandt Bucher wrote: I have pushed a first draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any *new* feedback that hasn't yet been addressed in the PEP! What about using an optional kwarg for a

[Python-ideas] Re: is a

`yield from` is a case where two keywords are used together to do something new, but they're both keywords independently of each other. If `a` can be variable or a keyword, we'd have to decide when `x is a y` is using `a` as a keyword and when it's using it as a variable. I don't think introducing

[Python-ideas] PEP 618: Add Optional Length-Checking To zip

I have pushed a first draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any *new* feedback that hasn't yet been addressed in the PEP! Brandt ___ Python-ideas mailing list --

[Python-ideas] Re: is a

On 2020-05-01 2:46 p.m., Steele Farnsworth wrote: So this would make `a` a new keyword. I don't think that could be added into python 4 at the earliest because it would immediately break all code for which `a` is a variable name. we could have keyphrases instead of keywords, tbh. I can

[Python-ideas] Re: is a

So this would make `a` a new keyword. I don't think that could be added into python 4 at the earliest because it would immediately break all code for which `a` is a variable name. I can appreciate wanting to make simple operations easy to read, though I think this relies too much on understanding

[Python-ideas] Re: zip(x, y, z, strict=True)

On May 1, 2020, at 08:08, Christopher Barker wrote: > > Also please keep in mind that the members of this list, and the python-dev > list, are not representative of most Python users. Certainly not beginners > but also many (most?) fairly active, but more "casual" users. > > Folks on this

[Python-ideas] is a

In cases where it makes sense to do explicit type checking (with ABCs or whatever), I really detest the look of the isinstance() function. if isinstance(thing, Fruit) and not isinstance(thing, Apple): Yucky. What I really want to write is: if thing is a Fruit and thing is not an Apple: and

[Python-ideas] Re: Adding a "once" function to functools

> Risks: Any reentrancy or recursion will result in deadlock. Reentrancy is a great point that I didn’t consider. I would say that as the intended use case for this is returning lazy singletons of some kind then reentrant calls would be a bug that would end with a recursion error - which is

[Python-ideas] Re: Adding a "once" function to functools

> You’ve written an exactly equIvalent to the double-checked locking for > singletons examples that broke Java 1.4 and C++03 and led to us having once > functions in the first place. > … but what about on Jython, or PyPy-STM, or a future GIL-less Python? While I truly do appreciate your

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 1:24 PM Christopher Barker wrote: > On Fri, May 1, 2020 at 1:38 AM M.-A. Lemburg wrote: > >> Adding more exception types to the stack makes sense when there's >> a dedicated need to catch only specific sub types, but even there >> it's already possible to add this extra

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 1:38 AM M.-A. Lemburg wrote: > Adding more exception types to the stack makes sense when there's > a dedicated need to catch only specific sub types, but even there > it's already possible to add this extra information to the exception > objects as e.g. .errno or similar

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 5/1/2020 9:21 AM, André Roberge wrote: On Fri, May 1, 2020 at 10:15 AM Rhodri James > wrote: On 01/05/2020 07:48, Ram Rachum wrote: > There are 2 reasons I want this: > > 1. When I'm writing a try..except clause, I want to catch a specific

[Python-ideas] Re: zip(x, y, z, strict=True)

It's all been said. There is a PEP being written, so we should all make sure our arguments are well represented there, and let the decision be made. But in all the discussion about usability and discoverability, etc, please keep in mind that zip() is a builtin, and zip_longest() and any other

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, 1 May 2020 10:21:22 -0300 André Roberge wrote: > On Fri, May 1, 2020 at 10:15 AM Rhodri James wrote: > > > On 01/05/2020 07:48, Ram Rachum wrote: > > > There are 2 reasons I want this: > > > > > > 1. When I'm writing a try..except clause, I want to catch a specific > > > exception like

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 01.05.2020 11:40, Peter Otten wrote: > M.-A. Lemburg wrote: > >> Hi Ram, >> >> I think you are confusing the exception type with the exception >> reason. By adding 100 more exception types, you don't make things >> easier, but instead you complicate things, since we'd all have >> to memorize

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 2020-05-01 3:48 a.m., Ram Rachum wrote: Hi, Here's something I wanted in Python for many years. If this has been discussed in the past, please refer me to that discussion. On one hand, it's something that I can't imagine the python-dev community supporting. On the other hand, it would

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 10:15 AM Rhodri James wrote: > On 01/05/2020 07:48, Ram Rachum wrote: > > There are 2 reasons I want this: > > > > 1. When I'm writing a try..except clause, I want to catch a specific > > exception like MissingArgumentsError rather than ValueError or TypeError. > > They're

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 01/05/2020 07:48, Ram Rachum wrote: There are 2 reasons I want this: 1. When I'm writing a try..except clause, I want to catch a specific exception like MissingArgumentsError rather than ValueError or TypeError. They're too ubiquitous. I don't want some other unexpected failure producing the

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 4:34 AM Ram Rachum wrote: > On Fri, May 1, 2020 at 10:28 AM Serhiy Storchaka > wrote: > >> Could you please provide a list of these 100 exceptions? If you create a >> PR, with documentation and tests, it would be a good start of the >> discussion. >> > > That's not a

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 01, 2020 at 11:36:40AM +0300, Ram Rachum wrote: > I thought of a third advantage to this approach: Except clauses will be > easier to understand. > > If I'm reading someone's code and I see `except ValueError`, I'm gonna have > to do a bit of thinking to figure out what exactly

[Python-ideas] Re: Introduce 100 more built-in exceptions

M.-A. Lemburg wrote: > Hi Ram, > > I think you are confusing the exception type with the exception > reason. By adding 100 more exception types, you don't make things > easier, but instead you complicate things, since we'd all have > to memorize those 100 exception types. > > That said,

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 12:28 PM Steven D'Aprano wrote: > Is "100 more exceptions" hyperbole? Or do you actually mean precisely > one hundred more exceptions? > It is hyperbole. I should have realized that the way I phrased it was provocative. Maybe people would have responded better if I put

[Python-ideas] Re: Introduce 100 more built-in exceptions

Is "100 more exceptions" hyperbole? Or do you actually mean precisely one hundred more exceptions? On Fri, May 01, 2020 at 09:48:21AM +0300, Ram Rachum wrote: [...] > I know it'll raise a ValueError, because I've memorized that, but it did > take me a few years to remember where I should

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 01.05.2020 10:44, Ram Rachum wrote: > > > On Fri, May 1, 2020 at 11:37 AM M.-A. Lemburg > wrote: > > Hi Ram, > > I think you are confusing the exception type with the exception > reason. > > > Some time ago `ModuleNotFoundError` was added as a subclass

[Python-ideas] Re: Introduce 100 more built-in exceptions

01.05.20 10:32, Ram Rachum пише: On Fri, May 1, 2020 at 10:28 AM Serhiy Storchaka > wrote: Could you please provide a list of these 100 exceptions? If you create a PR, with documentation and tests, it would be a good start of the discussion. That's

[Python-ideas] Re: Introduce 100 more built-in exceptions

Recent related discussion: https://mail.python.org/archives/list/python-ideas@python.org/thread/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/ On Fri, May 1, 2020 at 8:53 AM Ram Rachum wrote: > Hi, > > Here's something I wanted in Python for many years. If this has been > discussed in the past, please

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 11:37 AM M.-A. Lemburg wrote: > Hi Ram, > > I think you are confusing the exception type with the exception > reason. Some time ago `ModuleNotFoundError` was added as a subclass of `ImportError`, which I really liked. Was this also another instance of a confusion between

[Python-ideas] Re: Introduce 100 more built-in exceptions

I thought of a third advantage to this approach: Except clauses will be easier to understand. If I'm reading someone's code and I see `except ValueError`, I'm gonna have to do a bit of thinking to figure out what exactly they're catching. On the other hand, if the code is `except

[Python-ideas] Re: Introduce 100 more built-in exceptions

Hi Ram, I think you are confusing the exception type with the exception reason. By adding 100 more exception types, you don't make things easier, but instead you complicate things, since we'd all have to memorize those 100 exception types. That said, enhancing the error reasons texts is

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Fri, May 1, 2020 at 10:28 AM Serhiy Storchaka wrote: > Could you please provide a list of these 100 exceptions? If you create a > PR, with documentation and tests, it would be a good start of the > discussion. > That's not a reasonable request. If there's enough support for this idea, then

[Python-ideas] Re: Introduce 100 more built-in exceptions

01.05.20 09:48, Ram Rachum пише: I wish there were a 100 more built-in exceptions in Python, that will be very specific about what went wrong. If I do this:     >>> x, y = range(3) I know it'll raise a ValueError, because I've memorized that, but it did take me a few years to remember

[Python-ideas] Introduce 100 more built-in exceptions

Hi, Here's something I wanted in Python for many years. If this has been discussed in the past, please refer me to that discussion. On one hand, it's something that I can't imagine the python-dev community supporting. On the other hand, it would maintain backward compatibility. I wish there