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

[Andrew Barnert via Python-ideas]

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 GIL-less Python?
> 
> While I truly do appreciate your feedback on this idea, I’m really not clear 
> on your line of reasoning here. What specifically do you propose would be the 
> issue with the *Python* implementation? Are you proposing that under some 
> Python implementations `cache = func()` could be… the result of half a 
> function call? I could buy an issue with some implementations meaning that 
> `cache` still appears as `sentinel` in specific situations, but I feel that 
> would constitute a pretty obvious bug in the implementation that would impact 
> a _lot_ of other multithreaded code rather than a glaring issue with this 
> snippet. Both the issues you’ve referenced valid, but also are rather 
> specific to the languages that they affect. I don’t believe they apply to 
> Python.

But the issues really aren’t specific to C++ and Java. The only reason C#, 
Swift, Go, etc. don’t have the same problem is that their memory models were 
designed from the start to provide a way to do this correctly. Python was not. 
There was an attempt to define a memory model in the 00’s (PEP 583), but it was 
withdrawn.

According to the discussion around that PEP about when you can see 
uninitialized variables (not exactly the same issue, but closely related), 
Jython is safe when they’re globals or instance attributes and you haven’t 
replaced the module or object dict, but otherwise probably not; IronPython is 
probably safe in the same cases and more but nobody’s actually sure. Does that 
sound good enough to dismiss the problem?

> I still think the point stands. With your two-separate-decorators approach 
> you’re paying it on every call. As a general purpose `call_once()` 
> implementation I think the snippet works well, but obviously if you have some 
> very specific use-case where it’s not appropriate - well then you are 
> probably able to write a very specific and suitable decorator.

Being willing to trade safety or portability for speed is sometimes a good 
tradeoff, but that’s the special use case, not the other way around. People who 
don’t know exactly what they need should get something safe and portable.

Plus, there’s still the huge issue with single-threaded programs. It’s not like 
multi-threaded programs are ubiquitous in Python but, e.g., asyncio is some 
rare niche thing that the stdlib doesn’t have to worry about. A bunch of 
coroutines using a once function needs either nothing, or a coro lock; if you 
build a threading lock into the function, they waste time and maybe deadlock 
every 1 startups for no benefit whatsoever. Why is that acceptable for a 
general purpose function?

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

[Python-ideas] Re: is a

[Jonathan Goble]

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 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 backticks
> get in the way. It's not that I don't like backticks. I do. But to the
> degree that "infix operators" are words:
>
> x is y
>
> rather than symbols, the backticks get in the way of it looking like a
> word:
>
> x `is` y
>
> Even though they're only grit on Tim's monitor *wink* nevertheless they
> stand out too much for my liking. (Maybe I wouldn't think so if my
> native language used more accents?)
>
> So I'm afraid that I can't get past the idea that for a good looking,
> attractive syntax, you can either go whole-hog for Hypertalk-like
> natural(-ish) language syntax:
>
>the number of words of line 1 of text
>
> or functional notation:
>
>len(words(lines(text)[0]))
>
> but cramming them into the same language with backticks or dollar signs
> or some other sygil might be technically possibly but aesthetically
> ugly.
>
> (Likewise I like Forth-like RPN code, but I don't think trying to cram
> it into Python would look good.)
>
>
> [...]
> > For this particular use case:
> >
> > isa = isinstance
> > thing `isa` Fruit and not thing `isa` Apple
> >
> > … honestly, the lack of any parens here makes it seem harder to read,
> > even if it is a bit closer to English.
>
> Do you think the same about this?
>
> thing is None and not obj is None
>
> If not, perhaps its just familiarity. Or the backticks getting in the
> way for you too :-)
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YMYFH3RB35CL6VXHPXS5Z3HJYJMQZHTW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RY6KL7E2JJP5MLLLWQS4ERSPU5FWGCYH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: is a

[Steven D'Aprano]

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 backticks 
get in the way. It's not that I don't like backticks. I do. But to the 
degree that "infix operators" are words:

x is y

rather than symbols, the backticks get in the way of it looking like a 
word:

x `is` y

Even though they're only grit on Tim's monitor *wink* nevertheless they 
stand out too much for my liking. (Maybe I wouldn't think so if my 
native language used more accents?)

So I'm afraid that I can't get past the idea that for a good looking, 
attractive syntax, you can either go whole-hog for Hypertalk-like 
natural(-ish) language syntax:

   the number of words of line 1 of text

or functional notation:

   len(words(lines(text)[0]))

but cramming them into the same language with backticks or dollar signs 
or some other sygil might be technically possibly but aesthetically 
ugly.

(Likewise I like Forth-like RPN code, but I don't think trying to cram 
it into Python would look good.)


[...]
> For this particular use case:
> 
> isa = isinstance
> thing `isa` Fruit and not thing `isa` Apple
> 
> … honestly, the lack of any parens here makes it seem harder to read, 
> even if it is a bit closer to English.

Do you think the same about this?

thing is None and not obj is None

If not, perhaps its just familiarity. Or the backticks getting in the 
way for you too :-)


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

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

[Stephen J. Turnbull]

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
*other* people use them when *you* want them to.  Both
introspection into my own behavior and the complaint about "shitty
corporate systems" suggests that's a "Not Gonna Happen" for all of
the proposed exceptions (I think this is Steven d'Aprano's point,
too).

Ram Rachum writes:

 > If I do this:

 > >>> x, y = range(3)

 > It would be nice if the operation above raised UnpackingOverflowError,
 > which will be a subclass of UnpackingError, along with
 > UnpackingUnderflowError.  UnpackingError can be a subclass of ValueError,
 > for backward compatibility.

It's not a matter of backward compatibility (unless the Exception
class to raise was chosen incorrectly in the first place).  The point
of distinguishing among Exceptions is that you want to handle them
differently.  But there's not much you can do with a ValueError or
TypeError, because Python implements the "termination model" of
exception handling.  That is, the program stops what it's doing, and
throws away all the work done to that point, including the
continuation.  It's generally going to be somewhere between
impractical and impossible to determine how to fix the input to the
computation and restart it.  You either need to fix the program and
run it on the same inputs, or go on to the next input.  Even if you
raise a specific subclass, I'm probably going to handle it the same as
any other ValueError.

On the other hand, there are a plethora of environment errors, such as
3 suberrors of ConnectionError, at least 6 different errors related to
opening filesystem objects, and so on.  Why?  Because there are well-
known, common strategies allowing programs to recover from such
errors, and programs that catch them are prepared for them with
specific handlers for each such exception.

I admit I don't recall offhand ever making a pragmatic distinction
between TypeError and ValueError myself, except that ValueErrors are
often validation errors (eg, a typo), while TypeErrors are invariably
a logic error in my experience.  But that's a difference in how I
respond, not in how my program does.  So the principle "don't make
distinctions without a difference" isn't followed 100% (at least in
terms of my personal pragmatics).  But nothing's perfect.  The best we
can do is to not make things worse.

 > Similarly, if I did this:
 > 
 > >>> def f(x, y): return x + y
 > >>> f(1)
 > 
 > I would get a TypeError. Would be a lot cooler if I got
 > MissingArgumentsError, which would be a subclass of SignatureError, which
 > would be a subclass of TypeError.

Cool, maybe, but the relevant question for distinguishing a new
exception is how would your *program* respond differently to a
different subclass of SignatureError or TypeError?

 > 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 same ValueError and triggering my except clause.

If you're writing the code that raises the Exception, I see no problem
except your willingness to define the appropriate subclasses of
ValueError.  :-)

For SomebodyElse'sCode, here's the rub:

 > 2. When I get an error, especially from some shitty corporate system that
 > truncates the traceback, I want to get as many hints as possible about what
 > went wrong.

Why do you think "shitty corporate systems" (or quick hacks on PyPI)
are going to use fine-grained exceptions (a) correctly (b) at all?
(This is a real question, despite my obvious priors as to the answer.)

 > It's true that today, most Python exceptions have good text in their
 > message, like "TypeError: f() missing 1 required positional argument: 'y'".
 > But that isn't guaranteed everywhere, and specific exception types could
 > help.

I don't see much chance of that pragmatically.  I write a lot of code
that just raises RuntimeError because I don't feel like looking up and
figuring out the appropriate subclass.  Some of that code makes it
into production, to my later chagrin.  (Mostly not: "replace all
RuntimeErrors with something appropriate" is on my personal review
checklist. :-)  IMO, if developers aren't willing to write a descriptive
message, the effort to choose a specific exception appropriately is
unlikely to be worth it to them.  That effort is at best strictly
convex, and quite possibly exponential, in the number of Exceptions
defined.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org

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

[Stephen J. Turnbull]

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 mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ERE5F7J576Q4CLZNBX7Y3MDKSAAL7WZC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 have only a single error number, this would
> be a standardized way to add extra info to any Exception.

Okay, I've given this a bit more thought and I think that I have a way 
to make this -- maybe -- practical without having to have a universal 
global registry. There will still be a registry, but it will be per- 
installation, and generated dynamically when exceptions are raised.

Whether it's useful, I don't know. (That's a polite way of saying I 
don't think it is *wink* )

Whenever an exception is instantiated:

ValueError('too many chromions in the neutron flux')

`BaseException` looks for the combination of exception type and 
error message in a per-site database. If they are not already in the DB, 
it generates a new unique number for them. Once the error number is 
generated or retrieved, it is added to the exception instance.

Exceptions like StopIteration will need to opt-out of this costly 
process. That's easy enough: have the `BaseException.__init__` method 
call a public `register` method to do the work. If you want to opt-out, 
just set `register = None` in your class.

If one wanted to be a bit fancier, in a "Do What I Mean" kind of way, we 
could use string similarity rather than equality, so that minor typos 
in the error message won't be considered significant. The downside of 
that is that

ValueError('too many chromions in the neutron flux')
ValueError('too few chromions in the neutron flux')

will probably count as being similar (edit distance of 1 word), which 
you may not want.

Being site-specific, the error numbers won't necessarily correspond 
between one site and the next. So you can't google for error numbers. 
There would have to be some sort of tool for looking them up in the 
database.

I'm not entirely sure what we would do with this error number once you 
have it, but there it is. It was fun to think about.

If anyone wants to experiment with this, you can use a mixin class 
in your exceptions without having to touch BaseException.


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

[Python-ideas] Re: is a

[Guido van Rossum]

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, since (s1 `concat` s2) `concat` s3 produces the same result
as s1 `concat` (s2 `concat` s3), so it's reasonable to write it as s1
`concat` s2 `concat` s3 rather than as concat(s1, concat(s2, s3)) or
concat(concat(s1, s2), s3). And sure, you could improve by having a varargs
concat() function (which we do: "".join(s1, s2, s3)), but that only goes so
far. But for a binary operation that doesn't have this useful (and rare!)
property, spelling it as an infix operator doesn't buy you much. This would
explain why `json.dump` makes a poor operator (and probably `round` too,
though I honestly have no idea what it does).

There's also the benefit of being able to combine *different* operators
without having to use parentheses (like 2*x + 3*y), but that depends
strongly on whether people can remember the priority of the various
operators. (Python, following C, takes this a bit  too far, and I have to
look up the associativity of shift and bitwise operators.) For newly minted
operators like `round` this benefit goes away -- presumably there's only
one priority for that form, and it probably is lower than all other
operators.

Finally there's the benefit of matching common mathematical operators that
are traditionally spelled as infix operators -- but most people know only a
handful of these, and some of those aren't even associative (e.g.
subtraction of vector cross product). Nevertheless, it's nice to be able to
follow the mathematical tradition, as long as the typical programmer is
familiar with that tradition. (Maybe there's a traditional "round" operator
in some field of math commonly practiced by numpy users that I've never
heard of?)

--Guido

