Python Iterables struggling using map() built-in

[Ian Kelly]

On Wed, Dec 10, 2014 at 9:01 PM, Steven D'Aprano <steve at pearwood.info>
wrote:
>
> 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.

I don't think I'm missing the point. os.path is a module. That makes it
well suited for a namespace, because that's what modules are designed and
expected to provide: the implementation of namespaces. A function, on the
other hand, is not well suited to be a namespace, because it's not expected
to provide one. When I see a new function, I don't think "I should check
what attributes it has." Instead, I wonder about what parameters it takes
and what it returns.

I expect to be able to open up my web browser and go to the library
documentation for the os.path module. I don't expect to find a separate
page for statistics.median, because the docs are organized around modules,
not functions.  Would the median function itself be documented in the
statistics page, in the statistics.median page, or redundantly in both?

I expect to be able to import modules, and by extension, namespaces.
 "import os.path" works.  "import statistics.median.low" would return an
error, as would "from statistics.median import low as median", if that were
the only function I wanted. In the latter case I would have to do something
like "from statics import median; median = median.low". That's not just
ugly; it also demonstrates how the programmer needs to remember and
incorporate the detail that this namespace does not work like other
namespaces.

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

To me this sounds backward. Namespaces are a great idea, but at the same
time they also create cognitive burden. One creates a namespace because the
contents are important enough to be referenced as a group, not because they
aren't as important as the other things they're grouped with. The reason
the collections ABCs were moved into collections.abc wasn't because they
weren't important enough to be in the top-level collections module.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20141211/0b17df09/attachment.html>