Re: Python or Perl for a Debian maintainance project?

[Florent Rougon <f.rougon@free.fr>]

Andrew Suffield <asuffield@debian.org> wrote:

>> > The only way to get shorter is to not handle the errors - which is the
>> > norm in python.
>> 
>> It's no different than Perl.
>
> Yes, precisely my point. What's yours?

Then your point is wrong. See <[🔎] 87wu6gafn5.fsf_-_@florent.maison>.

> Factually incorrect, because you get all that with perl too, and
> python's default error doesn't give you a meaningful description. See
> the Carp documentation.

You are very wrong. You should document yourself before asserting
blatantly wrong statements. Proof by example:

,----[ foo.py ]
| #! /usr/bin/env python
| 
| import sys
| 
| def foo_func(arg):
|     a = int(arg, 10)
| 
| 
| def main():
|     foo_func("abc")
|     
|     sys.exit(0)
| 
| if __name__ == "__main__": main()
`----

% /tmp/foo.py                                                     flo@florent
Traceback (most recent call last):
  File "/tmp/foo.py", line 14, in ?
    if __name__ == "__main__": main()
  File "/tmp/foo.py", line 10, in main
    foo_func("abc")
  File "/tmp/foo.py", line 6, in foo_func
    a = int(arg, 10)
ValueError: invalid literal for int(): abc

The description is very useful to the programmer. Much more useful than
a simple segmentation fault (I hope you don't run every binary under gdb
with debugging symbols enabled for day-to-day use). It is not very
useful to a clueless user, but this is a feature. An exception should
not be raised to the user. This is a bug in the program, but the way it
is handled due to exceptions provides very useful information to the
programmer in order to fix the bug. Without having to ask complicated
things to the clueless users (gdb and such).

As far as Carp is concerned, I tried a Google for "carp python" and the
first page seems to imply it is a Perl module, so I fail to see how it
can be relevant to juge the usefulness of "python's default error", as
you call it.

> Vomiting to the screen is not better than aborting. And comparing
> the quality of broken code is silly.

If you're not able to distinguish the above backtrace from vomit, I fear
there is nothing that can be made to help you understand exceptions.

> There's a perl module that calls die "moo" on every IO error if that's
> what you really want, but nobody uses it because when they think about
> it, that is not what they want. They want a *useful* error
> message. Not an obtuse message suggesting that there might be some
> sort of error.

Broken programs are broken. Yeah.

-- 
Florent