[Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces)

[Steven D'Aprano]

On Tue, 25 Dec 2012 16:19:21 -0800, Rick Johnson wrote:

> On Tuesday, December 25, 2012 4:56:44 PM UTC-6, Steven D'Aprano wrote:
> 
>> Rick, what makes you think that this is logically inconsistent?
>> "Method" is the accepted name for functions attached to classes. They
>> report themselves as "methods":
>> [...]
>> There are two built-ins for creating different types of method: the
>> classmethod and staticmethod functions. If you don't think that these
>> objects should be called "<adjective> method", then what do you think
>> that they should be called?
> 
> I'm  not arguing about against instance method/class method name
> convention, i am talking about instance variable/class variable; pay
> attention!

You compared the use of "instance/class method" and "instance/class 
variable", and complained that it was "logically inconsistent" to use one 
set of terms while objecting to the other. That could mean that you 
object to *both* terms, or that you prefer both terms. You didn't say 
which, so I covered both options.

Since you apparently don't object to "instance/class method", I can only 
assume that you think that "class variable" is a good term for something 
which is not necessarily a class.


>> On the other hand, the terms "instance variable" and "class variable"
>> are logically inconsistent with other terminology. It is common
>> practice, across dozens or hundreds of languages, to refer to variables
>> by their type
> 
> Variable have no "type", only the value of variable has a "type".

That is incorrect in general. In statically typed languages, variables do 
have types: the compiler keeps track that (e.g.) variable named "x" is a 
float, while variable named "s" is a string.

That does not apply to Python, of course, but under normal circumstances 
many variables have an implied type, or types. Only a very few variables 
are used with unrestricted values. If I write a function:

def spam(alist):
    alist.sort()
    alist += [None, 'x', 42]
    

then most people would understand that calling alist "a list variable" 
gives the intent that alist should hold a list (or something that quacks 
like a list) rather than a statement that the compiler will prevent you 
from passing a non-list to the function.


>> (either as declared, in static-typed languages like C or Haskell, or as
>> they are expected to hold a value in dynamic languages like Ruby and
>> Python):
>>
>> - an integer variable is a variable used to hold an integer; 
>> - a string variable is a variable used to hold a string;
>> - a float variable is a variable used to hold a float; 
>> - a boolean variable is be a variable used to hold a boolean; 
>> - for consistency, a class variable should be a variable used to
>>   hold a class, e.g.:
>>   classes = [bool, float, MyClass, Spam, Ham, AnotherClass] 
>>   for cls in classes:  # cls is a "class variable"
>>       print "The name of the class is", cls.__name__
>> - and similarly for consistency an instance variable should be a
>>   variable holding some arbitrary instance. Since everything in an
>>   instance in Python, this last one is too general to be useful.
> 
> Your "last one"(sic) comment negates your whole argument of referring to
> variables by what type the variable references. Since EVERYTHING is an
> obj then ALL variables should be termed "instance variables" (that's
> going by your logic of course).

Of course you could do so, but that would be pointless. Normally we refer 
to things by the most precise term to describe them, not the least 
precise. We might say:

"42 is an int, 23.0 is a float, and 'spam' is a string"

rather than:

"42 is an instance, 23.0 is an instance, and 'spam' is an instance".

Although the second sentence is equally correct, it is not equally 
useful. Rather like saying:

"Lassie is a dog, Bozo is a chimpanzee, and Robin Hood is a person"

versus:

"Lassie is a mammal, Bozo is a mammal, and Robin Hood is a mammal".


>> Unfortunately people coming to Python from certain other languages,
>> particularly Java, (mis)use "class variable" to mean something
>> completely different:
> 
> Don't try to confuse us with your illogical ways, Lord Steven. Your sad
> devotion to that ancient hatred of java has not helped you conjure up
> logical terminology, or given you enough clairvoyance to find the
> truth...

Thank you Admiral Motti.


-- 
Steven