Re: using "private" parameters as static storage?

[Joe Strout]

On Nov 13, 2008, at 10:19 AM, Chris Mellon wrote:

Static storage is a way of preserving state. Objects are a way of
encapsulating state and behavior. Use an object.

Argh. I've been back in the Python community for about a month, and
I've been continually amazed at how every single "how do I do X" or
"what do you think of this method of doing X" question is answered by
people on high horses claiming "you shouldn't do X".

I know very well about state and objects. I'll be happy to whip out
my software engineering credentials and measure them against yours if
that's how you like to play. I understand very well when data should
be stored as instance data, and when it should be instead tucked away
as static data within a method. If you don't understand that, or are
happy without having the choice, and have no answer to the question I
was asking, then that's fine. I don't always have anything useful to
contribute when somebody asks a question either. But in that case, I
resist the urge to reply anyway.

Maybe we should define some standard tags people could add to the top
of their email: "Helpful-Answer" for helpful answers, and "Unhelpful-
Preaching" for the other kind. Then those of us not interested in one
sort or the other could set up an email filter.

Best,
- Joe

P.S. I'm sorry, Chris, I don't mean to rip your head off in
particular. You were just the straw that broke the camels back; there
have been plenty of others adding to the frustration. I'll try to
just ignore such responses in the future... though it is a little
disturbing to think how many newbies are probably driven away by this
sort of thing.

[Ben Finney]

Re: using "private&q uot; parameters as static storage?

Joe Strout <joe@strout.net writes:

On Nov 13, 2008, at 10:19 AM, Chris Mellon wrote:
>

Static storage is a way of preserving state. Objects are a way of
encapsulating state and behavior. Use an object.

>
Argh. I've been back in the Python community for about a month, and
I've been continually amazed at how every single "how do I do X" or
"what do you think of this method of doing X" question is answered
by people on high horses claiming "you shouldn't do X".

You seem to be reading the responses differently from me. I don't see
that the above response fits the pattern you describe at all.

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.

--
\ “Why, I'd horse-whip you if I had a horse.” —Groucho Marx |
`\ |
_o__) |
Ben Finney

[alex23]

Re: using &quot;private&q uot; parameters as static storage?

On Nov 14, 12:16 pm, Joe Strout <j...@strout.ne twrote:

Argh.  I've been back in the Python community for about a month, and  
I've been continually amazed at how every single "how do I do X" or  
"what do you think of this method of doing X" question is answered by  
people on high horses claiming "you shouldn't do X".

If someone asked you how to hammer together a cabinet with a saw,
wouldn't -you- respond with "don't use a saw"?

Suggesting the right tool for the job is hardly getting on a high
horse...

[Steven D'Aprano]

Re: using &quot;private&q uot; parameters as static storage?

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 characterizatio n 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_a rgs, _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

[Steven D'Aprano]

Re: using &quot;private&q uot; parameters as static storage?

On Thu, 13 Nov 2008 18:57:37 -0800, alex23 wrote:

On Nov 14, 12:16 pm, Joe Strout <j...@strout.ne twrote:

>Argh.  I've been back in the Python community for about a month, and
>I've been continually amazed at how every single "how do I do X" or
>"what do you think of this method of doing X" question is answered by
>people on high horses claiming "you shouldn't do X".

>
If someone asked you how to hammer together a cabinet with a saw,
wouldn't -you- respond with "don't use a saw"?
>
Suggesting the right tool for the job is hardly getting on a high
horse...

If somebody asked me how to hammer together a cabinet with a regular
carpenter's hammer, and I answered "Don't do that, anything less than an
object-oriented Uber-Hammer is wrong", then they might be justified in
thinking that I was full of it, particularly if I was unable to explain
just why using a regular hammer was harmful.



--
Steven

[Aaron Brady]

Re: using &quot;private&q uot; parameters as static storage?

On Nov 13, 10:25 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

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 characterizatio n 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_a rgs, _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.

Does it follow that variables should be exposed too to those who need
it, e.g. for testing?

If anyone has a *reason* why this idiom is harmful, please say so.

Or forever hold his peace?

I've alluded to them before. The reasons are *NOT STRONG*. They are
mild, and do not (*NOT*) constitute a conclusive case. (Not.) The
idiom is not harmful, but here is what whatever case there is against
it is.

1. It's an argument list, not an argument-and-static-variable list.
2. Mistakes by the caller.
3. BIG gotcha.
4. Not obvious from the syntax. Much of Python is; this isn't, it's
arbitrarily assigned.
5. Arnaud's 'static' decorator nearly as convenient and much clearer.
6. Signature can get really long with a few arguments and a few
statics. Split into two statements, one being a decorator.

Even combined, these don't warrant the effort to remove the feature.

P.S. At least it's not globals! Ha ha ha.