[Python-Dev] pprint(iterator)

[Nick Coghlan]

Walter Dörwald wrote:
> Paul Moore wrote:
>> 2009/1/30 Walter Dörwald <walter at livinglogic.de>:
>>> Paul Moore wrote:
>>>
>>>> [...]
>>>> In all honesty, I think pkgutil.simplegeneric should be documented,
>>>> exposed, and moved to a library of its own[1].
>>> http://pypi.python.org/pypi/simplegeneric
>>
>> Thanks, I was aware of that.
> 
> I wasn't aware of the fact that simplegeneric is part of the stdlib,
> albeit in a strange spot.

Officially, it isn't - it's an implementation detail of pkgutil. As
such, a leading underscore wouldn't have hurt, but the lack of mention
in the pkgutil documentation (or pkgutil.__all__) is hopefully enough of
a hint that it really isn't intended as a general purpose programming tool.

>> I assume that the barrier to getting this
>> into the stdlib will be higher than to simply exposing an
>> implementation already available in the stdlib.
> 
> At least we'd need documentation and tests. And of course the code must
> be stable and there must be someone willing to maintain it (then again
> it's less than 40 lines of code).
> 
> There should be enough third-party module that use it to justify making
> simplegeneric an official part of the stdlib.
> 
> The best spot for generic() is probably in the functools module.

>> To be honest, all I
>> would like is for these regular "let's have another special method"
>> discussions to become unnecessary...
> 
> Me too.

A trio of patches that:
1. promoted simplegeneric from pkgutil to functools (with appropriate
documentation and tests)
2. changed pkgutil to use functools.simplegeneric instead of its current
 internal version
3. updated pprint to be a generic function (and hence more easily
extensible via the ABC mechanism, while still keeping it's current
special cases as necessary)

would certainly be an interesting thing to see (with patch 3 being the
poster child for why patch 1 is a good idea).

The major virtue of such a basic generic framework is that it is much
easier to explain than the all-singing all-dancing overloading system
described in PEP 3124. Type-based dispatch on the first argument is
fairly straightforward to describe in terms that make sense to anyone
that is already familiar with dynamic dispatch of class and instance
methods. It's only when you get into more exotic dispatch conditions and
up-calls and the like that people's eyes start to glaze over.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------