[prev in list] [next in list] [prev in thread] [next in thread]
List: python-ideas
Subject: Re: [Python-ideas] (no subject)
From: Brett Cannon <brett () python ! org>
Date: 2016-11-30 17:57:22
Message-ID: CAP1=2W7spJpiZGXJndVgUfRSUS9Lhr4TVb_8nkUCgNW6aDD+kg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, 29 Nov 2016 at 12:32 MRAB <python@mrabarnett.plus.com> wrote:
> On 2016-11-29 19:45, Brendan Barnwell wrote:
> > On 2016-11-29 09:43, Brett Cannon wrote:
> >> One way to make this cheap is to have a reasonable default message and
> >> use attributes on the exceptions trigger the use of the default message.
> >> Nearly a year ago I filed a bunch of issues for ideas on providing
> >> attributes on exceptions where it made sense, e.g. an index attribute on
> >> IndexError (http://bugs.python.org/issue18162). If we did this then for
> >> classes like IndexError there constructor could be `IndexError(index=10,
> >> start=0, end=3)` and then __str__() can lazily construct the string
> >> representation using a default message, e.g. `"index {} is out of range
> >> of{} to {}".format(index, start, end)`. Make the arguments keyword-only
> >> and they become backwards-compatible and so the only overhead you pay
> >> for these richer messages are keyword-based construction if you simply
> >> never access the repr for the exception.
> >
> > I absolutely think this is the way to go. Having the relevant
> > information (the list that was too short, the index that was too big,
> > the key that wasn't there, etc.) is useful in many situations, and it's
> > much better to have that information in a programmatic form than just
> > squashed into an error message. This then makes it relatively easy to
> > write wrappers that take bubbling-up exceptions and try to construct
> > more detailed messages for a less experienced audience. Right now this
> > is difficult or impossible because the exception objects don't record
> > the information that would be needed for these expanded messages.
> >
> Couldn't that result in objects being held for longer, taking up memory,
> not being collected as promptly, and not releasing resources as quickly?
>
Sure, just like passing any other object into BaseException's initializer
so it gets stored in the args attribute. Notice how my example only used
ints, and that was on purpose. If you want to only pass in the repr of the
type for the message, then simply enforce that or at least encourage it to
prevent/discourage people from using whole objects instead of ints and
strings which are cheaper than the whole string message that is currently
constructed eagerly.
[Attachment #5 (text/html)]
<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 29 Nov 2016 at \
12:32 MRAB <<a href="mailto:python@mrabarnett.plus.com">python@mrabarnett.plus.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-11-29 19:45, Brendan \
Barnwell wrote:<br class="gmail_msg"> > On 2016-11-29 09:43, Brett Cannon \
wrote:<br class="gmail_msg"> >> One way to make this cheap is to have a \
reasonable default message and<br class="gmail_msg"> >> use attributes on the \
exceptions trigger the use of the default message.<br class="gmail_msg"> >> \
Nearly a year ago I filed a bunch of issues for ideas on providing<br \
class="gmail_msg"> >> attributes on exceptions where it made sense, e.g. an \
index attribute on<br class="gmail_msg"> >> IndexError (<a \
href="http://bugs.python.org/issue18162" rel="noreferrer" class="gmail_msg" \
target="_blank">http://bugs.python.org/issue18162</a>). If we did this then for<br \
class="gmail_msg"> >> classes like IndexError there constructor could be \
`IndexError(index=10,<br class="gmail_msg"> >> start=0, end=3)` and then \
__str__() can lazily construct the string<br class="gmail_msg"> >> \
representation using a default message, e.g. `"index {} is out of range<br \
class="gmail_msg"> >> of{} to {}".format(index, start, end)`. Make the \
arguments keyword-only<br class="gmail_msg"> >> and they become \
backwards-compatible and so the only overhead you pay<br class="gmail_msg"> >> \
for these richer messages are keyword-based construction if you simply<br \
class="gmail_msg"> >> never access the repr for the exception.<br \
class="gmail_msg"> ><br class="gmail_msg">
> I absolutely think this is the way to go. Having the relevant<br \
class="gmail_msg"> > information (the list that was too short, the index that was \
too big,<br class="gmail_msg"> > the key that wasn't there, etc.) is useful in \
many situations, and it's<br class="gmail_msg"> > much better to have that \
information in a programmatic form than just<br class="gmail_msg"> > squashed into \
an error message. This then makes it relatively easy to<br class="gmail_msg"> > \
write wrappers that take bubbling-up exceptions and try to construct<br \
class="gmail_msg"> > more detailed messages for a less experienced audience. \
Right now this<br class="gmail_msg"> > is difficult or impossible because the \
exception objects don't record<br class="gmail_msg"> > the information that \
would be needed for these expanded messages.<br class="gmail_msg"> ><br \
class="gmail_msg"> Couldn't that result in objects being held for longer, taking \
up memory,<br class="gmail_msg"> not being collected as promptly, and not releasing \
resources as quickly?<br class="gmail_msg"></blockquote><div><br></div><div>Sure, \
just like passing any other object into BaseException's initializer so it gets \
stored in the args attribute. Notice how my example only used ints, and that was on \
purpose. If you want to only pass in the repr of the type for the message, then \
simply enforce that or at least encourage it to prevent/discourage people from using \
whole objects instead of ints and strings which are cheaper than the whole string \
message that is currently constructed eagerly.</div></div></div>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic