No 1.6! (was Re: A REALLY COOL PYTHON FEATURE:)

[Martijn Faassen]

Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> m.faassen at vet.uu.nl (Martijn Faassen) writes:

>>   I sit on the chair
>         .
>>   chair.sit() 

> Hmm.  This is not the way I think of it.  I would never say
> chair.sit() ... more like, 

> "Bob, sit on the chair."

> bob.sit(chair)

> After all, who's doing the work here; bob, or the chair?

Depends on how you're modelling. In many muds for instance, the 
world objects determine what's possible with them, not the players.
The player issues some commands and the player object knows just
enough to be able to pipe it to the world objects (which then can
query the player. So more like:

  chair.sit(bob)

Though that does look a bit odd. :)
 
  chair.be_sat_on_by(bob)

>> Similarly:
>> 
>>   I append to the list

> I tend not to think of things as so person-focused ;-).  *I* will
> append nothing to the list; I am merely telling the list what it shall
> do.  I plan to be somewhere else entirely when this program is
> running.

You're just as person-focused as I am. I just happend to be in a first-person
mood while you're in a third-person mood. I frequently think things
like: 

  'here I am adding these two numbers but the output is wrong..weird'

when really the computer is doing the adding.

>>   list.append()

> So what "list.append(element)" says to me is, "List, append
> element. (to yourself, of course)"

Sure, perhaps I should rewrite 'I append to the list' to something like:

I tell the list to append another element to it.

>>   I draw on a paper with a blue color
>> 
>>   paper.draw(color='blue')

> This doesn't make sense either.  For me it would be:

> pen.paper=paper
> pen.draw(color='blue')

> "Pen, you're going to be drawing on that piece of paper.  Draw in
> blue."

Depends on how you're modelling. Let's do this then:

  display.fill(color='blue')

The 'pen' metaphor does often work better if you're going to draw
lines and such.

>> In the case of 'foo'.join() this stops making sense:
>> 
>>   I join the list of strings with spaces.
>> 
>>   ' '.join(list)

>> In this case, it feels obvious to us that the *list* is the big target,
>> and the space is what we're joining with. We don't think:
> [snip]

> Finally, this makes sense to me, becuase what I'm saying is;

> "' ' (which we all know to be a string), join list together".  Being a
> programming language, "tell me what the result is" is implicit =).

Interesting. Would you like the arguments to string.join() to be reversed
as well then? As usually we map the first argument in functions to 'self'
in objects. In Python this is extremely explicit. The string.join() 
function therefore feels like it should be translated to something like
list.join(), as the first argument is a list. i.e.:

  list, join yourself together (with a space)

The equivalent in your pen example would seem to be:

  blue.draw(paper)

and that doesn't seem to be encountered often. Though this is more
common:

  pen = Pen(color=blue)
  pen.draw(paper)

>> lots-of-instinctive-language-analysis-ly yours,

> my-intuition-is-nonintuitive-ly y'rs,

I suppose it all has to do with refactoring; on which object we should
place our methods, and so on. In programming we sometimes tend to move methods
around a bit until they settle; we change our minds about what the central
actors are and what are just arguments. In the list example, some people
just don't seem to feel that the string is being the central actor. I think
there's also the tension with .split(), i.e:

   "foo bar baz".split(" ")

Which would be:

   string, split yourself (on spaces)

Or is it this in 1.6?

  " ".split("foo bar baz")

That would be the equivalent with the join() case, right? 

  space, split this string.

downloads-tarball-compiles-tests-no-its-the-former-ly yours,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?