On Fri, May 1, 2020 at 7:42 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> 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 calling without
> complicating the grammar much, or breaking backward compatibility at all. I
> don’t think it *should*, but maybe others would disagree.
>
> 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)
>
> That should be a very easy change to the grammar and no change at all to
> the later stages of compiling, so it’s about as simple as any new syntax
> could be. It doesn’t get in the way of anything else to the parser—and,
> more importantly, I don’t think it’s confusable as meaning something else
> to humans. (Of course it would be one extra thing to learn, like any syntax
> change.) Maybe something like $ instead of backticks is better for people
> with gritty monitors, but no point bikeshedding that (or the precedence)
> unless the basic idea is sound.
>
> Anyway, it’s up to the user to decide which binary functions to infix and
> which to call normally, which sounds like a consenting-adults issue, but…
> does it _ever_ look Pythonic?
>
> For this particular use case:
>
> isa = isinstance
>
> thing `isa` Fruit and not thing `isa` Apple
>
> … honestly, the lack of any parens here makes it seem harder to read, even
> if it is a bit closer to English.
>
> Here’s the best use cases I can come up with:
>
> xs `cross` ys
> array([[0,1], [1,1]]) `matrix_power` n
> prices `round` 2
>
> These are all things I have written infix in Haskell, and can’t in
> Python/NumPy, so you’d think I’d like the improvement… but if I can’t have
> real operators, I think I want dot-syntax methods with parens instead in
> Python:
>
> prices.round(2)
>
> And outside of NumPy, the examples seem to just get worse:
>
> with open(path, 'w') as f:
> obj `json.dump` f
>
> Of course maybe I’m just failing to imagine good examples.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AQPPHKL4EMFMT5NPB66W4GAFMGE5YYAB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to 

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

[Steven D'Aprano]

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 = open(filename)
> >   except IOError as err:
> >print(filename)
> 
>try:
>config = parse_config()
>except IOError as err:
>print(filename)

That's not a very convincing example, because surely if you are logging 
the error, or reporting it to the user, you need the entire error 
message. As a user, what am I to make of this?

/tmp/z

when you could show me this instead?

FileNotFoundError: [Errno 2] No such file or directory: '/tmp/z'

I might also argue that this is a poorly designed parse_config function 
for many reasons, but it's obvious to me that you intended it as only a 
toy example to match my toy example, not real-world code.

But that's the thing, there are many things which seem compelling when 
you only look at toy examples, but in real-world code they become less 
useful. For example, in a real-world config system, you probably have 
"read_config" try a series of multiple file names, in some specified 
order, rather than fail, and the config function itself logs the errors 
if you need them logged. Even if none of them are available, you ought 
to return default settings rather than fail.

(I've used applications that die if a config file isn't readable, and 
they are horrible to use. But I digress.)

In the standard library, my quick and dirty grep has found a few uses 
for err.filename in the stdlib:

- ten cases testing that it is set correctly; 
- one place where it appears to be copied from one exception to another;

and unless I've missed anything, that's it. Take from that what you 
will.

So in the spirit of always being open to learning something new, have 
you personally used the err.filename attribute, and if so, under what 
circumstances was it useful to you?



[...]
> At any rate, it’s a bit silly to relitigate this change. 

Was that what I was doing? Whew, thank goodness you told me, now I can 
cancel the PEP I was writing to deprecate and remove that feature! 

*wink*

But seriously... unless it is your position that every functional change 
made to the language and stdlib is by definition optimal, and therefore 
beyond question, I don't think it is "silly" to revist a change made a 
decade ago and see whether it actually turned out to be as useful as we 
hoped, *before* using that change as an example of a successful language 
feature that ought to be copied.

YAGNI is a genuine principle, and I cannot tell you how many times I've 
started custom exceptions and loaded them up with information that I 
surely would need to extract programmatically, only to discover that all 
I really needed was to read the error message. So please forgive me if 
I'm a bit cautious about the suggestion that we must load exceptions up 
with more information.


> All of the 
> new IOError subclasses where a filename is relevant have had a 
> filename attribute since 3.0, so this problem has been solved for over 
> a decade.

Since the filename attribute can be None, you still have to deal with 
the case where the filename is missing. (Even if it is rarer than it 
used to be.)


> If you really prefer the 2.x situation where sometimes those 
> exception instances had the filename and sometimes not, you’ll need a 
> time machine.

Since I've never been in a position where I needed to extract the file 
name from an exception, at least not as far as I can remember, I don't 
think I would care if it was missing or not. YMMV.


> >> It seems like every year or two, someone suggests that we should go
> >> through the stdlib and fix all the exceptions to be reasonably
> >> distinguishable and to make their relevant information more
> >> accessible, and I don’t think anyone ever has a problem with that,
> > 
> > I do!
> > 
> > Christopher's proposal of a central registry of error numbers and 
> > standardised error messages just adds a lot more work to every core 
> > developer for negligible or zero actual real world benefit.
> 
> You’re replying to a message saying “errno was a problem to be fixed, 

Not every obscure OS error should be given its own exception. It is good 
that the most common ones have been, like FileNotFoundError, but for 
rarer and more exotic exceptions, it isn't worth the bloat of adding 50 
exception subclasses which most people will never experience in their 
entire lifetime. So for those, a standard errno works great and I don't 
think it is a problem to be fixed.

In fact, I don't think it was a problem as such, it is just that 
separate exceptions for common failures was *even better*.


> not an ideal solution to emulate” and likewise having to parse errors. 
> And you’re insisting that you disagree because adding errno and 
> standardizing 

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

[Chris Angelico]

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 incredibly helpful. It'd also be a
> > reliable idiom for recursion optimization - any "me()" is guaranteed
> > to be recursion and may potentially give info to an optimizer.
> >
> > Perhaps, if Python had a way to identify the current function, it
> > would feel less odd to attach attributes to it.
>
> As one might imagine, something so 'obvious' has been proposed multiple
> times.  Reasons for repeated rejection.
>
> 1. Function bodies are compiled to code objects.  There is no function
> to 'bind' to and there might never be.  (compile(code_body, ...)).

True, but that's a bit of an edge case. I'm sure there are other edge
cases too - what happens with a 'nonlocal' if it's in a code object
outside of a function? (Or in the CPython implementation, what happens
with the corresponding cell lookup?) If  causes a RuntimeError if
used in such a context, or if the compilation of  creates some
sort of reference that simply doesn't work outside of a function, it'd
be fine.

> 2. Python does name resolution on function bodies when called.  If early
> binding of  were possible, it would be an exception.

It would have to be a keyword of a sort. Not necessarily an actual
keyword, although that would definitely work.

> 3. Recursion without names is really hard; hence the special
> head-spinning combinator to do that.

And that's a good reason to have compiler support for it. It would
make true recursion simple. (Obviously mutual recursion would still
require names.)

> 4. The post-compile function object address would only be useful for
> CPYthon, not for implementations that move objects around.

Why? It's an object. It should be possible to reference it.

> 5. The automatic conversion of recursion to a while loop only works for
> linear tail recursion.  In Python, such cases are usually better written
> directly as a for-loop.

True, and that would probably only be a small advantage anyway. But
it's also a clarity thing, and it means you don't have to name your
function inside the function and then remember to rename it.

There is another objection though:

6. Decorated functions would behave differently based on whether you
call by name or call by .

I don't have an answer to that, other than that giving programmers the
option isn't a bad thing. People would just have to be aware of the
distinction and know which one they want.

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

[Python-ideas] Re: is a

[Andrew Barnert via Python-ideas]

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 calling without complicating 
the grammar much, or breaking backward compatibility at all. I don’t think it 
*should*, but maybe others would disagree.

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)

That should be a very easy change to the grammar and no change at all to the 
later stages of compiling, so it’s about as simple as any new syntax could be. 
It doesn’t get in the way of anything else to the parser—and, more importantly, 
I don’t think it’s confusable as meaning something else to humans. (Of course 
it would be one extra thing to learn, like any syntax change.) Maybe something 
like $ instead of backticks is better for people with gritty monitors, but no 
point bikeshedding that (or the precedence) unless the basic idea is sound.

Anyway, it’s up to the user to decide which binary functions to infix and which 
to call normally, which sounds like a consenting-adults issue, but… does it 
_ever_ look Pythonic?

For this particular use case:

isa = isinstance

thing `isa` Fruit and not thing `isa` Apple

… honestly, the lack of any parens here makes it seem harder to read, even if 
it is a bit closer to English.

Here’s the best use cases I can come up with:

xs `cross` ys
array([[0,1], [1,1]]) `matrix_power` n
prices `round` 2

These are all things I have written infix in Haskell, and can’t in 
Python/NumPy, so you’d think I’d like the improvement… but if I can’t have real 
operators, I think I want dot-syntax methods with parens instead in Python:

prices.round(2)

And outside of NumPy, the examples seem to just get worse:

with open(path, 'w') as f:
obj `json.dump` f

Of course maybe I’m just failing to imagine good examples.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AQPPHKL4EMFMT5NPB66W4GAFMGE5YYAB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Andrew Barnert via Python-ideas]

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 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 message if you really want to know.
>> I don’t think there are many cases where a standardized .errno would 
>> help—and I think most such cases would be better served by separate 
>> exceptions. With OSError, errno was a problem to be fixed, not an ideal 
>> solution to emulate everywhere.
>> You do often need to be able to get more information, and that is a problem, 
>> but I think it usually needs to be specific to each exception, not something 
>> generic.
>> Does code often need to distinguish between an unpacking error and an int 
>> parsing error? If so, you should be able to handle UnpackingError and 
>> IntParsingError, not handle ValueError and check an .errno against some set 
>> of dozens of new builtin int constants. If not, then we shouldn’t change 
>> anything at all.
>> As for parsing the error message, that usually comes up because
>> there’s auxiliary information that you need but that isn’t accessible.
>> 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 = open(filename)
>   except IOError as err:
>print(filename)

   try:
   config = parse_config()
   except IOError as err:
   print(filename)

You can’t get the local variable out of some other function that you called, 
even with frame hacking.

At any rate, it’s a bit silly to relitigate this change. All of the new IOError 
subclasses where a filename is relevant have had a filename attribute since 
3.0, so this problem has been solved for over a decade. If you really prefer 
the 2.x situation where sometimes those exception instances had the filename 
and sometimes not, you’ll need a time machine.

>> It seems like every year or two, someone suggests that we should go
>> through the stdlib and fix all the exceptions to be reasonably
>> distinguishable and to make their relevant information more
>> accessible, and I don’t think anyone ever has a problem with that,
> 
> I do!
> 
> Christopher's proposal of a central registry of error numbers and 
> standardised error messages just adds a lot more work to every core 
> developer for negligible or zero actual real world benefit.

You’re replying to a message saying “errno was a problem to be fixed, not an 
ideal solution to emulate” and likewise having to parse errors. And you’re 
insisting that you disagree because adding errno and standardizing messages so 
they could be parsed would be a problem for maintainers as well as for users. 
Sure, you’re right, but that’s not in any way an argument against Ram’s 
proposal, or against the paragraph you quoted; if anything, it’s an argument 
*for* it.

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

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

