Coding standard: Prefixing variables to indicate datatype

[Daniel Dittmar]

Terry Reedy wrote:
> In the last paragraph of my post, which you clipped (I suspect without
> reading), I already acknowledged that you might have meant this and
I admit this and I'm sorry about it. From the quoting, it appeared to be 
a reply to a message further up the chain.

> 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().
> "

I'm of course referring to the smalltalk version of class methods, where 
every constructor (and join could be seen as a constructor) is a class 
method. But then smalltalk has no modules.

> 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.

You meant B, right? Not if B is only a helper parameter (and being 
optional in the string module version of join shows that it's just 
that). Just suppose that re.I would be an object of some class 
re.options and not an integer. Would you really argue that re.compile 
(pattern[, options]) should be transformed to re.I.compile (pattern)?

But let's stop this thread. It hasn't anything to do with the original 
post and it won't change anything in the Python implementation.

Daniel