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 -- https://mail.python.org/mailman/listinfo/python-list