[Steven D'Aprano]

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

Their problem is not solved. All they have is an exception. Now what are 
they going to do with it?

This is why I am still unconvinced that this functionality is anywhere 
near as useful as the proponents seem to think. Brandt has found one 
good example of a parsing bug in the ast library, but if he has shown 
how this zip_strict function will solve the bug, I haven't seen it.

In any case, even giving Brandt the benefit of the doubt that this will 
solve the ast bug, its hard for me to generalise from that. If I'm 
expecting equal length inputs, and don't get them, what am I supposed to 
do with the exception as the consumer of the inputs?

As the consumer of the inputs, I can pass the buck to the producer, make 
it their responsibility, and merely promise to truncate the inputs if 
they're not the same length. Otherwise, what do I do once I've caught 
the exception?

The most common use for this I have seen in the discussion is:

"I have generated two inputs which I expect are equal, and I'd like to 
be notified if they aren't"

which to me is an assertion about program correctness. So this ought to 
be an assert that gets disabled under -O, not a raise that the caller 
might catch.

So this suggests *two* new functions:

- zip_equal for Brandt's parsing bug use-case, guaranteed to raise

- zip_assert_equal for the more common use case of checking 
  program correctness, and disabled under -O


> Is it’s in itertools, they have to think to look there.

And this is a problem, why? Should *everything* be a builtin?

Heaven forbid that somebody has to read the docs and learn about 
modules, let's have one giant global namespace with everything in it! 
Because that's good for the beginners! (Not.)


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

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

[Steven D'Aprano]

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 dict union operators? :-)

Aside from the Python-Ideas community being quite conservative about 
change at the best of times[1], this is a change with few obvious 
*concrete* use-cases that I have seen, a significant disagreement over 
the intent of the check (is it an assertion that should never be caught, 
or an exception that the caller may want to catch and recover from?), 
plus it has much opportunity for bikeshedding:

- zip_strict or zip_equal or zip_exact or zip_same?
- builtin or itertools?
- function or recipe in itertools?
- zip.method or function?
- just use more-itertools?
- deprecate zip and call it zip_shortest?
- use a True/False flag or a string mode or an enumeration?
- pass a callback function to zip?


Unlike dict union operators, there is no long history of requests for 
this functionality (that I have seen). It wasn't added to itertools when 
zip_longest was added, not even as a recipe. And even more-itertools, 
which adds everything including the kitchen sink to their library, only 
added it within the last few weeks (give or take).

So I don't think you should be surprised by the pushback on this.


> With that in mind, I've started drafting one summarizing the 
> discussion that took place here, and arguing for the addition of a 
> boolean flag to the `zip` constructor. Antoine Pitrou has agreed to 
> sponsor, and I've chatted with another core developer who shares my 
> view that such a flag wouldn't violate Python's existing design 
> philosophies.

Maybe you should chat with another core developer who *disagrees* with 
your view about such a flag?



[1] Whether it is *excessively* conservative probably depends on how you 
feel about the change being proposed :-)


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

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

[Andrew Barnert via Python-ideas]

> 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 served by finding the lowest hanging 
> fruit, and suggesting jsut a few.

I think you’re right. It _might_ be accepted if someone did the work, but it’s 
probably a lot easier to get separate small changes with solid use cases in one 
by one. As long as you’re not being sneaky and pretending like you don’t have a 
master plan, and each of the changes is convincing, I think they’d have a much 
better chance. And there ought to be good use cases for “these builtin parse 
functions should have a .string with the input that failed so you don’t have to 
regex it out of the message” or “I need to distinguish this one kind of 
ValueError from all the other kinds” or whatever; a lot easier to argue for 
those use cases than something abstract and general. 

And almost any way it turns out seems like a win. Even if they all get 
rejected, better to know you were on the wrong track early rather than after a 
hundred hours of work. Or if it turns out to be more work than you expected and 
you get sick of doing it, at least you’ve improved some of the most important 
cases. Or maybe you’d just keep doing it and people just keep saying “fine”. Or 
maybe someone says, “Hold on, another one of these? They’re all good on their 
own, but shouldn’t we have some master plan behind it all?” and then you can 
point back to the master plan you posted in this thread that nobody wanted to 
read at the time, and now they’ll want to read it and start bikeshedding. :)

(By “you” here I don’t mean you, Christopher; I mean Ram, or whoever else wants 
to do all this work.)

By the way:

> Python2 DID have a .message attribute -- I guess I should go look and find 
> documentation for the reasoning behind that, but it does seem like a step 
> backwards to me.

In 2.6 and 2.7, it’s undocumented, and should always be either the same thing 
__str__ returns or the empty string. So, not particularly useful.

I believe it exists as a consequence of the first time someone suggested “let’s 
clean up all the exceptions” but then that cleanup didn’t get started.

It was added in 2.5, along with a planned deprecation of args, and a new rule 
for __str__ (return self.message instead of formatting self.args), and a new 
idiom for how newly-written exception classes should super: don’t pass *args, 
pass a single formatted string; anything worth keeping around for users is 
worth storing in a nicely named attribute the way SyntaxError and IOError 
always have. And Py3000 was going to change all the existing exceptions to use 
that new idiom. But that never happened, and 2.6 and 3.0 basically went back to 
2.4: there’s no mention of message at all, args isn’t going to be deprecated, 
the rule for __str__ is the old one, etc.

There are more custom attributes on more exceptions than there used to be, but 
they seem to mostly have grown on a case by case basis (and mostly on brand new 
exceptions) rather than in one fell swoop. Which implies that you were right 
about the best way to get anything done.

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

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

[Steven D'Aprano]

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 
> > find out more about exactly what caused it, and often you are left with 
> > parsing the message if you really want to know.
> 
> I don’t think there are many cases where a standardized .errno would help—and 
> I think most such cases would be better served by separate exceptions. With 
> OSError, errno was a problem to be fixed, not an ideal solution to emulate 
> everywhere.
> 
> You do often need to be able to get more information, and that is a problem, 
> but I think it usually needs to be specific to each exception, not something 
> generic.
> 
> Does code often need to distinguish between an unpacking error and an int 
> parsing error? If so, you should be able to handle UnpackingError and 
> IntParsingError, not handle ValueError and check an .errno against some set 
> of dozens of new builtin int constants. If not, then we shouldn’t change 
> anything at all.
> 
> As for parsing the error message, that usually comes up because 
> there’s auxiliary information that you need but that isn’t accessible. 
> 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 = open(filename)
except IOError as err:
 print(filename)

I'm trying to think of a case where you might be making a call to open 
but you don't know the filename.

I thought it might be if you pass a file descriptor, but in that case 
the filename attribute seems to be set to None.


> It seems like every year or two, someone suggests that we should go 
> through the stdlib and fix all the exceptions to be reasonably 
> distinguishable and to make their relevant information more 
> accessible, and I don’t think anyone ever has a problem with that, 

I do!

Christopher's proposal of a central registry of error numbers and 
standardised error messages just adds a lot more work to every core 
developer for negligible or zero actual real world benefit.

When I want to raise something in the stdlib, I just raise:

# let's say I add a kurtosis function
raise StatisticsError('not enough data points for kurtosis')

Under Christopher's proposal, I have to:

* look up the central registry;
* find the next ID unused number;
* register it to my library and error message;
* use the relevent errno and the same error message in my code:

# something like this?
raise StatisticsError('not enough data points for kurtosis', errno=926361)

and while I'm doing that, one of the faster and more productive core 
devs have come along and used that errno before I could merge my patch, 
so now I have to change the errno.

And then if I decide to improve the error message, what now? Do I have 
to register a new errno? What if the error message is variable?

Expected at least 4 data points, but got 2.

And the benefit of this is ... what? I'd like to see the real-world 
concrete benefit that couldn't be more easily accomplished by using a 
separate try...except around *only* the call to kurtosis:

try:
k = kurtosis(data)
except StatisticsError:
# This can only mean one thing: not enough data.
k = None


I'm sorry to anyone who likes to use a single try around many 
computations:

try:
xm = mean(ydata)
ym = mean(ydata)
xsd = stdev(xdata)
ysd = stdev(ydata)
except StatisticsError as err:
# How do I distinguish which call failed?

but supporting that is not something I'm prepared to do until either I 
need that functionality myself or somebody provides a really compelling 
use-case, not just "it would be cool if..." :-)



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

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

[Steven D'Aprano]

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 saying it'd be an antipattern to shadow zip with a
> version that is always strict. If you want both strict and non-strict in
> the same file, you're in trouble.

Then don't do it!

If you want both, then it is trivially easy to use both:


from itertools import zip_equal
zip(zip_equal(a, b), c)


> But replacing zip with a zip that has an
> optional strict flag should be harmless.

[Aside: I still disagree *strongly* with the use of a "strict" flag 
here.]

Indeed, that's a perfectly safe and fine use of shadowing. Python is 
designed to allow shadowing. Calling it an "anti-pattern" is just wrong. 
Yes, shadowing can be abused, or done by accident, but intentional 
shadowing is a useful software design pattern. For instance:

if not settings['print_diagnostics']:
print = lambda *args, **kw: None

def main():
print('diagnostics go here')
...


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

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

[Steven D'Aprano]

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 can finally push for the no_op function, for starters.

"Let us add this unnecessary over-generalisation so that we can add 
another unnecessary builtin" is not a use-case. It is language bloat.


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

[Python-ideas] Re: is a

[Steven D'Aprano]

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 explicit type checking (with ABCs 
> or whatever), I really detest the look of the isinstance() function.


Is it just the `isinstance` function you detest, or all functions?

If it's just `isinstance`, then you can alias it:

is_a = isinstance
if is_a(thing, Fruit): # yuck this is worse

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.


[...]
> What I really want to write is:
> 
> if thing is a Fruit and thing is not an Apple:
> 
> and after thinking about it on and off for a while I wonder if it 
> might indeed be possible to teach the parser to handle that in a way 
> that eliminates almost all possible ambiguity with the regular "is", 
> including perhaps 100% of all existing standard library code and 
> almost all user code?

Whether it is possible is only half the question. Whether it is 
desirable is the other half.

My first language was Apple's Hypertalk back in the 1990s, which used a 
very English-like syntax where things like "is a" would have been right 
at home. For example:

if there is a file "myfile.pct" then ...

Functions could be written in either traditional parenthesized format, 
or English-like prefix operator syntax:

root = sqrt(value)
put the sqrt of value into root

It's been two decades since I've last written a line of Hypertalk code 
and I still miss it :-) so I'm definitely sympathetic to your request. 
But I fear that few others will be.

If we wanted this new operator, I think it should combine 
isinstance and issubclass:

obj is a T

should be equivalent to:

issubclass(obj, T) if isinstance(obj, type) else isinstance(obj, T)

and T is a type or tuple of types.

The rules in English for when to use "a" versus "an" depend 
on the *sound* of the following word, not the initial letter. Blindly 
applying the rule "an before vowels otherwise a" is wrong:

an uncle  # correct
an unicorn  # wrong

so I propose that the interpreter allow either, and we leave it to the 
programmer and/or linters to enforce good English grammar:

obj is an int
obj is an float  # accepted by interpreter
obj is a int  # also accepted by interpreter

In other words, the "is-a" operators would become:

is a[n]
is not a[n]


The above is the easy part. The hard part is justifying why this should 
become an operator.


> Maybe this has been considered at some point in the past? The "is 
> [not] a|an" proposal would at least be a strong contender for "hardest 
> thing to search for on the internet" lol.

Indeed :-)

But for what it's worth, I don't remember coming across this myself.


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

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

[Christopher Barker]

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 message if you really want to know.
>
> I don’t think there are many cases where a standardized .errno would
> help—and I think most such cases would be better served by separate
> exceptions. With OSError, errno was a problem to be fixed, not an ideal
> solution to emulate everywhere.
>

I will note that wrote is response to someone else suggesting that that was
the solution to the OP's problem. If the "policy" is that some information
should be tacked on to a fairly generic exception, rather than crating a
bunch of subclasses if that exception, then I'm suggesting that there
should be a standardized way to do that.


> You do often need to be able to get more information, and that is a
> problem, but I think it usually needs to be specific to each exception, not
> something generic.
>

but does that mean there can't be a more standardized way to "add more
information" maybe not -- I can't say I've thougth deeply about it, but we
could go ONE step better: as far as I can tell, the only thing at all a
standard is the exceptions all have a .args attribute wich is a tuple of
??? IN practic,e the zeroth element of that tuple is the "Error Message",
but it could be any old thing.

Python2 DID have a .message attribute -- I guess I should go look and find
documentation for the reasoning behind that, but it does seem like a step
backwards to me.

As for parsing the error message, that usually comes up because there’s
> auxiliary information that you need but that isn’t accessible. For example,
> in 2.x, to get the filename that failed to open, you had to regex .args[0],
> and that sucked. But the fix was to add a .filename to all of the relevant
> exceptions, and now it’s great. If you need to be able to get the failing
> string for int(s) raising a ValueError today, you have to regex .args[0],
> and that sucks. Do people actually need to do that? If so, there should be
> a .string or something that carries that information; an .errno won’t help.
>

but it does seem like this could be a bit more standardized. in those two
cases, you have the data passed in that caused the failure -- could they
bwoth use .input_value or something? Maybe it's better to have a
use-specific name, maybe not.

I'm not going to be able to motivate this well, so I should probably just
stop until/unless I get some more time to dig back in my archives and find
examples when this was an issue, but I know that every time I've wanted a
bit more info from an Exception, I realized that .args is the ONLY standard
place for any info -- and thought "really?"

It seems like every year or two, someone suggests that we should go through
> the stdlib and fix all the exceptions to be reasonably distinguishable and
> to make their relevant information more accessible, and I don’t think
> anyone ever has a problem with that, it’s just that nobody’s ever willing
> to volunteer to survey every place a builtin or stdlib raises, list them
> all, and work out exactly what should be changed and where.
>

Probably so, but it seems that no one's going to do that work unless they
think it will be accepted -- kin dof like how Ram proposed this in vague
and hyperbolic terms, rather than providing a big list of all the places he
thought needed improvement.

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 served by finding the lowest
hanging fruit, and suggesting jsut a few.

-CHB






-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OML342YY3CJPVE7YLHDXIQUMAES6SEX4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Alex Hall]

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 require; a flag can’t be used in
> libraries until they’re able to require Python 3.9 (unless they want to use
> a backport that monkey patches or shadows the builtin, but I doubt you’d
> suggest that, since you called it an antipattern elsewhere in the PEP).


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 saying it'd be an antipattern to shadow zip with a
version that is always strict. If you want both strict and non-strict in
the same file, you're in trouble. But replacing zip with a zip that has an
optional strict flag should be harmless. So a backport with a flag seems
perfectly fine, whether it's used per module or it patches builtins for all
modules.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YBJITTC6ACDWH5CCJRSJGBVDYZAVP2G4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[André Roberge]

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 use of the word
> ‘strict’”, but people did challenge it, and even more people just called it
> “equal” instead of “strict” when arguing for it or +’ing it (which implies
> a preference even if there’s no argument there), and the only known prior
> art on this is more-itertools, which has a zip_equal function, not a
> zip_strict function.
>

