General question about Python design goals

[Antoon Pardon]

On 2005-11-29, Bengt Richter <bokr at oz.net> wrote:
> 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.

I'm open too other possibilties, and I'm interrested in your iterator
methods. It is just that on the one hand people talk about the
advantages of tuples as keys, (no need to copy the keys, since
they are immutable) while on the other hand when tuples lack
some functionality tell me to cast them as lists, completely
eliminating the adavantage tuples have.

> 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.

Sure, A base sequence type, from which tuples and lists would inherit
that would provide for this functionality would be good too. Of
course it isn't that difficult to write a general function that works
on any iterable either.

> 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.

There are other ways to get a bound method like object, so I don't
consider that a big advantage.

> 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))

Sure. The problem here is a bit about python only providing a partial
solution. If python didn't provide any count methods I think nobody
would have complained. If you needed this, you could easily provide
it your self.

But now python does provide it, but not for all classes it seems
applyable to, so people question why.

> 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)

Sure, thanks for the suggestion, I think I'll write me a sequence module
with these and similar function. It seems just a bit stupid, because
once I wrote all of these, a number of list methods seem just a waste
that is to be carried along.

> 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.

Well my preferred solution, would have been if sequence had been a mixin
class, that would provide a number of methods for subclasses that
provide the right protocol and then tuple and list being such a 
subclass. I think that would have been more pythonic than your suggested
solution, but I think your suggestion is a valuable alternative.

-- 
Antoon Pardon