On Thu, Aug 8, 2019 at 5:24 PM Sebastian Kreft <skr...@gmail.com> wrote:
>
>
> 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.
>
The property isn't broken for ImportError, it just isn't being given the
keyword arguments because it didn't makes sense to pass them down with no
information attached to it. The 'args' attribute still gets the message
which is the key detail.
-Brett
>
> 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/
>
_______________________________________________
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/34RJSUDUOT3ORA4IY3GDPWHR5U2XH7RR/
Code of Conduct: http://python.org/psf/codeofconduct/