I completely agree with this. I didn't bother replying to the original
thread as other people had already mentioned my favourite idea which was to
use something like

mode = "equal" | "shortest" | "longest"

with "shortest" as the default (avoiding causing any breakage with the
existing function).

André Roberge

>
> I think it misrepresents the arguments for a separate function and
> undersells the advantages—it basically just addresses the objections that
> are easiest to reject. I don’t want to rehash all of my arguments and those
> of a dozen other people, since they’re already in the thread, but let me
> just give one: 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 require; a
> flag can’t be used in libraries until they’re able to require Python 3.9
> (unless they want to use a backport that monkey patches or shadows the
> builtin, but I doubt you’d suggest that, since you called it an antipattern
> elsewhere in the PEP).
>
> It implies that infinite iterators are the only legitimate place where
> you’d ever want the existing shortest behavior.
>
> Also, I don’t think anyone on the thread suggested the alternative of
> changing the behavior of zip _today_. Serhiy only suggested that we should
> leave the door open to doing so in the future, by having an enum-valued
> flag instead of a bool, or zip_shortest alongside zip_equal and
> zip_longest, or whatever. That allows people to explicitly say they want
> shortest when they want it, now—which might be beneficial even on its own
> terms. And if people end up usually using strict, and usually being
> explicit when they want shortest, then at that point it might be worth
> changing the default (or just not having one). So the argument against the
> alternative doesn’t really cover the actual thing suggested, but a
> different thing nobody wanted.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MHP3V2GFFBIDXVCY4T62TL4YRLGYGTGW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UJVFHWEVJ3MOJRSZJLFLU73L3WWFI2YX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Caleb Donovick]

> 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 discussed in the main
thread zip strict could also be handled by zip_longest
with a sentinel.  However, zip strict is an incredibly common usecase.
There is no evidence that recovering the consumed
elements is.

> also: I don't like booleans. they're not extensible, unless you consider
> None. you either get it right the first time, add a new boolean argument
> later, or use enum.Flag from the beginning. this callback-based API
> sidesteps all these issues

While in theory I very much support the use of enums for flags, they have
serious performance problems
which makes their use inadvisable in the standard lib let alone a builtin.

https://bugs.python.org/issue39102
https://bugs.python.org/issue38659


On Fri, May 1, 2020 at 1:20 PM Soni L.  wrote:

>
>
> 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 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 handler for mismatched
> lengths?
> > > > > I made a post about it on the other thread and it's not addressed
> in the
> > > > > PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka
> > > > > zip(strict=True)) and zip_longest, it's not stringly-typed, and
> it's
> > > > > user-extensible. Something along the lines of zip(foo, bar, baz,
> > > > > and_then=lambda consumed_items, iters: ...).
> > > > >
> > > >
> > > > YAGNI.
> > >
> > > examples:
> > >
> > > # iterates in chunks, e.g. a very large file that wouldn't fit all in
> RAM
> > > zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))
> >
> > I'm honestly not sure how useful this really is in practice. Iterating
> > over a file is already going to be chunked. What do you gain by
> > wrapping it up in an opaque zip call?
> >
> > > # strict zip
> > > sentinel = object()
> > > def zip_eq(res, iters):
> > >if res or any(next(x, sentinel) is not sentinel for x in iters):
> > >  raise ValueError
> > > zip(a, b, c, and_then=zip_eq)
> > > # this would ideally be zip.strict e.g. zip(a, b, c,
> > > and_then=zip.strict), but w/e.
> >
> > So a messier and noisier spelling of what's already in this
> proposal...
> >
> > > # normal (shortest) zip but using an explicit function
> > > def no_op(*args, **kwargs):
> > >pass
> > > zip(a, b, c, and_then=no_op)
> > >
> >
> > ... and a messier and noisier spelling of what we already have.
> >
> > 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 can finally push for the no_op function, for starters. but the main
> benefit is, again, being able to get the iterated values which were
> silently swallowed by zip when the iteration stopped.
>
> also: I don't like booleans. they're not extensible, unless you consider
> None. you either get it right the first time, add a new boolean argument
> later, or use enum.Flag from the beginning. this callback-based API
> sidesteps all these issues.
>
> and just in case maybe zip(strict=True) should be zip(errors=True) and
> we can later change it to zip(errors="replace", value=Foo) to get
> zip_longest >.< (no really bools = bad please don't use them in new APIs)
> >
> > ChrisA
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UAQGBSUUFSQJRE56VGTHVXAHCJHUAYTM/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/F43SYFQAK7O7TVUGLHMKIKJDESES4W25/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org

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

[Andrew Barnert via Python-ideas]

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 of 
“strict” when arguing for it or +’ing it (which implies a preference even if 
there’s no argument there), and the only known prior art on this is 
more-itertools, which has a zip_equal function, not a zip_strict function.

I think it misrepresents the arguments for a separate function and undersells 
the advantages—it basically just addresses the objections that are easiest to 
reject. I don’t want to rehash all of my arguments and those of a dozen other 
people, since they’re already in the thread, but let me just give one: 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 require; a flag can’t be used in libraries until 
they’re able to require Python 3.9 (unless they want to use a backport that 
monkey patches or shadows the builtin, but I doubt you’d suggest that, since 
you called it an antipattern elsewhere in the PEP).

It implies that infinite iterators are the only legitimate place where you’d 
ever want the existing shortest behavior.

Also, I don’t think anyone on the thread suggested the alternative of changing 
the behavior of zip _today_. Serhiy only suggested that we should leave the 
door open to doing so in the future, by having an enum-valued flag instead of a 
bool, or zip_shortest alongside zip_equal and zip_longest, or whatever. That 
allows people to explicitly say they want shortest when they want it, now—which 
might be beneficial even on its own terms. And if people end up usually using 
strict, and usually being explicit when they want shortest, then at that point 
it might be worth changing the default (or just not having one). So the 
argument against the alternative doesn’t really cover the actual thing 
suggested, but a different thing nobody wanted.

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

[Python-ideas] Re: is a

[Andrew Barnert via Python-ideas]

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 it’s intentional that it’s a little yucky. It makes you think “could I 
be using duck typing or overridden methods here instead of type switching?” 
Sure, sometimes the answer is, “No, I can’t,” which is why ABCs were added. But 
if you’re using them so often that you get annoyed by the ugliness, then maybe 
you’re using an antipattern—or, if not, there’s a good chance you’re doing 
something that’s perfectly valid but unusual for Python, so the language just 
isn’t going to cater to you.

Maybe Python leans a little too far toward discouraging type checks, because 
there was so much resistance to the very idea of ABCs until people got used to 
them. But if so, I suspect you’ll need a solid example of realistic code that 
should look better, and can’t be reasonably redesigned, to convince people, not 
just showing that isinstance is about as ugly as it was designed to be.

> What I really want to write is:
> 
> if thing is a Fruit and thing is not an Apple:

> and after thinking about it on and off for a while I wonder if it might 
> indeed be possible to teach the parser to handle that in a way that 
> eliminates almost all possible ambiguity with the regular "is", including 
> perhaps 100% of all existing standard library code and almost all user code?

Possible? Yes, at least with the new parser coming from PEP 617. But that 
doesn’t mean it’s a good idea.

You certainly can’t make a and an into keywords, because lots of people have 
variables named a.

You can’t even make them into “conditional keywords”, that only have a special 
meaning after “is” and “is not”—besides all the usual negatives of conditional 
keywords, it won’t work, because “b is a” is already perfectly reasonable code 
today.

So you’d need to add some kind of backtracking: they’re conditional keywords 
only if they follow “is” or “is not” and are followed by a valid expression. 
Which is more complicated (and less efficient) to parse. Some third-party 
parser tools might even have to be completely rewritten, or at least to add 
special case hacks for this.

And, more importantly, the more context it takes to parse things (or the more 
special cases you have to learn and memorize), the harder the language’s syntax 
is to internalize. The fact that Python is (almost) an LL(1) language makes it 
pretty easy to get most of syntax for the subset that you use firmly into your 
head. Every special case makes that less true, which means more cases where you 
get confused by a SyntaxError in your code or about what someone else’s code 
means, and means it’s harder to manually work through the parse when you do get 
stumped like that and you resort to shotgun-debugging antics instead.

For a practical example, look at some languages that are actually designed to 
be executable English rather than executable pseudocode, like AppleScript or 
Inform. The fact that “bring every window of the first app to the foreground” 
reads like a normal English sentence is pretty cool, but the fact that “bring 
the first window of every app to the foreground” gives you an error message 
about not knowing what the every is, and the only way to rewrite it is “tell 
every app to bring the first window of it to the foreground”, severely dampens 
the coolness factor.

> Maybe this has been considered at some point in the past? The "is [not] a|an" 
> proposal would at least be a strong contender for "hardest thing to search 
> for on the internet" lol.

That will also make it hard to search for when you see some code you don’t 
understand and need to search for help, won’t it? A search for “isinstance” 
(even without including Python) brings me the docs page, some tutorials and 
blogs, and some StackOverflow questions; what’s a search for “is a” or even 
“Python is a” going to get me?

Maybe you could get more mileage out of going halfway there, with an operator 
named isa. Other languages use that spelling for related things (in Perl it’s 
exactly the operator you want; in ObjC it’s a property on the instance but it’s 
still about types), and people often use “isa” or “is-a” as a technical term in 
comp sci.

if thing isa Fruit and thing not isa Apple:

That’s still pretty readable, and easy to parse.

But it still breaks backward compatibility, because people do have code that 
uses “isa” as a normal identifier. (For one thing, it’s how you access the isa 
attribute of an ObjC object in PyObjC.)

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 

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

[Soni L.]

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 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 handler for mismatched lengths?
> > > I made a post about it on the other thread and it's not addressed in the
> > > PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka
> > > zip(strict=True)) and zip_longest, it's not stringly-typed, and it's
> > > user-extensible. Something along the lines of zip(foo, bar, baz,
> > > and_then=lambda consumed_items, iters: ...).
> > >
> >
> > YAGNI.
>
> examples:
>
> # iterates in chunks, e.g. a very large file that wouldn't fit all in RAM
> zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))

