Coding style

[Bruno Desthuilliers]

Carl Banks wrote:
> Bruno Desthuilliers wrote:
> 
>>Carl Banks wrote:
>>
>>>Patrick Maupin wrote:
>>>
>>>
>>>>PTY wrote:
>>>>
>>>>
>>>>
>>>>>It looks like there are two crowds, terse and verbose.  I thought terse
>>>>>is perl style and verbose is python style.  BTW, lst = [] was not what
>>>>>I was interested in :-)  I was asking whether it was better style to
>>>>>use len() or not.
>>>>
>>>>It's not canonical Python to use len() in this case.  From PEP 8:
>>>>
>>>>- For sequences, (strings, lists, tuples), use the fact that empty
>>>>     sequences are false.
>>>>
>>>>     Yes: if not seq:
>>>>          if seq:
>>>>
>>>>     No: if len(seq)
>>>>         if not len(seq)
>>>>
>>>>The whole reason that a sequence supports testing is exactly for this
>>>>scenario.  This is not an afterthought -- it's a fundamental design
>>>>decision of the language.
>>>
>>>
>>>That might have made sense when Python and string, list, tuple were the
>>>only sequence types around.
>>>
>>>Nowadays, Python has all kinds of spiffy types like numpy arrays,
>>>interators, generators,
>>>etc., for which "empty sequence is false" just
>>>doesn't make sense.
>>
>>Iterators and generators are *not* sequences types. wrt/ non-builtin
>>container types, I suggest you re-read section 3.3.1 of the language
>>references:
> 
> 
> I'm aware of the semantics, thank you, and that they're as advertised
> in the docs.  It doesn't matter whether you call it a sequence or not.

Your opinion - not mine. Sequences are iterable, but not all iterables
are sequences.

> Iterables, lists, arrays, and whatever else have overlapping uses, but
> bool(obj) behaves differently for different types,

bool(obj) will mainly look for __len__(), then for __nonzero__(), then
return True. You can only call len(obj) on objects implementing
__len__(), so relying on (implicit) 'bool(obj)' is clearly more generic
than 'len(obj) > 0'.  Also, since bool(obj) will try to call
obj.__len__(), explicitely calling len(obj) doesn't make any difference.

> making it unsuitable
> for writing generic functions that might use some other types that
> aren't vanilla list, tuple, and string.

Using an explicit test against the length of an iterator or generator
*won't* work anyway, since iterators and generators are unsized. And
that's one of the reasons why the difference between sequences and
iterables does matter.

And if you want your own sequence types to be well-behaved sequence
types, just take time to implement the needed protocol(s), including
__len__().

For short: either your function expects an iterable or it expects a
sequence. If it expects an iterable, treat it as an iterable wether it
happens to be a sequence or not. If it expects a sequence, it obviously
won't work with a non-sequence.

> All I'm saying is, knowing there's lots of roughly-list-like

"roughly-list-like" ?

> types that
> don't consider "empty" to be  "false",

This means they are unsized (ie don't implement __len__).

> and that there's not reasonable
> way to get consistent behavior as to what the boolean value of such
> types is, 

I don't know what "types" you are talkink about, but seems like either
they're not designed to be treated as sequences or they are badly
implemented. In the first case, you're not using them correctly. In the
second case, send a bug report to the authors.

> it's possible that these types wouldn't even have a boolean
> value and any tests for emptiness would have to be explicit.

Yes ? How ? Calling len() on them ?-)
(hint: reread how len() and bool() works wrt/ __len__())



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"