Carl Banks wrote:
On Dec 24, 1:24 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
OTOH, going the extra mile to hide useful information from a user is
asinine. As a user, I will decide for myself how I want to use
implementation-defined information, and I don't want the implementor to
decide this for me. It's bad enough if an implementor fails to provide
information out of laziness, but when they deliberately do extra work to
hide information, that's self-importance and arrogance.
But that of course is nonsense, because as the user you don't decide
anything of the sort.
As a user I can criticize the decision of the implementor to
needlessly filter information, and declare that it's borne out of the
author's arrogance in thinking he knows what I want when I get a
traceback.
I can also opine that Python language shouldn't make it easy for
library implementors to be arrogant like this.
The developer responsible for writing the function
decides what information he provides you, starting with whether you get
an exception at all, where it comes from, the type of exception, and the
error message (if any). Once this information has been passed on to you,
you're free to do anything you like with it, but you never get to choose
what information you get -- I'm not suggesting any change there. All I'm
suggesting is that there should be a way of reducing the boilerplate
needed for this idiom:
def _validate_arg(x):
if x == 'bad input': return False
return True
def f(arg):
if not _validate_arg(arg):
raise ValueError
process(arg)
to something more natural that doesn't needlessly expose implementation
details that are completely irrelevant to the caller.
Arrogance. Who gave you the right to decide what is completely
irrelevant to user? I, as the user, decide what's relevant. If I
want implementation-dependent information, it's my business.
I don't want the language to make it easy for arrogant people, who
think they know what information I want better than I do, to hide that
information from me.
One of the many things I love about Python is that it stays out of the
way of me getting my work done. I think a truly pythonic
program/library/module must do the same. So in this regard I agree with
Carl.
There are also times when I change the exception being raised to match
what python expects from that type of object -- for example, from
WhatEverException to KeyError for a dict-like object. So in this regard
I agree with Steven.
For kj's concern, which seems to be along the lines of functional as
opposed to custom object, I don't think the traceback should be monkied
with -- either use a decorator to keep the traceback short, or give the
_pre_func name a good name and don't worry about it. I know when I see
a traceback, I start at the bottom and only work my way up if I need to.
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
