On Wed, Dec 10, 2014 at 9:01 PM, Steven D'Aprano <st...@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.
-- https://mail.python.org/mailman/listinfo/python-list
