'join' in the wrong word for the method in class Thread.

castironpi at gmail.com castironpi at gmail.com
Sun Mar 16 07:35:49 CET 2008


On Mar 15, 9:28 pm, Benjamin <musiccomposit... at gmail.com> wrote:
> On Mar 15, 7:29 pm, castiro... at gmail.com wrote:> 'join' in the wrong word for the method in class Thread.
>
> > The agent-patient semantics of calling functions can get ambiguous.
> > It is not a problem of native Pythoners alone.  Is it due to lazy
> > programming, an inability of English (do you have it in other
> > languages?), or not a problem at all?
>
> This is what Java uses, and Python's threading module tries to imitate
> it.

If everybody's using join, then everybody's using join.  That by
itself doesn't constitute a case that the practice, the trend, is
either right or wrong.  Which is why I bring it up!

Upon some second thoughts, the OP (myself) could use a few more
examples... maybe even some parameters.  Maybe even a spell checker
(subject line).

> th1.join() -> 'be joined by th1'
> file1.close()-> 'close file1'
> lock1.wait()-> 'getinlinefor lock1'

One approach is to take a 'declarative' perspective: make them
statements instead of commands.

th1.join()
-> th1.joins()
file1.close()
-> file1.closes()
lock1.wait()
-> lock1.becomesfree()
htmlparser.reset()
-> htmlparser.resets()
htmlparser.feed( data )
-> htmlparser.eats( data )
pickle.dump( obj )
-> pickle.dumps( obj )
pickle.dumps( obj )
-> pickle.sdumps( obj )
socket.accept()
-> socket.accepts()

I tried once but got frustrated because the libraries wouldn't fit in.

lock1.becomesfree() is a fine example.  It's saying what happens in
that statement, which is a lot closer to what's actually going on--
because lock is doing exactly nothing until something else in some
other story line.  thread1.joins() similarly.

I do contend that names are hard to pick-- "one-worders" take
perspective and distance, which are pricey pricey-- and unfortunately
deadlines press and the existing ones come already to be used.  Of
course, Python version graduation is a fine time to make the change,
but I'm no good at asking politely-- the right people at the right
times and in the right ways.  A tool might be able to convert the
obvious cases automatically, and prompt the operator about any
residue.  He wouldn't necessarily even have to change overridden
methods by hand either!

Multi-control systems may have cause the rift.  Without them, 'do it'
is the same as 'it does it'.  With them, 'he does it' and 'you do it'
are different.  However the popularity of object-orientation may be
the culprit: not all of our instruction names made the jump right.
Maybe both.

Aside: The docs are heavily (-heavily-) in the patient (passive) voice
too: code.interact: "is passed", "is then run", "is discarded", as
well as alternate between declaration and command.  But -you- rewrite
them, Mr. Backseat Driver!  A lot of abbreviations 'recv', 'del',
'dir', and 'stat' can go.  I digress.

The language would be changing pretty deeply: returns, yields, passes,
dels, raises, breaks, continues, imports.  The 'returns' would even
move over: retval returns; object() returns; match returns (return
retval, return object(), return match).  Maybe there's a language out
there that understands!

The inconsistency is in the address of threads and synchro. objects:
The author changes audiences.  In th1.join(), he is not commanding his
audience to join th1.  Biggest problem.  It's like an implicit 'the
self thread' shows up from dreamworld or something.

th1.join( this_thread )
lock1.waitfor( a_goahead )
lock1.waitfor( someone_else_to_finish_up )

I'm not holding that the functions aren't defined.  I'm saying the
names are hastily chosen.

The join documentation doesn't use the word 'join'.  Event.wait
doesn't use wait, but Condition, os, and subprocess do.

"Event.wait( [timeout])

Block until the internal flag is true. If the internal flag is true on
entry, return immediately. Otherwise, block until another thread calls
set() to set the flag to true, or until the optional timeout occurs.
When the timeout argument is present and not None, it should be a
floating point number specifying a timeout for the operation in
seconds (or fractions thereof). "

Aside: The rage-against-the-machine/paranoia/conspiracy-theory side of
me tries to ascribe malice to the writers, saying "they" were
"holding" "me" "down" (referring to my nose, of course).  I know
better, but college was rough and the girlfriend pulled, so I don't
always catch it.  Cough.

My earlier use of 'lazy' may have been a bit pejorative.  It
insinuated the authors devoted time to Doritos over better names,
rather than just other names or even bugs.  I was in a different
setting then -and- on autopilot.  It proves my point, though.  Time is
scarce.

Help me ask the right way!



More information about the Python-list mailing list