Coding standard: Prefixing variables to indicate datatype

[Terry Reedy]

> > Terry Reedy wrote:
> >>Once you actually think about it, its obvious that attaching the
join
> >>method to the joiner is the only sensible place to put it.
> >>
> >>"Carpenter, exercise your ability to joins these pieces of wood."

> Erik Max Francis wrote:
> > Agreed.  It may look weird at first, but it doesn't take long to
realize
> > as a method, that's the only place it can logically go.  After
all, the
> > alternative is having a join method be part of _every single
sequence
> > interface_, which is clearly heavy-handed.

"Daniel Dittmar" <daniel at dittmar.net> wrote in message
> Now that there are class methods, there's no longer the need to
force
> this into a instance method call. str.join (somelist [, joinstring])
> does the job just fine.

Nope.
str.join is *not* a class method.  (If it were, joiner.join(seq) would
not work!).  While not identified as 'unbound', it acts like a normal
instance methods.  So you have the parameter order backwards.

>>> '..'.join('abc')
'a..b..c'
>>> str.join('..', 'abc')
'a..b..c'
# Not '.abc.' as you claimed

*Every* instance method can be invoked like this, via the class, with
the instance given as an explicit first parameter.  While occasionally
useful  -- to get at a method that is masked by inheritance, or
explain why 'self' should be explicit -- it seems awkward for routine
use.

However, I do not care too much if people with joiner.join phobia make
an exception for this particular method and write the extra chars for
the circumlocution -- as long as they don't push the awkward usage on
me or advocate it to newcomers.  The point of my original post was to
oppose the notion that join should be a method of lists -- which
proposal ignores the two facts that not all lists can be joined, and
that any string sequence, not justs lists, can be joined.

If the quote above is a another suggestion -- that .join could (or
should) be or have been turned into a class method instead of an
instance method, then I oppose this also.  Every method *could* be
turned in a 'class' method.  (Or we could get rid of the
instance.method syntax entirely and always use the class.meth(inst)
alternative.)  However, this violates the whole notion of a class
method -- which is a method that operates on or with a class and it
attributes instead of any particular instance.  This does not, not,
not apply to .join.  The purpose of adding explicit class methods was
to avoid the circumlocation of writing a class method as an instance
method called with an arbitrary instance that is then ignored except
for using it to get at the class that should have been the self param
in the first place, instead of the instance.  Again, this has nothing
to do with .join().

Terry J. Reedy