unittest.TestCase, lambda and __getitem__

[Alex Martelli]

Steven Bethard <steven.bethard at gmail.com> wrote:

> Alex Martelli <aleaxit <at> yahoo.com> writes:
> > Steven Bethard <steven.bethard <at> gmail.com> wrote:
> > > Or is there a better/clearer way of handling this kind of test case?
> > 
> > Sure:
> > 
> >     def wrong_indexing(): return obj[index]
> >     self.assertRaises(ValueError, wrong_indexing)
> 
> Yeah, I guess I was just begging someone to give me that response. ;)
> 
> First, I have to mention that I'd probably have to write your code as
> 
> def wrong_indexing():
>     return obj[index]
> self.assertRaises(ValueError, wrong_indexing)
> 
> because GvR has also commented that he wishes he hadn't allowed the one-
> line "if: statement" syntax, so by analogy, I assume he'd also rather no one-
> line def statement.  So I'm stuck replacing a single line with three...  I was

I don't think the two issues are comparable.  Consider the PEP:

http://www.python.org/peps/pep-3000.html

which, while of course still very tentative, DOES express Guido's
current plans for the future, non-backwards-compatible Python 3000.

"The lambda statement" is first on the list of things "to be removed".
(Of course, there IS no such thing -- it's not a statement -- but I hope
that's just a minor error in the PEP;-).

There is no indication on the PEP that Guido means to remove the ability
to use a single line such as def name(): return 23.  The PEP does pick
up many specific changes coming from the 'Regrets' document,
http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf , and
specifically points to that document; but the PEP does not mention as
planned changes any of the lexical issues in the Regrets document (use
of \ for continuation, one-line if, use of tabs).  Until further notice
I think this means these lexical aspects aren't going away.

> hoping to avoid this...  (Of course, if I have a bunch of obj[index] type
> calls, I can average the additional line cost over all of these by making the
> function suitably general.)
> 
> Regardless, your analogy between obj[index] and an arbitrary mathematical
> expression was helpful.  It clarifies that, what I really want is an anonymous
> code block...

It generally is: lambda isn't a block and def isn't anonymous -- given
the tiny investment required to cook up a name for def, I think this
means def is much closer than lambda to what you want.  When you change
lambdas to defs you often find that the modest effort of naming is
actually USEFUL, since it helps clarify your code, and sometimes you get
to generalize and better apply "once and only once".

All in all I think changing lambdas into defs is a worthy endeavour and
enhances your code.  And if it should ever turn out in the future that
you do need a line break after the : in "def name(): ...", it's a
trivial and totally mechanical transformation with any editor (or an
auxiliary Python script), no effort at all.  So I wouldn't let that
distant prospect worry me in the slightest.


> Hmm...  Well, if this is really the only option, I'll probably leave these
> lambdas until I absolutely have to remove them...

I've never seen a syntax proposed for an "anonymous def" that Guido
would find in the least acceptable, if that's what you mean.  I still
think that perfectly ordinary defs are fine, and better than lambdas,
but of course it's your code so it's your decision.


Alex