Python Iterables struggling using map() built-in

[Ian Kelly]

On Wed, Dec 10, 2014 at 2:24 AM, Steven D'Aprano <steve at pearwood.info>
wrote:
>
> Example: In the statistics module in Python 3.4, I added a `median`
> function to calculate the median by the traditional schoolbook algorithm.
> But that's only one out of a number of ways to calculate medium, and
> inspired by similar syntax from R I proposed adding additional methods to
> that `median` object:
>
>     median.low(alist)
>     median.high(alist)
>
> etc. We all know that functions are first class objects with attributes
> and methods, they have a __dict__ so you can attach per-function data to
> them. And there's the last line of the Zen, about namespaces being
> awesome. Every instance with a __dict__ is a namespace.
>
> This ought to be a no-brainer, but apparently nobody has any experience
> with callable attributes attached to instances:
>
>     math.sin(x)
>     "some string".split(s)
>
> We make it a point of pride that functions in Python are not just first
> class values but that they are objects with attributes and methods and a
> per-instance __dict__. But when somebody proposes making use of that, it
> is rejected. Not that I'm bitter :-)

I don't particularly have a problem with functions having attributes, e.g.
I think itertools.chain.from_iterable is just peachy. There is a downside
though, which is that making those functions attributes of another function
rather than of the module defeats the dir() function for that module.
Likewise the generated help for the help() function, unless care is taken
to explicitly mention the existence of those functions in either the doc
string for the module or the standard median function. Thirdly, IDEs with
code completion features may simply fail to notice that these alternate
versions of the function exist. For these reasons I think that this is an
anti-pattern and is best avoided in the standard library. Having to type _
instead of . is only one extra key stroke.

Now if there were an established pattern to such function attributes, e.g.
if f.len(parrots) was a standard alternative to len(f(parrots)) for
functions that return sequences, then that could be a useful feature,
especially if such properties could be chained arbitrarily. But one-offs
like median.low would only serve to make the function more difficult to
find than necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20141210/be8aea70/attachment.html>