"Humane" programmer interfaces

Andrew Durdin adurdin at gmail.com
Tue Jan 3 04:55:28 CET 2006

On 1/3/06, Alex Martelli <aleax at mail.comcast.net> wrote:
> Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> >  if somestr[:len(needle)] == needle:
> This is definitely more readable, and the same would apply if I tested
> somestr[:len('glab')] == 'glab' -- the key point being that one knows
> where that slice limit comes from, rather than having to guess.

I don't think there'd be much argument that 
somestr.startswith('glab')  is significantly clearer (in action and
intent) than  somestr[:len('glab')] == 'glab'  -- even if you use a
variable instead of repeating the literal. So this is not an example
of a purely redundant way of comparing the start of a string, because
there is a significant gain in clarity.  OTOH, that  somestr.last  is
*significantly* clearer in action or intent than  somestr[-1]  is
questionable.  I don't believe that it is -- but I agree with you that
having it is not necessarily a design error (i.e. "obviously wrong").

> But that doesn't really change the main point, that Python does offer
> redundant ways to perform several tasks -- a general one (often based on
> slicing) and a specialized one with a readable name

In many cases there can be subtle semantic differences separating the
"redundant" ways, which makes them non-equivalent.

> Much like I prefer using list(alist) to make
> a copy (more readable), rather than the concise idiom alist[:] based on
> slicing,

These are identical only for the case where  type(alist) == list.  If
alist issome other sequence-like type, then the equivalence no longer

> e.g.
> del L[a:b] as the equivalent of L[a:b]=[], and yet the "alternative
> readable synonym" gets offered anyway.

These too may not be equivalent, if the behaviour of __setitem__ and
__delitem__ differ for L.__class__; although I cannot think of a good
reason to not have them equivalent for any sequence-like object.

As I said before "With one simple, obvious, general interface, these
special cases only add unneeded complexity."   If the general
interface is either not simple or not obvious for a task, then a
special interface is likely more suitable.


More information about the Python-list mailing list