On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
> 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. > I don't really understand what you mean here. This property was broken since ImportError started accepting keyword arguments. For example: >>> ImportError("message", name="name", path="path").args ('message',) >>> ImportError("message", "foo", name="name", path="path").args ('message', 'foo') For the case of str and repr, one could just call super with the formatted message as the only positional argument. I suggest taking a look at PEP 473 <https://www.python.org/dev/peps/pep-0473/> for ideas on why having structured arguments is a good idea. > > 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/ > -- Sebastian Kreft
_______________________________________________ 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/ZOLTXVQPUFWFJXO66JT7JEP2BMLVC5OF/ Code of Conduct: http://python.org/psf/codeofconduct/