I'm honestly not sure how useful this really is in practice. Iterating
over a file is already going to be chunked. What do you gain by
wrapping it up in an opaque zip call?

> # strict zip
> sentinel = object()
> def zip_eq(res, iters):
>if res or any(next(x, sentinel) is not sentinel for x in iters):
>  raise ValueError
> zip(a, b, c, and_then=zip_eq)
> # this would ideally be zip.strict e.g. zip(a, b, c,
> and_then=zip.strict), but w/e.

So a messier and noisier spelling of what's already in this proposal...

> # normal (shortest) zip but using an explicit function
> def no_op(*args, **kwargs):
>pass
> zip(a, b, c, and_then=no_op)
>

... and a messier and noisier spelling of what we already have.

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 can finally push for the no_op function, for starters. but the main 
benefit is, again, being able to get the iterated values which were 
silently swallowed by zip when the iteration stopped.


also: I don't like booleans. they're not extensible, unless you consider 
None. you either get it right the first time, add a new boolean argument 
later, or use enum.Flag from the beginning. this callback-based API 
sidesteps all these issues.


and just in case maybe zip(strict=True) should be zip(errors=True) and 
we can later change it to zip(errors="replace", value=Foo) to get 
zip_longest >.< (no really bools = bad please don't use them in new APIs)


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

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

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

[Ethan Furman]

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 catch what you can recover from.


But in practice, it is surprisingly more practical than it sounds in
theory.


Since not every problem can be recovered from and therefore shouldn't be caught.

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

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

[Chris Angelico]

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:
> > > >
> > > > 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 handler for mismatched lengths?
> > > I made a post about it on the other thread and it's not addressed in the
> > > PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka
> > > zip(strict=True)) and zip_longest, it's not stringly-typed, and it's
> > > user-extensible. Something along the lines of zip(foo, bar, baz,
> > > and_then=lambda consumed_items, iters: ...).
> > >
> >
> > YAGNI.
>
> examples:
>
> # iterates in chunks, e.g. a very large file that wouldn't fit all in RAM
> zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))

I'm honestly not sure how useful this really is in practice. Iterating
over a file is already going to be chunked. What do you gain by
wrapping it up in an opaque zip call?

> # strict zip
> sentinel = object()
> def zip_eq(res, iters):
>if res or any(next(x, sentinel) is not sentinel for x in iters):
>  raise ValueError
> zip(a, b, c, and_then=zip_eq)
> # this would ideally be zip.strict e.g. zip(a, b, c,
> and_then=zip.strict), but w/e.

So a messier and noisier spelling of what's already in this proposal...

> # normal (shortest) zip but using an explicit function
> def no_op(*args, **kwargs):
>pass
> zip(a, b, c, and_then=no_op)
>

... and a messier and noisier spelling of what we already have.

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.

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

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

[Andrew Barnert via Python-ideas]

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 message if you really want to know.

I don’t think there are many cases where a standardized .errno would help—and I 
think most such cases would be better served by separate exceptions. With 
OSError, errno was a problem to be fixed, not an ideal solution to emulate 
everywhere.

You do often need to be able to get more information, and that is a problem, 
but I think it usually needs to be specific to each exception, not something 
generic.

Does code often need to distinguish between an unpacking error and an int 
parsing error? If so, you should be able to handle UnpackingError and 
IntParsingError, not handle ValueError and check an .errno against some set of 
dozens of new builtin int constants. If not, then we shouldn’t change anything 
at all.

As for parsing the error message, that usually comes up because there’s 
auxiliary information that you need but that isn’t accessible. For example, in 
2.x, to get the filename that failed to open, you had to regex .args[0], and 
that sucked. But the fix was to add a .filename to all of the relevant 
exceptions, and now it’s great. If you need to be able to get the failing 
string for int(s) raising a ValueError today, you have to regex .args[0], and 
that sucks. Do people actually need to do that? If so, there should be a 
.string or something that carries that information; an .errno won’t help.

It seems like every year or two, someone suggests that we should go through the 
stdlib and fix all the exceptions to be reasonably distinguishable and to make 
their relevant information more accessible, and I don’t think anyone ever has a 
problem with that, it’s just that nobody’s ever willing to volunteer to survey 
every place a builtin or stdlib raises, list them all, and work out exactly 
what should be changed and where.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CZP5RDQGWAXS4QQ3BHVNRT4VBXVP2Z3Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Soni L.]

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 to hear any *new* feedback 
that hasn't yet been addressed in the PEP!
>
> What about using an optional kwarg for a handler for mismatched lengths?
> I made a post about it on the other thread and it's not addressed in the
> PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka
> zip(strict=True)) and zip_longest, it's not stringly-typed, and it's
> user-extensible. Something along the lines of zip(foo, bar, baz,
> and_then=lambda consumed_items, iters: ...).
>

YAGNI.


examples:

# iterates in chunks, e.g. a very large file that wouldn't fit all in RAM
zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))

# strict zip
sentinel = object()
def zip_eq(res, iters):
  if res or any(next(x, sentinel) is not sentinel for x in iters):
    raise ValueError
zip(a, b, c, and_then=zip_eq)
# this would ideally be zip.strict e.g. zip(a, b, c, 
and_then=zip.strict), but w/e.


# normal (shortest) zip but using an explicit function
def no_op(*args, **kwargs):
  pass
zip(a, b, c, and_then=no_op)



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

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

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

[Rhodri James]

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 your Rationale 
section misses the point.  The rest of the document appears to divide 
uses of zip into those playing with infinite iterators, for which the 
current behaviour of zip() is just fine and "strict=True" would be an 
error, those where the program logic expects the finite inputs to be the 
same length for which "strict=True" is protection against meddling :-), 
and a relatively small number of cases that don't care for which 
"strict=True" may not even be a useful debugging tool.  In other words, 
from context the programmer should always know whether he always wants 
"strict=True" or "strict=False".  That functionality switch is the 
smell, and I don't think you convincingly deal with it.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MHY5OAY2RXSDYO5RX36LF6F67GRUAK57/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 been addressed in the PEP!
>
> What about using an optional kwarg for a handler for mismatched lengths?
> I made a post about it on the other thread and it's not addressed in the
> PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka
> zip(strict=True)) and zip_longest, it's not stringly-typed, and it's
> user-extensible. Something along the lines of zip(foo, bar, baz,
> and_then=lambda consumed_items, iters: ...).
>

YAGNI.

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

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

[Soni L.]

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 handler for mismatched lengths? 
I made a post about it on the other thread and it's not addressed in the 
PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka 
zip(strict=True)) and zip_longest, it's not stringly-typed, and it's 
user-extensible. Something along the lines of zip(foo, bar, baz, 
and_then=lambda consumed_items, iters: ...).




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

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

[Python-ideas] Re: is a

[Steele Farnsworth]

