Coding standard: Prefixing variables to indicate datatype

[Terry Reedy]

"Daniel Dittmar" <daniel at dittmar.net> wrote in message
news:b0cptv$857$1 at news.eusc.inter.net...
> Terry Reedy wrote:
> > "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.
>
> I meant it *should* be a class method with str being the class, join
> being the method and somelist and joinstring being the arguments.

In the last paragraph of my post, which you clipped (I suspect without
reading), I already acknowledged that you might have meant this and
explained that it is illogical (inconsistent with the meaning of
'class method') and therefore a bad idea (ie, would create a warty
inconsistency):
"
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().
"
To paraphrase the above: in Python, instance methods take an instance
as a parameter, while class methods get a class instead of an
instance.  Join() must get a string instance and has no use for the
string class.  It therefore *is* an instance method and *is not* a
class method.  If we were to mislabel .join, we could and might as
well do the same for any and every other instance method.

My argument assumes and is based on the following two principles:

1. If a function has two parameters, A and B, and A is any member of
one particular type/class, while B is a member of restricted subsets
of several different types and classes, including user-defined classes
with the proper behavior, and if the function is to be made into a
method, then it is and should be an instance method of the class of A.

2. Consistency is good.

Terry J. Reedy