Thoughts on List Methods and Return Values

[David Bolen]

Don O'Donnell <donod at home.com> writes:

(...)

> After a few minutes of debugging, I realized why this doesn't work. 
> Obviously, sort() and reverse() are not the only list methods that don't
> return a value, insert() doesn't either.  So, I ended up with the
> following:
> 
> 	searchList = list(altSeq)
> 	searchList.insert(0, currPath)
> 	searchList = filter(None, searchList)
> 
> (I won't argue the fact that this may be more readable, but that's not
> the issue.)

(...)

> Which leads me to the thought that if *all* the methods which now return
> None were to modify the list in place as well as return the modified
> list, we would soon get used to this behaviour and achieve some coding
> economy by being able to chain operations.

Ah, so the point is trying to get coding economy in an arguably less
readable form?  Personally, I'd stick with giving readability (and
thus maintainability) the best chance at the expense of a little more
code text.

And as you note later,

> Hmmm... after looking back at my initial incorrect (one-liner) code,
> it's obvious that there's another problem -- the original input sequence
> (altSeq) is modified even though it doesn't look like it is, and I might
> use altSeq later on thinking it still contained it's original values. 
> Whereas, in the correct 3-liner, it's obvious what's being modified and
> what's not.  This can be easily remedied, however, by using the same
> name for both input and result sequences:

so if code just doesn't happen to have a convention for always
assigning to the same name as the modified list, it may be easy to
skip over while maintaining it.  I'd rather that Python itself gave a
little nudge in the right direction and ensured that the odds were in
the code's favor.

I've definitely noticed over time that when I tend to get a touch
annoyed at something in Python (and I've definitely had that feeling
at times with sort(), and the non-assignment in expressions, and so
on), that I'm sort of getting annoyed that I can't write a more
complicated piece of code that "feels" more elegant or compact, but in
reality is probably just a touch more obfuscated.  And in the end, the
"simpler" feeling code that's built out of more statements really is
just that - simpler to read, simpler to understand and simpler to
maintain.  While still behaving properly.  Amazing :-)

> ... So, maybe it's not such a great idea after all.  But after doing all
> this typing I'm sure as hell not going to scrap this post  ;o)

:-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/