[Python-3000] Traits/roles instead of ABCs
barry at python.org
Tue May 1 01:16:09 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Apr 30, 2007, at 6:01 PM, BJörn Lindqvist wrote:
> On 4/30/07, Bill Janssen <janssen at parc.com> wrote:
>>> On 4/30/07, Raymond Hettinger <python at rcn.com> wrote:
>>>> I'm concerned that the current ABC proposal will quickly evolve
>>>> from optional
>>>> to required and create somewhat somewhat java-esque landscape where
>>>> inheritance and full-specification are the order of the day.
>>> +1 for preferring simple solutions to complex ones
>> Me, too. But which is the simple solution? I tend to think ABCs
> Neither or. They are both an order of a magnitude more complex than
> the problem they are designed to solve. Raymond Hettingers small list
> of three example problems earlier in the thread, is the most concrete
> description of what the problem really is all about. And I would
> honestly rather sort them under "minor annoyances" than "really
> critical stuff, needs to be fixed asap."
Interfaces and ABCs are really all about Programming in the Really
Large. Most Python programs don't need this stuff, and in fact,
having to deal with them in any way would IMO reduce the elegance of
Python for small to medium (and even most large) applications. I
think the experience of Zope, Twisted, and PEAK have shown though
that /something/ is necessary to manage the complexity when
applications become frameworks.
To me, interfaces and/or generic functions strike the right balance.
Such tools are completely invisible for Python programmers who don't
care about them (the vast majority). They're also essential for a
very small subclass of very important Python applications.
If ABCs can walk that same tightrope of utility and invisibility,
then maybe they'll successfully fill that niche.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-3000