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/
