On Aug 8, 2019, at 15:01, Ryan Fox <r...@rcfox.ca> wrote:
>
> I don't see why you would want to access arguments by their position.
Because that’s the way it’s worked since Python 1.x, and there’s tons of
existing code that expects it, including the default __str__ and __repr__ for
exceptions and the code that formats tracebacks.
> The user-defined exceptions in the Python documentation don't pass arguments
> to the base class either:
> https://docs.python.org/3/tutorial/errors.html#user-defined-exceptions
Yes they do. Try it:
>>> e = InputError('[2+3)', 'mismatched brackets')
>>> e.args
('[2+3)', 'mismatched brackets')
>>> e
InputError('[2+3)', 'mismatched brackets')
If you’re wondering why this works, it’s because Error and InputError don’t
override __new__. Which should make it obvious why a tutorial aimed at novices
doesn’t get into the details, but that’s why Python has reference manuals
instead of just a tutorial.
Also, notice that the tutorial examples don’t even try to create a formatted
message; they expect that the type name and the args will be enough for
debugging. I’m not sure that’s a great design, but it means that your intended
fix only solves a problem they didn’t even have in the first place.
> So let's go ahead and assume my implementation is flawed. The fact that
> people prefer to copy their format strings all over their projects implies
> that the current exception scheme is suboptimal. Can we agree on that? If
> not, there's no need to continue this discussion.
I agree that it would be nice for more people to move their message formatting
into the class, but you need a design that encourages that without fighting
against the fact that exception args are positional, and I’m not sure what that
looks like. And I don’t think it’s your implementation that’s bad (it seems to
do what it says perfectly well), but that the design doesn’t work.
Of course if you were designing a new language (or a new library from builtins
up for the same language), this would be easy. Exceptions would look like
(maybe be) @dataclasses, storing their arguments by name and generating
repr/str/traceback that takes that into account, and all of them would actually
store the relevant values instead of half of them making you parse it out of
the first arg, and there would be a special message property or method instead
of args[0] being sort of special but not special enough, and so on. And then,
providing an easier way to create that message property would be an easy
problem. But I think with the way Python is today, it’s not.
Of course I’d be happy to be proven wrong on that. :)_______________________________________________
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/5ULPVNH6RBFXY24P76YZCAKIKOLHWF2B/
Code of Conduct: http://python.org/psf/codeofconduct/