`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
that possibility is worth the effort.

On Fri, May 1, 2020 at 2:13 PM Soni L.  wrote:

>
>
> 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 appreciate wanting to make simple operations easy to read, though I
> think this relies too much on understanding English and wouldn't be
> intuitive for people who aren't English speaking. I am native English
> speaking so I wouldn't know for sure, but I think accepting that "or" is
> the same as "||" is an easier jump to make than "x is a y" being a
> construct for indicating that x belongs to the y class.
>
> If you need this English-style syntax, I believe `type(x) is y` is
> guaranteed to be True if x is exactly of the y type and not one of its
> super classes.
>
> On Fri, May 1, 2020, 1:27 PM gbs--- via Python-ideas <
> python-ideas@python.org> 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.
>>
>> What I really want to write is:
>>
>> if thing is a Fruit and thing is not an Apple:
>>
>> and after thinking about it on and off for a while I wonder if it might
>> indeed be possible to teach the parser to handle that in a way that
>> eliminates almost all possible ambiguity with the regular "is", including
>> perhaps 100% of all existing standard library code and almost all user code?
>>
>> Maybe this has been considered at some point in the past? The "is [not]
>> a|an" proposal would at least be a strong contender for "hardest thing to
>> search for on the internet" lol.
>>
>> Thanks!
>>
>> Gavin
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/YKLNQXONLLZ7OXEMUHXF5HD4PCX4SNVT/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to 
> python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/PQSJ6PSRS3JZZUV7CRRKRSGJAPVBYP6G/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/JFSNV7FAKLMTZWQDHJWPX3ZSMKVHA6V3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ULZUOHUT4XY7ZB2XF6IAD6J7CDOVG4TU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brandt Bucher]

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@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZBB5L2I45PNLTRW7CCV4FDJO5DB7M5UT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: is a

[Soni L.]

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 appreciate wanting to make simple operations easy to read, 
though I think this relies too much on understanding English and 
wouldn't be intuitive for people who aren't English speaking. I am 
native English speaking so I wouldn't know for sure, but I think 
accepting that "or" is the same as "||" is an easier jump to make than 
"x is a y" being a construct for indicating that x belongs to the y class.


If you need this English-style syntax, I believe `type(x) is y` is 
guaranteed to be True if x is exactly of the y type and not one of its 
super classes.


On Fri, May 1, 2020, 1:27 PM gbs--- via Python-ideas 
mailto:python-ideas@python.org>> 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.

What I really want to write is:

if thing is a Fruit and thing is not an Apple:

and after thinking about it on and off for a while I wonder if it
might indeed be possible to teach the parser to handle that in a
way that eliminates almost all possible ambiguity with the regular
"is", including perhaps 100% of all existing standard library code
and almost all user code?

Maybe this has been considered at some point in the past? The "is
[not] a|an" proposal would at least be a strong contender for
"hardest thing to search for on the internet" lol.

Thanks!

Gavin
___
Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/YKLNQXONLLZ7OXEMUHXF5HD4PCX4SNVT/
Code of Conduct: http://python.org/psf/codeofconduct/


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


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

[Python-ideas] Re: is a

[Steele Farnsworth]

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 English and wouldn't be
intuitive for people who aren't English speaking. I am native English
speaking so I wouldn't know for sure, but I think accepting that "or" is
the same as "||" is an easier jump to make than "x is a y" being a
construct for indicating that x belongs to the y class.

If you need this English-style syntax, I believe `type(x) is y` is
guaranteed to be True if x is exactly of the y type and not one of its
super classes.

On Fri, May 1, 2020, 1:27 PM gbs--- via Python-ideas <
python-ideas@python.org> 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.
>
> What I really want to write is:
>
> if thing is a Fruit and thing is not an Apple:
>
> and after thinking about it on and off for a while I wonder if it might
> indeed be possible to teach the parser to handle that in a way that
> eliminates almost all possible ambiguity with the regular "is", including
> perhaps 100% of all existing standard library code and almost all user code?
>
> Maybe this has been considered at some point in the past? The "is [not]
> a|an" proposal would at least be a strong contender for "hardest thing to
> search for on the internet" lol.
>
> Thanks!
>
> Gavin
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YKLNQXONLLZ7OXEMUHXF5HD4PCX4SNVT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PQSJ6PSRS3JZZUV7CRRKRSGJAPVBYP6G/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Andrew Barnert via Python-ideas]

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 list are very invested in the itertools module and iteration in 
> general. But many folks write a LOT of code without every touching 
> iterttools. Honestly, a lot of it is pretty esoteric (zip_longests is not) -- 
> I need to read the docs and think carefully before I know what they even do. 

So what? Most of the os module is pretty esoteric, but that doesn’t stop you—or 
even a novice who just asked “how do I get my files like dir”—from using 
os.listdir. For that matter, zip is in the same place as stuff like setattr and 
memoryview, which are a lot harder to grok than chain.

That novice will never guess to look in os. And if I told them “go look in os”, 
that would be useless and cruel. But I don’t, I tell them “that’s called 
os.listdir”, and they don’t have to learn about effective/real/saved user ids 
or the 11 different spawn functions to “get my files like dir” like they asked.

> Example: Here's the docstring for itertools.chain:
> 
> chain(*iterables) --> chain object
> 
> Return a chain object whose .__next__() method returns elements from the
> first iterable until it is exhausted, then elements from the next
> iterable, until all of the iterables are exhausted.
> 
> I can tell you that I have no idea what that means -- maybe folks wth CS 
> training do, but that is NOT most people that use Python.

And here’s the docstring for zip:

> Return a zip object whose .__next__() method returns a tuple where
> the i-th element comes from the i-th iterable argument.  The .__next__()
> method continues until the shortest iterable in the argument sequence
> is exhausted and then it raises StopIteration

Most people have no idea what that means either.

In fact, chain is simpler to grok than zip (it just doesn’t come up as often, 
so it doesn’t need to be a builtin).

> Anyway, inscrutable docstrings are another issue, and one I keep hoping I'll 
> find the time to try to address one day,

Yes, many of Python’s docstrings tersely explain the details of how the 
function does what it does, rather than telling you why it’s useful or how to 
use it. And yes, that’s less than ideal.

But that isn’t an advantage to adding a flag to zip over adding a new function. 
Making zip more complicated certainly won’t magically fix its docstring, it’ll 
just make the docstring more complicated.

> but the point is :
> 
> "Folks will go look in itertools when zip() doesn't do what they want " just 
> does not apply to most people.

But nobody suggested that they will. That’s exactly why people keep saying it 
should be mentioned in the docstring and the docs page and maybe even the 
tutorial.

And you’re also right that it’s also not true that “folks will read the 
docstring for zip() when zip() doesn’t do what they want and figure it out from 
there”, but that’s equally a problem for both versions of the proposal.

In fact, most people, unless they learned it from a tutorial or class or book 
or blog post or from existing code before they needed it, are going to go to a 
coworker, StackOverflow, the TA for their class, a general web search, etc. to 
find out how to do what they want. There’s only so much Python can do about 
that—the docstring, docs page, and official tutorial (which isn’t the tutorial 
most people learn from) is about it.

We have to trust that if this really is something novices need, the people who 
teach classes and answer on StackOverflow and write tutorials and mentor 
interns and help out C# experts who only use Python twice a year and so on will 
teach it. There’s no way around that. But if those people can and do teach 
os.listdir and math.sin and so on, they can also teach zip_equal.

> Finally, yes, a pointer to itertools in the docstring would help a lot, but 
> yes, it's still a heavier lift than adding a flag, 'cause you have to then go 
> and import a new module, etc.

What’s the “etc.” here? What additional thing do they have to do besides import 
a new module?

People have to import a new module to get a list of their files. And lots of 
other things that are builtins in other languages. In JavaScript, I don’t have 
to import anything to decode JSON, to do basic math functions like sin or mean, 
to create a simple object (where I don’t have to worry about writing __init__ 
and __repr__ and __eq__ and so on), to make a basic web request, etc. In 
Python, I have to import a module to do any of those things (for the last one, 
I even have to install a third-party package first).

Namespaces are a honking great idea, but there is a cost to that idea, and that 
cost includes people having to learn import pretty early on.


___
Python-ideas mailing list -- 

[Python-ideas] is a

[gbs--- via Python-ideas]

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 after thinking about it on and off for a while I wonder if it might indeed 
be possible to teach the parser to handle that in a way that eliminates almost 
all possible ambiguity with the regular "is", including perhaps 100% of all 
existing standard library code and almost all user code?

Maybe this has been considered at some point in the past? The "is [not] a|an" 
proposal would at least be a strong contender for "hardest thing to search for 
on the internet" lol.

Thanks!

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

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

[Tom Forbes]

> 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 
infinitely better and more debuggable than a deadlock. So yes, this should be a 
`RLock` instead.

> Limitations: No instrumentation. No ability to reset or clear. Won't work 
> across multiple processes.

I get the feeling that you might be about to make the point that this is 
somewhat re-inventing the `lru_cache` wheel, and I honestly agree with you. 
Given that the `lru_cache()` overhead with no arguments is so small, would you 
accept a PR that defaults `maxsize` to `None` if the wrapped function accepts 
no arguments and a change to the documentation showing that you could use 
`lru_cache` as a replacement for `call_once`?

Or, we could add the ability to clear and add stats pretty easily. Ugly 
implementation:

```
def once(func):
   sentinel = object()
   cache = sentinel
   lock = Lock()
   hit_count = 0

   @functools.wraps(func)
   def _wrapper():
   nonlocal cache, lock, sentinel
   if cache is sentinel:
   with lock:
   if cache is sentinel:
   cache = func()
   else:
   hit_count += 1
   else:
   hit_count += 1

   return cache

   def clear():
   cache = sentinel
   
   def stats():
   return hit_count

   _wrapper.clear = clear
   _wrapper.stats = stats
   return _wrapper
