Python Iterables struggling using map() built-in

[Steven D'Aprano]

On Wed, 10 Dec 2014 09:46:55 -0700, Ian Kelly wrote:

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

I think you are missing the point of namespaces :-)

When I call dir(os), I see os.path, but I don't see the names in os.path. 
That is working as designed.


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

Yes.

I don't have a problem with saying "See also ``median.low``" in the 
docstring for median.

I would also have raised a feature request (and/or patch) for having 
help() automatically display functions and methods attached to a 
function, much as it already does for classes.

As the designer of the module I thought that median_low and median_high 
were important enough to include but not important enough to stick in the 
main module namespace. I wanted to delegate them to secondary status by 
putting them in a separate lightweight namespace, without going all the 
way to making statistics be a package. I even considered doing the same 
for the population variance and standard deviation, but decided against 
it as most people are familiar with them from scientific calculators and 
school.

Python gives us the functionality to include multiple namespaces in a 
single module. Despite the Zen of Python, hardly anyone makes use of the 
fact that functions are namespaces. I wish to rail against that :-)


> Thirdly, IDEs with code completion features may simply fail to
> notice that these alternate versions of the function exist.

Hmmm, that would be a bad bug in the IDE then. If I type

    foo.


I would expect the IDE to complete on whatever attributes foo has, 
regardless of whether it is a function or some other object.

I have tab completion enabled in Python 2.7, and it works for me:

py> def spam(): pass
... 
py> spam.
Display all 31 possibilities? (y or n)
spam.__call__(          spam.__globals__        spam.__str__(
spam.__class__(         spam.__hash__(          spam.__subclasshook__(
spam.__closure__        spam.__init__(          spam.func_closure
spam.__code__           spam.__module__         spam.func_code
spam.__defaults__       spam.__name__           spam.func_defaults
spam.__delattr__(       spam.__new__(           spam.func_dict
spam.__dict__           spam.__reduce__(        spam.func_doc
spam.__doc__            spam.__reduce_ex__(     spam.func_globals
spam.__format__(        spam.__repr__(          spam.func_name
spam.__get__(           spam.__setattr__(       
spam.__getattribute__(  spam.__sizeof__(        


I expect that most IDEs will Just Work in this case.

[...]
> Now if there were an established pattern to such function attributes,

But there's the rub. That's the conservatism I'm referring to. Somebody 
has to be the first to do such a thing, and if we reject it because 
nobody does it, nobody will do it because when they try they're always 
rejected.

We know namespaces are great and useful. We use namespaces in the form of 
modules, packages and classes, and the Zen says we should use more of 
them. But we don't, because we're trapped in a vicious circle where 
attempts to use more namespaces get dismissed because nobody uses them, 
and nobody uses them because when they try it gets dismissed :-(


Oh well, there's always my own non-stdlib modules :-)



-- 
Steven