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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to