```

> It would be nice to look at some compelling use cases.  Off hand, I can't 
> think of time when I would have used this decorator.  Also, I have a nagging 
> worry that holding a non-reentrant lock across an arbitrary user defined 
> function call is recipe for deadlocks.  That's why during code reviews we 
> typically check every single use of Lock() to see if it should have been an 
> RLock(), especially in big systems where GC, __del__, or weakref callbacks 
> can trigger running any code at just about any time.

There are two specific use cases that I’ve seen:

1. You want a module-level singleton that creates an object that depends on 
something that’s not present yet. In it’s simplest form that might involve 
circular dependencies:

```
@call_once()
def create_client():
# some_module imports the outer module
from some_module import something
something(…)
```

In the case of Django 
,
 the “something that’s not present yet” is the Django settings:

```
@functools.lru_cache()
def get_default_renderer():
renderer_class = import_string(settings.FORM_RENDERER)
return renderer_class()
```

We don’t want to needlessly re-create the default form renderer, and we cannot 
create this instance at the module level.

2. You ant to create a singleton instance that is lazily created, can be easily 
mocked. For example, a `redis` client:

```
@call_once()
def get_redis_connection():
return redis.Redis(host='localhost', port=6379, db=0)
``` 

You don’t want to create this at the module level as the class might well start 
creating connections to Redis when it’s instantiated. On top of that other 
modules can do `from redis import get_redis_connection`, rather than `from 
redis import redis_connection`, which is easier and more consistent to mock.

> On 29 Apr 2020, at 23:04, Raymond Hettinger  
> wrote:
> 
> 
> 
>> On Apr 29, 2020, at 11:15 AM, Tom Forbes  wrote:
>> 
>> What exactly would the issue be with this:
>> 
>> ```
>> import functools
>> from threading import Lock
>> 
>> def once(func):
>>   sentinel = object()
>>   cache = sentinel
>>   lock = Lock()
>> 
>>   @functools.wraps(func)
>>   def _wrapper():
>>   nonlocal cache, lock, sentinel
>>   if cache is sentinel:
>>   with lock:
>>   if cache is sentinel:
>>   cache = func()
>>   return cache
>> 
>>   return _wrapper
>> ```
> 
> This recipe is the best variant so far and gives us something concrete to 
> talk about :-)
> 
> Benefits: Guarantees the wrapped function is not called more than once.
> Restrictions:  Only works with zero argument functions.
> Risks: Any reentrancy or recursion will result in deadlock.
> Limitations: No instrumentation. No ability to reset or clear. Won't work 
> across multiple processes.
> 
> It would be nice to look at some compelling use cases.  Off hand, I can't 
> think of time when I would have used this decorator.  Also, I have a nagging 
> worry that holding a non-reentrant lock across an arbitrary user defined 
> function call is recipe for deadlocks.  That's why during code reviews we 
> typically check every single use of Lock() to see if it should have been an 
> RLock(), especially in big systems where GC, __del__, or weakref callbacks 
> can trigger running any 

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

[Tom Forbes]

> 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 feedback on this idea, I’m really not clear on 
your line of reasoning here. What specifically do you propose would be the 
issue with the *Python* implementation? Are you proposing that under some 
Python implementations `cache = func()` could be… the result of half a function 
call? I could buy an issue with some implementations meaning that `cache` still 
appears as `sentinel` in specific situations, but I feel that would constitute 
a pretty obvious bug in the implementation that would impact a _lot_ of other 
multithreaded code rather than a glaring issue with this snippet. Both the 
issues you’ve referenced valid, but also are rather specific to the languages 
that they affect. I don’t believe they apply to Python.

> But you won’t be paying the overhead only on the first call, you’ll be paying 
> it on all of the calls that before the first one completed. 

Sure, that was a typo. It should have read:

> Seems generally more correct, even in single threaded cases, to pay the 
> overhead only in the first call (or first few calls if there is contention) 
> if you want `call_once` semantics

I still think the point stands. With your two-separate-decorators approach 
you’re paying it on every call. As a general purpose `call_once()` 
implementation I think the snippet works well, but obviously if you have some 
very specific use-case where it’s not appropriate - well then you are probably 
able to write a very specific and suitable decorator.


> On 30 Apr 2020, at 03:09, Andrew Barnert  wrote:
> 
> On Apr 29, 2020, at 11:15, Tom Forbes  > wrote:
>> 
>>> Thread 2 wakes up with the lock, calls the function, fills the cache, and 
>>> releases the lock.
>> 
>> What exactly would the issue be with this:
>> 
>> ```
>> import functools
>> from threading import Lock
>> 
>> def once(func):
>>   sentinel = object()
>>   cache = sentinel
>>   lock = Lock()
>> 
>>   @functools.wraps(func)
>>   def _wrapper():
>>   nonlocal cache, lock, sentinel
>>   if cache is sentinel:
>>   with lock:
>>   if cache is sentinel:
>>   cache = func()
>>   return cache
>> 
>>   return _wrapper
>> ```
> 
> 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.
> 
> In both of those languages, and most others, there is no guarantee that the 
> write to cache in thread 1 happens between the two reads from cache in thread 
> 2. Which gives you the fun kind of bug that every few thousand runs you have 
> corrupted data an hour later, or it works fine on your computer but it 
> crashes for one of your users because they have two CPUs that don’t share L2 
> cache while you have all your cores on the same die, or it works fine until 
> you change some completely unrelated part of the code, etc.
> 
> Java solved this by adding volatile variables in Java 5 (existing code was 
> still broken, but just mark cache volatile and it’s fixed); C++11 added a 
> compiler-assisted call_once function (and added a memory model that allows 
> them to specify exactly what happens and when so that the desired behavior 
> was actually guaranteeable). Newer languages learned from their experience 
> and got it right the first time, rather than repeating the same mistake.
> 
> Is there anything about Python’s memory model guarantee that means it can’t 
> happen in Python? I don’t think there _is_ a memory model. In CPython, or any 
> GIL-based implementation, I _think_ it’s safe (the other thread can’t be 
> running at the same time on a different core, so there can’t be a cache 
> coherency ordering issue between the cores, right?), but what about on 
> Jython, or PyPy-STM, or a future GIL-less Python?
> 
> And in both of those languages, double-checked locking is still nowhere near 
> as efficient as using a local static.
> 
>> Seems generally more correct, even in single threaded cases, to pay the 
>> overhead only in the first call if you want `call_once` semantics. Which is 
>> why you would be using `call_once` in the first place?
> 
> But you won’t be paying the overhead only on the first call, you’ll be paying 
> it on all of the calls that before the first one completed. That’s the whole 
> point of the lock, after all—they have to wait until it’s ready—and they 
> can’t possibly do that without the lock overhead. And for the next few 
> afterward, because they’ll have gotten far enough to check even if they 
> haven’t gotten far enough to get the lock, and there’s no way they can know 
> they don’t need the lock. And for the next few after that, because unless the 
> 

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

[André Roberge]

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 information to the exception
>> objects as e.g. .errno or similar attribute.
>>
>
> 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 message if you really want to know.
>
> Honestly, I've never written production code that does that -- but I don't
> think that's because there's no need for it, but because, well, parsing an
> error message is pretty painful, and just seems "wrong".
>
> 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, 
>
>
+100

With the exception of the obscure "SyntaxError: Invalid syntax", this would
make it really easy to provide translations of error messages in other
languages (or in "beginner friendly English") as I'm slowly doing with
friendly-traceback.

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

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

[Christopher Barker]

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

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 message if you really want to know.

Honestly, I've never written production code that does that -- but I don't
think that's because there's no need for it, but because, well, parsing an
error message is pretty painful, and just seems "wrong".

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 have only a single error number, this would
be a standardized way to add extra info to any Exception.

And frankly I've always thought it odd that the way to get the message was
to grab the first element in .args -- it's a defacto standard, but wouldn't
it be better to make it a actual standard?

Not well thought out, but this may be a way to address Ram's issues, while
not massively cluttering up the Exception namespace.

NOTE: I'm not sure where I come down on this, but having to "memorize" a
bunch more exceptions does not concern me in the least. I pretty much
always write code or tests that trigger the Exception I'm going to catch to
make sure I've got the right one anyway. Sure, I'm pretty familiar with
ValueError and TypeError, but there are a lot more than I can keep in my
brain at one time anyway, and I need to spell it right, and all that.

The one complication I DO see to this approach is that we'd have a lot of
Exceptions that were subclasses of more general ones, and when you see it,
it would not be obvious what the hierarchy is, so folks would tend to use
the fine-grained exception over the more general one, even if that wasn't
appropriate.

-CHB



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VRFFIGLKVXWHK3SRCAYNPF3PCABKPSGN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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
> exception like MissingArgumentsError rather than ValueError or
TypeError.
> They're too ubiquitous. I don't want some other unexpected failure
> producing the same ValueError and triggering my except clause.

If you want to catch MissingArgumentsError, you're doing something
really weird.  I'm trying to think of a realistic example and failing.


This type of error is already caught and identified by Python as a 
TypeError in at least two different situations with the following 
(generic) error messages:


X takes Y positional arguments but Z was given

X missing 2 required positional arguments: Y and Z

The fact that two such messages exist is indicative that this type of 
error do occur in realistic code.


So, in theory, one could think of extracting these two subcases of 
TypeError into a new exception subclass; personnally, I think that the 
current error messages are sufficient and adding a new exception 
subclass for them would just make the exception handling code more 
complicated than necessary.


But the question is: why would you actually catch these different 
exception types, and what would you do when you caught them? There's 
actual code that checked for errno on an IOError, which is why it was 
easy to say that adding FileNotFoundError, etc. would be an improvement. 
Where's the code that catches (or wants to catch) MissingArgumentsError?


I do think that every exception subclass that anyone wants to add is 
going to go through a case-by-case scrutiny. We're not just going to say 
"let's add a lot more exceptions!".


Eric



André Roberge


> 2. When I get an error, especially from some shitty corporate
system that
> truncates the traceback, I want to get as many hints as possible
about what
> went wrong.

Then you should read the exception reason.  You're still going to
have
to think about what your program logic error is, and a separate
exception is going to be less use than an explanatory text string.

-- 
Rhodri James *-* Kynesim Ltd

___
Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
Code of Conduct: http://python.org/psf/codeofconduct/


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

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

[Christopher Barker]

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
function written will be in the itertools module.

All the tab completion, etc in the world does not help when the functions
are in different namespaces.

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 list are very invested in the itertools module and iteration
in general. But many folks write a LOT of code without every touching
iterttools. Honestly, a lot of it is pretty esoteric (zip_longests is not)
-- I need to read the docs and think carefully before I know what they even
do.

Example: Here's the docstring for itertools.chain:

chain(*iterables) --> chain object

Return a chain object whose .__next__() method returns elements from the
first iterable until it is exhausted, then elements from the next
iterable, until all of the iterables are exhausted.

I can tell you that I have no idea what that means -- maybe folks wth CS
training do, but that is NOT most people that use Python.

And here's the full docs:

Make an iterator that returns elements from the first iterable until it is
exhausted, then proceeds to the next iterable, until all of the iterables
are exhausted. Used for treating consecutive sequences as a single
sequence. Roughly equivalent to:

def chain(*iterables):
# chain('ABC', 'DEF') --> A B C D E F
for it in iterables:
for element in it:
yield element


OK, that's better, though only because there's a nice simple example there,
and ytou have to go looking for them.

Anyway, inscrutable docstrings are another issue, and one I keep hoping
I'll find the time to try to address one day, but the point is :

"Folks will go look in itertools when zip() doesn't do what they want "
just does not apply to most people.

Finally, yes, a pointer to itertools in the docstring would help a lot, but
yes, it's still a heavier lift than adding a flag, 'cause you have to then
go and import a new module, etc.

-CHB



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LISCLZXA5RE5WHMWVBPF2CDXN73WYREG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Dan Sommers]

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 MissingArgumentsError rather than ValueError or TypeError.
> > > They're too ubiquitous. I don't want some other unexpected failure
> > > producing the same ValueError and triggering my except clause.
> >
> > If you want to catch MissingArgumentsError, you're doing something
> > really weird.  I'm trying to think of a realistic example and failing.
> >
> 
> This type of error is already caught and identified by Python as a
> TypeError in at least two different situations with the following (generic)
> error messages:
> 
> X takes Y positional arguments but Z was given
> 
> X missing 2 required positional arguments: Y and Z
> 
> 
> The fact that two such messages exist is indicative that this type of
> error do occur in realistic code.

"Realistic code"?  Those are both effectively syntax (i.e., compile
time) errors, and should be caught way before any code hits the street.
I agree with Rhodri:  if you're catching these errors at runtime, then
you're doing something really weird.  (And I agree with others:  if
you're catching these errors in a REPL or in unit tests, then you're
going to have to think about how to fix the problem regardless of the
label of the exception.)

(Well, if I use my imagination:  someone else is in control of your
environment, and they pulled in a new version of some library that
doesn't care about backwards compatility, and suddenly the runtime
behavior of your otherwise tested and debugged code is now failing.  But
that hardly seems like a common scenario.)

(Or maybe you're trying to build a genetic code generator and/or
debugger, and it's easier on your software to "guide" the evolution if
more information is encoded in the type of the exception rather than in
a human readable message.  But that also seems rather unlikely.)

Dan

-- 
“Atoms are not things.” – Werner Heisenberg
Dan Sommers, http://www.tombstonezero.net/dan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3AVTHZGUXVIVSDTNUV7TZ2WVU5CHRQ5Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[M.-A. Lemburg]

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 those 100 exception types.
>>
>> That said, enhancing the error reasons texts is certainly something
>> that would help everyone.
>>
>> 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 attribute.
> 
> There is prior art, though, specifically for errno:
> 
> $ python2 -c 'open("not-there")'
> Traceback (most recent call last):
>   File "", line 1, in 
> IOError: [Errno 2] No such file or directory: 'not-there'
> $ python3 -c 'open("not-there")'
> Traceback (most recent call last):
>   File "", line 1, in 
> FileNotFoundError: [Errno 2] No such file or directory: 'not-there'

Yes, and the reason for having those is that you will want to
often catch those exceptions in applications in a platform independent
way. That doesn't apply to all OS errors, though.

As with all great new features, a case has to be made why an
addition is necessary, what the benefits and drawbacks are and
why we should force millions of Python programmers to learn about
the addition.

Note that we're talking about the Python core, not an application
or Python package from PyPI. Those can, of course, define their own
exceptions and hierarchies.

I assume Ram was testing waters here... just to get an idea of what
it takes for such a change to go in, please see the PEP for the
OS/IO exception hierarchy changes:

https://www.python.org/dev/peps/pep-3151/

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 01 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OYLCV4XDIMHRBCUQNCHCM3Z5YWJZTJCI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Soni L.]

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 maintain backward 
compatibility.


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 where I should expect ValueError 
and where I should expect TypeError.


It would be nice if the operation above raised UnpackingOverflowError, 
which will be a subclass of UnpackingError, along with 
UnpackingUnderflowError. UnpackingError can be a subclass of 
ValueError, for backward compatibility.


oh yes please let me distinguish the exception from the unpacking and 
the exception from the iterator


def foo():
  yield from ()
  raise ValueError

it = foo()
try:
  x, y = it
except ValueError:
  print("Is this a problem with the unpacking or a problem with the 
generator?")

  raise

also please have unpacking wrap any UnpackingError from the generator 
into a RuntimeError.




Similarly, if I did this:

    >>> def f(x, y): return x + y
    >>> f(1)

I would get a TypeError. Would be a lot cooler if I got 
MissingArgumentsError, which would be a subclass of SignatureError, 
which would be a subclass of TypeError.


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 same ValueError and triggering my except clause.


2. When I get an error, especially from some shitty corporate system 
that truncates the traceback, I want to get as many hints as possible 
about what went wrong.


It's true that today, most Python exceptions have good text in their 
message, like "TypeError: f() missing 1 required positional argument: 
'y'". But that isn't guaranteed everywhere, and specific exception 
types could help.



What do you think?


Ram.

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


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

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

[André Roberge]

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 too ubiquitous. I don't want some other unexpected failure
> > producing the same ValueError and triggering my except clause.
>
> If you want to catch MissingArgumentsError, you're doing something
> really weird.  I'm trying to think of a realistic example and failing.
>

This type of error is already caught and identified by Python as a
TypeError in at least two different situations with the following (generic)
error messages:

X takes Y positional arguments but Z was given

X missing 2 required positional arguments: Y and Z

The fact that two such messages exist is indicative that this type of error
do occur in realistic code.

So, in theory, one could think of extracting these two subcases of
TypeError into a new exception subclass; personnally, I think that the
current error messages are sufficient and adding a new exception subclass
for them would just make the exception handling code more complicated than
necessary.

André Roberge

>
> > 2. When I get an error, especially from some shitty corporate system that
> > truncates the traceback, I want to get as many hints as possible about
> what
> > went wrong.
>
> Then you should read the exception reason.  You're still going to have
> to think about what your program logic error is, and a separate
> exception is going to be less use than an explanatory text string.
>
> --
> Rhodri James *-* Kynesim Ltd
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OER543LOXANLUUBUYSLKNBYO6EXYJIFA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rhodri James]

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 same ValueError and triggering my except clause.


If you want to catch MissingArgumentsError, you're doing something 
really weird.  I'm trying to think of a realistic example and failing.



2. When I get an error, especially from some shitty corporate system that
truncates the traceback, I want to get as many hints as possible about what
went wrong.


Then you should read the exception reason.  You're still going to have 
to think about what your program logic error is, and a separate 
exception is going to be less use than an explanatory text string.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[André Roberge]

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 reasonable request.
>
If there's enough support for this idea, then I'll be happy to start
> working on this, but even then it'll be a collaborative effort.
>

I believe the first step would be to show that which combination of
current_exception + messages should be split into various new exceptions.

To give a possible concrete example, if you have a look at
https://aroberge.github.io/friendly-traceback-docs/docs/html/tracebacks_en_3.6.html,
you will see that TypeError can have various messages such as:

* must be X not Y  (where X might be str and Y might be list, etc.)
* can only concatenate X (not Y) to X
* unsupported operand type(s) X for: Y and Z
* X not supported between instances of Y and Z
* bad operand type for unary X: Y
* X object does not support item assignment
* X takes Y positional arguments but Z was given
* X missing 2 required positional arguments: Y and Z
* X object is not callable

There are likely many more cases only for TypeError (not to mention other
types of errors.)

Note that there are actual tests for each of these (which is one important
criterion as mentioned by Serhly). (This comment does not mean that I am
not necessarily expressing support for adding many new exception types.)

You're welcome to start collaborating and help document all possible
cases.   This invitation to collaborate is, of course open to all.

André Roberge



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

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

[Steven D'Aprano]

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 they're catching.

You say that as if that's a bad thing. Except in the most blindingly 
obvious and simple cases, you're going to have to do that anyway. 
Working out what is being caught is not the hard part, unless you abuse 
try...except clauses:

try:
main()
except:
print("an error occurred")

is a classic example of exception misuse. But there are many smaller 
ways to abuse them too.

The hard part is usually figuring out *why* the exception occurred, not 
*what* you are catching.


> On the
> other hand, if the code is `except IntParsingError`, then I know exactly
> what it is they're catching.

Will you? Since I don't know what functions might raise IntParsingError, 
I can't tell what it might have raised it. I mean, sure, it is obviously 
something parsing an int in some sense, but that's pretty wide:

- must it be parsing a string? could it be bytes? 
- parsing a fraction?
- might it be a call to `eval` or `compile` or only `int`?

I think we need to distinguish between the two use-cases for exceptions:

- to halt processing and report an error to the developer;
- to be caught and recovered from.

In this case, I don't think there is any benefit to me, the developer, 
to read:

IntParsingError: invalid literal for int() with base 10: 'a'

over the status quo:

ValueError: invalid literal for int() with base 10: 'a'


and from the perspective of debugging, it's just bloat:

- one more thing to document
- one more thing for the test suite to test
- one more thing to learn
- one more thing to misspell
  (is it IntParsingError or IntParseError or IntParsingException?)
- one more class using up memory
- one more thing for IDEs and syntax colourisers to check for

etc. From the perspective of catching and recovering from errors, again, 
I doubt that there is much benefit to well-written code:

try:
num = int(astring)
except ValueError:
recover()

is fine, changing the ValueError to IntParsingError gains nothing. The 
only advantage I can see is if your try block falls into that very 
narrow zone where it is large enough to contain *exactly* one attempt to 
parse an int *but also* at least one other function call which might 
raise an unrelated ValueError:


try:
a, b = int(astring), float(alist)
except IntParsingError:
...

But I'm not sure that this is valuable enough to make up for the bloat.



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

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

[Peter Otten]

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, enhancing the error reasons texts is certainly something
> that would help everyone.
> 
> 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 attribute.

There is prior art, though, specifically for errno:

$ python2 -c 'open("not-there")'
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 2] No such file or directory: 'not-there'
$ python3 -c 'open("not-there")'
Traceback (most recent call last):
  File "", line 1, in 
FileNotFoundError: [Errno 2] No such file or directory: 'not-there'

I very much prefer the specific exception because most of the time I only 
want to handle the common problems. Instead of

try:
   open file
except OSError as err:
   if err.errno == what was file-not-found? ah ENOENT:
  # deal with it
   elif err.errno == what was is-a-directory? ah EISDIR:
  # deal with it
   else:
  # give up
  raise

I can now write

try:
open file
except FileNotFoundError:
# deal with it
except IsADirectoryError:
# deal with it

which (a) looks better to me and (b) is easier to remember. It's a bit like 
Guido's advice to use distinct functions instead of flags.

I am sure that I would quickly adopt more specific exceptions in other areas 
(most notably HTTPError). I don't think they all need to become built-ins. 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JF7WXRP6IEJCZDIUTVHGIRAAYM24SEAN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ram Rachum]

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 more thought into that...
100 is an arbitrary number of course. I gave a few specific examples
of UnpackingUnderflowError and MissingArgumentsError, and if I spent 30
minutes on it I could probably come up with 10 more examples. The point
isn't the specific example, but to advocate for a general strategy of
breaking down exception to as many classes as possible, instead of having
this fight over and over again on each exception.



> This is an idea I could get behind:
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/


Alex sent me that, I'm happy to see it :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CQKEPB27BU7QJWNBTDO7NKPINUSJUHYK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 expect ValueError and where
> I should expect TypeError.

If it took you a few years to learn that ValueError is raised for bad 
values, and TypeError for bad types, then it would probably take you 
three or four hundred years to memorise an additional 100 exceptions and 
their spellings.

"Is it UnpackingOverflowException or PackingUnderflowError or 
TooManyValuesUnpackException or ValueUnpackingError or ...???"

It took me far too long to learn the difference between 
UnicodeEncodingError and UnicodeDecodingError. Or is it 
UnicodeEncodeError and UnicodeDecodeError?

It is possible to have too many fine-grained errors as well as too 
few.


[...]
> Similarly, if I did this:
> 
> >>> def f(x, y): return x + y
> >>> f(1)
> 
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError, which
> would be a subclass of TypeError.

This is an idea I could get behind:

https://mail.python.org/archives/list/python-ideas@python.org/message/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/


> 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 same ValueError and triggering my except clause.

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. 
But in practice, it is surprisingly more practical than it sounds in 
theory.


> 2. When I get an error, especially from some shitty corporate system that
> truncates the traceback, I want to get as many hints as possible about what
> went wrong.

I sympathise, but it's not up to the language to work around the bad 
practices of lousy corporate systems.


> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument: 'y'".
> But that isn't guaranteed everywhere, and specific exception types could
> help.
> 
> 
> What do you think?

I think that speaking generically, being in favour of "better error 
messages" and "more fine-grained exceptions" is like being in favour of 
peace. But the devil is in the details. Peace at what cost?



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

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

[M.-A. Lemburg]

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 of
> `ImportError`, which I really liked. Was this also another instance of a
> confusion between the exception type and the exception reason?

No, because the ImportError can actually mean a lot of things (the
import machinery being rather complex) and you will want to be able to
catch the error situation where the module is not installed, rather
than e.g. an error which happened while loading an installed module.
> 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.
> 
> 
> Why would you have to memorize them? If you're writing an except clause,
> you could still write `except ValueError:` and it'll work the same as
> before.
> 
> Do you feel that the addition of `ModuleNotFoundError` meant that you
> now had to memorize a new exception?

Sure, because I would not know that this is actually a subclass of
ImportError.

The hierarchy already has quite a few exeption types and it's not
always clear that one type is subclass of another:

https://docs.python.org/3/library/exceptions.html#exception-hierarchy

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 01 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/22PK2OB6QHMNJUAMKO4ERVISOIGSMKTK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 not a reasonable request. If there's enough support for this 
idea, then I'll be happy to start working on this, but even then it'll 
be a collaborative effort.


There is nothing to discuss without the subject of discussion.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J37BHTL3O2XPIBMKTMB3RMORVQUVDVAG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Alex Hall]

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 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 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 where I should expect ValueError and where
> I should expect TypeError.
>
> It would be nice if the operation above raised UnpackingOverflowError,
> which will be a subclass of UnpackingError, along with
> UnpackingUnderflowError.  UnpackingError can be a subclass of ValueError,
> for backward compatibility.
>
> Similarly, if I did this:
>
> >>> def f(x, y): return x + y
> >>> f(1)
>
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError, which
> would be a subclass of TypeError.
>
> 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 same ValueError and triggering my except clause.
>
> 2. When I get an error, especially from some shitty corporate system that
> truncates the traceback, I want to get as many hints as possible about what
> went wrong.
>
> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument: 'y'".
> But that isn't guaranteed everywhere, and specific exception types could
> help.
>
>
> What do you think?
>
>
> Ram.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XZXWXICKS2RCQLLX73NJOWCJPRY7IUX2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZVX6Q6GFRVN6X43WZEAOBCDZTWJH56U6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ram Rachum]

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 the exception type and 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.
>

Why would you have to memorize them? If you're writing an except clause,
you could still write `except ValueError:` and it'll work the same as
before.

Do you feel that the addition of `ModuleNotFoundError` meant that you now
had to memorize a new exception?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UIOZ4AZ2VEF5YKUWJ7UZHPVLBZ32NRBX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ram Rachum]

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 IntParsingError`, then I know exactly
what it is they're catching.

