This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steven.daprano
Recipients agthorr, belopolsky, christian.heimes, gregory.p.smith, mark.dickinson, pitrou, ronaldoussoren, steven.daprano, stutzbach, tshepang, vajrasky
Date 2013-08-05.18:14:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <51FFEB73.7060803@pearwood.info>
In-reply-to <1375722502.04.0.658900088022.issue18606@psf.upfronthosting.co.za>
Content
On 06/08/13 03:08, Mark Dickinson wrote:
>
> I too find the use of a class that'll never be instantiated peculiar.

I'll accept "unusual", but not "peculiar". It's an obvious extension to classes being first-class objects. We use classes as objects very frequently, we call methods on classes directly (e.g. int.fromhex). This is just a trivial variation where I am using a class-as-object as a function.

But if this is really going to be a sticking point, I can avoid using a class. I'll make median a plain function. Will that be acceptable?

> As you say, there's no state to be stored.  So why not simply have separate functions `median`, `median_low`, `median_high`, `median_grouped`, etc.?

Why have a pseudo-namespace median_* when we could have a real namespace median.* ?

I discussed my reasons for this here:
http://mail.python.org/pipermail/python-ideas/2013-August/022612.html
History
Date User Action Args
2013-08-05 18:14:23steven.dapranosetrecipients: + steven.daprano, gregory.p.smith, ronaldoussoren, mark.dickinson, belopolsky, pitrou, agthorr, christian.heimes, stutzbach, tshepang, vajrasky
2013-08-05 18:14:23steven.dapranolinkissue18606 messages
2013-08-05 18:14:23steven.dapranocreate