On 12/10/2014 11:46 AM, 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
Itertools.chain is a class, not a function. Chain.from_iterable is an
*alternate constructor* for instances of the class, just as
dict.fromkeys is an alternate constructor for dict instances.
It is true that if itertools were written in python, chain and the other
classes would likely be written as generator functions, so tha analogy
would not apply.
defeats the dir() function for that module.
And it is also true that dir(__builtins__) does not show dict.fromkeys.
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
help(it.chain) lists
| from_iterable(...) from builtins.type
| chain.from_iterable(iterable) --> chain object
|
| Alternate chain() contructor taking a single iterable argument
| that evaluates lazily.
help(dict)
| fromkeys(iterable, value=None, /) from builtins.type
| Returns a new dict with keys from iterable and values equal to
value.
Thirdly, IDEs with code completion features may simply fail to
notice that these alternate versions of the function exist.
I don't know what you mean here. In Idle
>>> it.chain. --> completion box with from_iterable
>>> dict. --> completion box that includes fromkeys
None of the above is to say that alternate constructors for classed are
not a bit awkward. I believe this was recognized when dict.fromkeys was
added. But it was considered less awkward than the alternatives: 1. do
not add the functionality; 2. further overload the main (__init__)
constructor; 3. add a independent function. Anyway, they exist, are an
accepted pattern among core devs, and will probably increase in number.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