On Fri, May 1, 2020 at 9:48 AM 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 maintain backward compatibility.
>
> 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 where I should expect ValueError and where
> I should expect TypeError.
>
> It would be nice if the operation above raised UnpackingOverflowError,
> which will be a subclass of UnpackingError, along with
> UnpackingUnderflowError.  UnpackingError can be a subclass of ValueError,
> for backward compatibility.
>
> Similarly, if I did this:
>
> >>> def f(x, y): return x + y
> >>> f(1)
>
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError, which
> would be a subclass of TypeError.
>
> 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 same ValueError and triggering my except clause.
>
> 2. When I get an error, especially from some shitty corporate system that
> truncates the traceback, I want to get as many hints as possible about what
> went wrong.
>
> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument: 'y'".
> But that isn't guaranteed everywhere, and specific exception types could
> help.
>
>
> What do you think?
>
>
> Ram.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6Z2XITLJ4RSAW4WGTVPCA2YSHXONM3HO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[M.-A. Lemburg]

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 certainly something
that would help everyone.

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

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 01 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/


On 01.05.2020 08:48, 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 maintain backward
> compatibility.
> 
> 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 where I should expect ValueError and
> where I should expect TypeError.
> 
> It would be nice if the operation above raised UnpackingOverflowError,
> which will be a subclass of UnpackingError, along with
> UnpackingUnderflowError.  UnpackingError can be a subclass of
> ValueError, for backward compatibility.
> 
> Similarly, if I did this: 
> 
>     >>> def f(x, y): return x + y
>     >>> f(1)
> 
> I would get a TypeError. Would be a lot cooler if I got
> MissingArgumentsError, which would be a subclass of SignatureError,
> which would be a subclass of TypeError.
> 
> 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 same ValueError and triggering my except clause. 
> 
> 2. When I get an error, especially from some shitty corporate system
> that truncates the traceback, I want to get as many hints as possible
> about what went wrong.
> 
> It's true that today, most Python exceptions have good text in their
> message, like "TypeError: f() missing 1 required positional argument:
> 'y'". But that isn't guaranteed everywhere, and specific exception types
> could help.
> 
> 
> What do you think? 
> 
> 
> Ram.
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/XZXWXICKS2RCQLLX73NJOWCJPRY7IUX2/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HKZTPPY5JHMAP7QSV7ALCT6O6TLETCDP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 not a reasonable request. If there's enough support for this idea,
then I'll be happy to start working on this, but even then it'll be a
collaborative effort.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IVNKPAYM3HT67CMULVUIOT35USUWWW6L/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 where I should expect ValueError and 
where I should expect TypeError.


It would be nice if the operation above raised UnpackingOverflowError, 
which will be a subclass of UnpackingError, along with 
UnpackingUnderflowError. UnpackingError can be a subclass of ValueError, 
for backward compatibility.


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.

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

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

[Ram Rachum]

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 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 where I should expect ValueError and where
I should expect TypeError.

It would be nice if the operation above raised UnpackingOverflowError,
which will be a subclass of UnpackingError, along with
UnpackingUnderflowError.  UnpackingError can be a subclass of ValueError,
for backward compatibility.

Similarly, if I did this:

>>> def f(x, y): return x + y
>>> f(1)

I would get a TypeError. Would be a lot cooler if I got
MissingArgumentsError, which would be a subclass of SignatureError, which
would be a subclass of TypeError.

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 same ValueError and triggering my except clause.

2. When I get an error, especially from some shitty corporate system that
truncates the traceback, I want to get as many hints as possible about what
went wrong.

It's true that today, most Python exceptions have good text in their
message, like "TypeError: f() missing 1 required positional argument: 'y'".
But that isn't guaranteed everywhere, and specific exception types could
help.


What do you think?


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