On 16/08/13 04:24, R. David Murray wrote: > I too prefer the median_low naming rather than median.low. I'm not > sure I can articulate why, but certainly the fact that that latter > isn't used anywhere else in the stdlib that I can think of is > probably a lot of it:) And the reason it's not used in the stdlib is because whenever somebody proposes doing so, python-dev says "but it's never been used in the stdlib before". *wink* > Perhaps the underlying thought is that we don't use classes pure > function namespaces: we expect classes to be something more than > that. To be perfectly frank, I agree! Using a class is not my first preference, and I'm suspicious of singletons, but classes and instances are the only flexible namespace type we have short of modules and packages. We have nothing like C++ namespaces. (I have some ideas about that, but they are experimental and utterly not appropriate for first-time use in a std lib module.) Considering how long the namespaces line has been part of the Zen, Python is surprisingly inflexible when it comes to namespaces. There are classes, and modules, and nothing in-between. A separate module for median is too much. There's only four functions. If there were a dozen such functions, I'd push them out into a module, but using a full-blown package structure just for the sake of median is overkill. It is possible to construct a module object on the fly, but I expect that would be even less welcome than a class, and besides, modules aren't callable, which leads to such ugly and error-prone constructions as datetime.datetime and friends. I won't impose "median.median" or "median.regular" on anyone :-) Anyway, this is my last defence of median.low() and friends. If consensus is still against it, I'll use underscores. (I will add a section in the PEP about it, one way or the other.) -- Steven