Coding style

[Patrick Maupin]

Christophe wrote:
> > The perverse wish, expressed in the specific example, that SOME piece
> > of code SOMEWHERE should PLEASE throw an exception because some idiot
> > passed a generator expression rather than a list into a function, is
> > not apt to be well received by an audience which strives for generality
> > when it makes sense
>
> Well then, you haven't beed using enouth generator expressions or else,
> that kind of mistake would have bitten you badly by now and you would
> agree with that remark !

I use generators frequently.

> > confronted with the wished-for exception, would fix the function so
> > that it quite happily accepted generator expressions, rather than
> > changing a conditional to use len() just so that an equivalent
> > exception could happen a bit earlier.
>
> Thanks but NO. If that function needs to iterate twice on the
> expression, then it needs to iterate twice and passing it a generator
> will only cause strange bugs.

The original post did not say "this function is iterating twice over
the same data."  It only said that there might be a significant
computational cost on an empty iterator, and wished that the code would
somehow throw an exception to alert the programmer to this cost.  I
maintain that if the cost is low enough that the programmer doesn't
notice it without the exception, there is no problem, and if the cost
is high enough that the programmer notices it, the profiler would find
the problem easily.

I'm not sure why you say "Thanks but NO" to the option of fixing the
function so that it accepts generators, but in any case if you know
up-front that a function needs to iterate twice over the same data and
you are too lazy to write some code to do that for generators (such as
by creating a list object or using the tee function), then by all means
feel free to check that the data coming into the function is not a
generator.  But this is still not a good reason why, in the general
case, "if len(lst)" should be preferred over "if lst".  In fact, I'm
not sure it's a good reason to use this construct even in this specific
case.  It would be too easy for someone to "fix" this during
refactoring.  If you really want to make sure that a function can only
take objects which have __len__ methods, why not come right out and say
so:

    assert hasattr(lst, "__len__")

Regards,
Pat