frozendict (v0.1)
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Fri Oct 8 13:09:15 EDT 2010
On Fri, 08 Oct 2010 12:10:50 +0000, kj wrote:
> In <4cae667c$0$29993$c3e8da3$5496439d at news.astraweb.com> Steven D'Aprano
> <steve at REMOVE-THIS-cybersource.com.au> writes:
>
>>On Fri, 08 Oct 2010 00:23:30 +0000, kj wrote:
>
>>Because it's always better to use a well-written, fast, efficient,
>>correct, well-tested wheel than to invent your own slow, incorrect wheel
>>:)
>
> IOW, "don't you worry your little head about why."
Shame on you for deleting the context of my answer.
You said:
"I imagine that frozenset is better than sorted(tuple(...)) here, but
it's not obvious to me why."
Because frozenset already works. Because somebody else has done the work,
and debugged it, and tested it, and profiled it, and optimized it, and
ensured that it is correct and fast. That saves you a lot of effort, and
frees you from having to duplicate the same functionality, and debugging
it, testing it, profiling it, and optimizing it. Every line of code that
you can avoid writing is a win.
If you're a carpenter, it is better to buy a hammer than it is to go out
and dig up your own iron ore, smelt the metal, and forge it into a
hammer: unless you're in the business of making hammers, you've got
better things to do with your time. And if you're a programmer, you've
got better things to do than write a slower, buggier version of code that
already exists.
If you want to know *what* the frozenset does that is better, then go
read the source code. For all I know you might discover that it does the
same thing as your code. It's *still* better to use frozenset, simply
because it already exists. Unless you profile your code and discover that
frozenset is too slow and you can do better, there is no reason not to
use it, and many reasons to use it.
This has nothing to do with "your little head", but about code reuse.
Almost the entire history of programming, from the invention of sub-
routines to the open source movement, is about code reuse.
--
Steven
More information about the Python-list
mailing list