using "private" parameters as static storage?
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Thu Nov 13 23:25:48 EST 2008
On Fri, 14 Nov 2008 13:35:02 +1100, Ben Finney wrote:
> Instead, it looks like you're falling foul of one of the classic
> mistakes in the “How to ask questions the smart way” document: you've
> got a goal, but you're assuming that you need to use a specific tool to
> get there. Instead, you're being shown that your assumption is false:
> there's a better tool available to achieve your goal.
For the sake of the argument I will accept your characterization of Joe's
question. Even given that, you have still made an error: Joe hasn't been
shown that his assumption is wrong, he's merely had a bunch of people
declare, without evidence or even reason, that he is wrong. If anyone has
given any reason for avoiding the idiom that doesn't boil down to "I
don't like it!" (I need a smiley for pursed lips), I haven't read it.
I for one do not think he is wrong, and I have given reasons for
preferring the idiom:
def parrot(public_args, _cache={}) # or similar
for implementing caches and similar internal storage. It's quick, it's
easy, it's lightweight, and it exposes the cache to those who need it,
e.g. for testing.
If anyone has a *reason* why this idiom is harmful, please say so.
Repeating "That's not the way to do it!!! Use an object!!!" is not a
reason.
Without such a reason, then the decision whether or not to use a functor
(class with a __call__ method) in Python is a matter of personal taste.
--
Steven
More information about the Python-list
mailing list