On 16/08/13 04:10, Eric V. Smith wrote:
I agree with Mark: the proposed median, median.low, etc., doesn't feel
right. Is there any example of doing this in the stdlib?
The most obvious case is datetime: we have datetime(), and datetime.now(),
datetime.today(), and datetime.strftime(). The only API difference between it
and median is that datetime is a type and median is not, but that's a
difference that makes no difference: both are callables, and being a type is an
implementation detail. dict used to be a function that returned a type. Now it
is a type. Implementation detail.
Even builtins do this: dict() and dict.fromkeys(), for example. If you include
unbound methods, nearly every type in Python uses the callable(),
callable.method() API. I am truly perplexed by the opposition to the median
API. It's a trivially small difference to a pattern you find everywhere.
If we do end up keeping it, simpler than the callable singleton is:
def median(): return 'median'
...
def _median_low(): return 'median.low'
...
median.low = _median_low
del _median_low
median()
'median'
median.low()
'median.low'
That is the implementation I currently have. Alexander has convinced me that
attaching functions to functions in this way is sub-optimal, because
help(median) doesn't notice the attributes, so I'm ruling this implementation
out.
My preference is to make median a singleton instance with a __call__ method,
and the other flavours regular methods. Although I don't like polluting the
global namespace with an unnecessary class that will only be instantiated once,
if it helps I can do this:
class _Median:
def __call__(self, data): ...
def low(self, data): ...
median = _Median()
If that standard OOP design is unacceptable, I will swap the dots for
underscores, but I won't like it.
--
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
