Suggested coding style

Devin Jeanpierre jeanpierreda at gmail.com
Mon Sep 26 03:15:49 CEST 2011


> I would have thought that a better solution would be to specify a
> minimal set of methods in an abstract superclass and write the
> additional methods using that minimal set.
>
> The concrete string implementations would be descended from the
> superclass and would still be able to override the additional methods
> with more efficient code were desired, such as in the 'str' class.

This does sound better to me too!

Devin

On Sun, Sep 25, 2011 at 8:47 PM, MRAB <python at mrabarnett.plus.com> wrote:
> On 26/09/2011 01:23, Devin Jeanpierre wrote:
>>>
>>>  Why does it suck?
>>
>> The gist of what I was saying is that it's possible to define
>> functions that do this "generically" so that one implementation of
>> zfill can work with multiple implementations of strings. Having to
>> reimplement every time when one implementation would do is bothersome
>> and generally isn't done unless it has to be (thus why mmap lacks a
>> zfill method). Having to do more work than necessary "sucks", as does
>> having partial str implementations that don't do everything str does.
>>
>> Ideally, I would claim that if some interface will have multiple
>> implementations, it should have as few methods as possible to make
>> implementation as easy as possible, and move as much as possible
>> _away_ from methods and into functions that work with arbitrary
>> implementations of the interface. This minimizes the amount of work
>> that must be done for implementors and thus makes life better.
>>
> [snip]
> I would have thought that a better solution would be to specify a
> minimal set of methods in an abstract superclass and write the
> additional methods using that minimal set.
>
> The concrete string implementations would be descended from the
> superclass and would still be able to override the additional methods
> with more efficient code were desired, such as in the 'str' class.
> --
> http://mail.python.org/mailman/listinfo/python-list
>



More information about the Python-list mailing list