General question about Python design goals

[Bengt Richter]

On 29 Nov 2005 08:27:43 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:

>On 2005-11-28, Duncan Booth <duncan.booth at invalid.invalid> wrote:
>> Antoon Pardon wrote:
>>
>>> 
>>> No I gave an example, you would implement differently. But even
>>> if you think my example is bad, that would make it a bad argument
>>> for tuples having list methods. That is not the same as being
>>> a good argument against tuples having list methods. 
>>
>> Tuples don't have list methods, therefore any code which seems to require a 
>> tuple with list methods should make you stop and consider whether your 
>> design is wrong.
>
>IMO that is a non-sequitur, because that makes what is good or bad
>design dependand on the language used.
>
>If I have a design that seems to require tuples with a count method,
>then wether that is a good or bad design doesn't depend on
>whether or not python allows that or not.
>
No, but if your requirement is to count __eq__ - matching items in a
tuple, maybe your sense of orthogonality ought to abstract out the
sequence aspect in some other way than seeing it as a seeming method
requirement for tuple. A tuple.count method has implications about
attribute access to a special object, tuple, which then you have
to deal with for every new object you introduce, unless you want to
inherit it from object, but that means object becomes a
mega swiss army knife in short order.

So IMO the thing is not to ask for a specific solution like "why
not a count method for tuples?" You'll just get answers to that literal
question, with some elaborations. Instead, if you put it in the form
of what your general requirement really is (I'm guessing ;-) which I
assume is to be able to apply list count method _functionality_ to
anything which quacks like a list, including tuples etc. In short,
anything iterable.

Now the problem is to bring program and data together with some
spelling in python. data.method() is certainly one spelling, but
so is method(data). You gain something either way. The first allows
you to associate the method and data without executing the method, i.e.,
data.method is a bound method object that has the data-method association
built in, and it can be passed around. method(data) does the call right
away and uses a diferent name space search path to find method, and is
not necessarily associated with type(data). To ask for common methods
for all objects that exhibit some similar aspect is to entangle their
types in some way or to duplicate stuff. Sometimes it's fine to
derive from a common base etc., but

why not a built-in count function that does something like (untested)

    def count(obj, match_item, eq=operator.eq):
        return sum(1 for item in iter(obj) if eq(item, match_item))

which would give a little flexibility about eq comparison as well as
wide applicability to any sequence? index too (untested)

    def index(obj, match_item, eq=operator.eq):
        try: return (i for i, item in enumerate(obj) if eq(item, match_item)).next()
        except StopIteration: raise ValueError('index(seq, item): item not in seq')

why doesn't list have a find like str? ;-)

    def find(obj, match_item, eq=operator.eq):
        try: return (i for i, item in enumerate(obj) if eq(item, match_item)).next()
        except StopIteration: return -1

One could create an alternate spelling for obj.count(thing) using the count function above.
You can spell it now as

    count.__get__(obj, type(obj))(thing)

if you want to duplicate the effect of having the count function retrieved from type(obj)
as if it were a method defined there. Or you can spell it

    count(obj)

which doesn't seem too bad ;-)
But now the problem is cluttering the __builtins__ space. So maybe it would be
better to write
    from sequence_goodies import count
    ...
    count(obj)

Do you really want a count method for tuple? Or is that maybe not as clean is
it seemed? All the issues aren't usually immediatly apparent, so IMO the more
we focus on abstract functionality desired, the more likely we will get
helpful solution ideas for a menu of choices, and avoid prematurely discussing
whether we should have pumpkin pie with or without whipped cream, when finally
we might all like strawberries and cream better, if someone had thought of it.

Regards,
Bengt Richter