[Tutor] class method problem

[David Hutto]

On Sun, Sep 26, 2010 at 3:14 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, 26 Sep 2010 02:26:25 pm David Hutto wrote:
>> On Sat, Sep 25, 2010 at 9:16 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> > On Sun, 26 Sep 2010 08:13:23 am David Hutto wrote:
>> >> Since I had nothing else to do, but practice, this looks much
>> >> better:
>> >>
>> >> def find(word, search):
>> >>       if search in word:
>> >>               print True
>> >>       else:
>> >>               print False
> [...]
>> OP wanted to find if a in b. Does my function do that?...Yep
>
> I didn't say that the function did the wrong thing, I said the name was
> misleading for what it actually did.
>
> Why didn't you call the function len(), or deleteItemsFromPage()?
> Because those names would be misleading, deceptive and silly. And so is
> calling a function find() when it does something completely different
> from the commonly understood meaning of the word "find".



>
> When you find something, you know where it is afterwards.

Find to me, in the since of the OP's question means a hit. It was found in
the furtherence into where, is up to the OP and their next question on the list
that says now that I know it's there, where is it?

In the context
> of text searches, that means returning an offset to where the target is
> found, or something similar. That's what str.find() does, and regular
> expressions, and list.index(). Your "find" function is a membership
> test, which is what the `in` operator is for.

And I'm sure that with google, and my trust Building Skills in Python
Manual at my side, I would have found those string/list functions, and overtime
so will the OP, just as did at one point Mr. Miyagi.

>
>
>
>
>> >    Yes, we found your terms on the Internet, but we won't tell you
>> >    where. If you would like to find something else, we won't tell
>> >    you where that is either.
>>
>> It's not supposed to be a four line version of Google.
>
> I didn't say it was. I tried to inject a little humour into the email,
> but it clearly didn't work.

It did work, so I injected a little sarcasm back.

>
>
> [...]
>> > Even this is slightly misleading, because "text" doesn't need to be
>> > an actual string. It could be any sequence, such as a list.

I know this from a brief exercise I was working on before, but when
learning, you can
just give everything at once and expect it to be absorbed, you have to
practive with the different types you can manipulate, but knowing what
they are is helpful.

But
>> > this gives the *intention* of the function, which is to do text
>> > searches. So this is (in my opinion) an acceptable compromise
>> > between intention and generality.
>>
>> Semantics, are only important to those who didn't write it.
>
> "Semantics" means "meaning". If you are trying to tell me that the
> meaning of programs -- their *purpose* -- is unimportant, that it
> doesn't matter what a function does, I'm afraid you'll have your work
> cut out to convince me.

I meant if it's a small function that you might use once in a blue moon,
and you know what it does for you, and since you wrote this small
function, you're able to
tell exactly what it does, and then it does this task as expected for
you, then ok.

If I was working with someone else on it, then I'm sure, they would suggest,
that we use overlapping terminology we could agree on for the code at hand.
(it would probably require a meeting or something.)


>
> The most important reader of your functions is... you. The function
> might be fresh in your mind *today*, but tomorrow? Next week? Six
> months from now when you discover a bug in your program and are trying
> to remember how it works so you can fix it?

It's five lines long.

>
> Trust me, any non-trivial program that you don't just use once and throw
> away needs to be written with a careful eye to naming functions and
> arguments. The ideal is that you should never need to write
> documentation, because the functions and arguments document themselves.
> (This is an ideal that never quite works in practice, but we can at
> least *try*.)

and I do.

>
> An excellent piece of advice I've been given is to write your program's
> API -- the names of functions, the calling signatures, and so forth --
> as if the next person to maintain that code will be a psychopath with a
> hair-trigger temper and a gun and who knows where you live. Since the
> next person to maintain it will likely be you, you will save *much*
> more time in the future by careful and consistent naming than it costs
> to think of those names right now.

Your comments are in the suggestion box, and you'll be happy to know, I even
take advice from my critics...when it suits me.

>
>
>
> --
> Steven D'Aprano
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>

David Hutto