using "private" parameters as static storage?

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Fri Nov 14 05:25:48 CET 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