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

[Rick Johnson]

We all make mistakes, like my referring to class methods when I
meant instance methods.

This mistake reminded of how people in this group (maybe not you in particular) happily accept the terms "instance method" and "class method" HOWEVER if you _dare_ use the terms "instance variable" or "class variable" you get a swift rebuke.

Would anyone care for another serving of logically inconsistent py?

 

[Rick Johnson]

We all make mistakes, like my referring to class methods when I
meant instance methods.

This mistake reminded of how people in this group (maybe not you in particular) happily accept the terms "instance method" and "class method" HOWEVER if you _dare_ use the terms "instance variable" or "class variable" you get a swift rebuke.

Would anyone care for another serving of logically inconsistent py?

 

[Dennis Lee Bieber]

Hey I think I should rename the threads name into a new "Doc" project,
I'm sure It won't take much time to fill a book with our knowledge.

Thanks to Rick, you have Posted exactly what I wanted to ask. I know the that
__variable = 'xyz'
_variable = 'xyz'

are used to make them private, but I haven't found it for methods. Thanks

No... Single _ is a hint to the programmer using the name that it is
/considered/ "internal" and subject to change -- use at your own risk.

Double __ invokes name-mangling so that one does not conflict with a
parent class method (when one does NOT want to override the parent
class' method with the subclass method). It's a weird, seldom used,
situation.
.... def __something(self):
.... pass
.... def notsomething(self):
.... pass
........ def __something(self):
.... pass
.... def notsomething(self):
.... pass
....['_ABC__something', '_XYZ__something', '__class__', '__delattr__',
'__dict__', '__doc__', '__format__', '__getattribute__', '__hash__',
'__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'__weakref__', 'notsomething']
An instance of XYZ has two name-mangled __something methods, but
only one not mangled notsomething method.

Inside methods of XYZ, any use of __something will invoke
_XYZ__something -- but it is possible to explicitly invoke the parent
_ABC__something if needed.

 

[Dennis Lee Bieber]

This mistake reminded of how people in this group (maybe not you in particular) happily accept the terms "instance method" and "class method" HOWEVER if you _dare_ use the terms "instance variable" or "class variable" you get a swift rebuke.

Would anyone care for another serving of logically inconsistent py?

Only that many of us don't believe Python has /variables/, the use
of instance/class as a modifier is thereby moot.

An instance method is a method that works on an instance of the
class, whereas a class method is meant to work on the class as a
whole... I don't know of anyone arguing that Python does not have
"methods"...

 

[Steven D'Aprano]

This mistake reminded of how people in this group (maybe not you in
particular) happily accept the terms "instance method" and "class
method" HOWEVER if you _dare_ use the terms "instance variable" or
"class variable" you get a swift rebuke.

Would anyone care for another serving of logically inconsistent py?

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":

py> class Test(object):
.... def spam(self):
.... pass
....
py> Test().spam
<bound method Test.spam of <__main__.Test object at 0xb7bf528c>>

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?

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


Unfortunately people coming to Python from certain other languages,
particularly Java, (mis)use "class variable" to mean something completely
different:

- a class variable is a member attached to a class, and therefore
shared across all instances, what Python users usually call a
"class attribute";

- an instance variable is a member attached to an instance, and
therefore *not* shared across instances, what Python users usually
call an "instance attribute" or even just "attribute".


As I see it, it is not Python being inconsistent. What do you consider is
inconsistent by *avoiding* the use of "class variable" to mean an
attribute or member attached to a class?

 

[Rick Johnson]

Only that many of us don't believe Python has /variables/, the use
of instance/class as a modifier is thereby moot.

What IS a variable Dennis?
#
############################################################
# Variable (ComputerScience) #
############################################################
# In computer programming, a variable is a storage #
# location and an associated symbolic name (an identifier) #
# which contains some known or unknown quantity or #
# information, a value. The variable name is the usual way #
# to reference the stored value; this separation of name #
# and content allows the name to be used independently of #
# the exact information it represents. [...] The #
# identifier in computer source code can be bound to a #
# value during run time, and the value of the variable may #
# thus change during the course of program execution. #
############################################################
#
With that accurate definition in mind you can now understand how Python classes CAN and DO have variables, just as Python modules have variables; psst: they're called "global variables"!

Now, whilst i don't believe we should haphazardly re-define the definition of CS terms (or worse, re-invent the wheel by inventing new terms when perfectly good terms exist) I DO believe we should interpret these terms in their current context.

For instance, Python has no REAL "global variables", so we can happily refer to module level variables as global variables. However in many other languages (like Ruby for instance) we can declare REAL "global variables" that are known across all namespaces. And since Ruby also has modules which /themselves/ can contain variables, we would refer to "module level variables" as "module variables".

An instance method is a method that works on an instance of the
class, whereas a class method is meant to work on the class as a
whole

Allow me to use better terms:

An instance method is a method that is known to an
instance of the class only, whereas a class method is
known to all instances and accessible from the class
identifier

Now with that clear description in mind, apply it to variables:

An instance method is a method that is known to an
instance of the class only, whereas a class method is known
to all instances and accessible from the class identifier.

This transformation is without flaw because it is based on logic and not emotion.

...I don't know of anyone arguing that Python does not have
"methods".

Of course not because they would have to be insane. However, we should never adopt illogical terms just because a few folks cannot resolve the definition of the proper terms.

 

[Rick Johnson]

Only that many of us don't believe Python has /variables/, the use
of instance/class as a modifier is thereby moot.

What IS a variable Dennis?
#
############################################################
# Variable (ComputerScience) #
############################################################
# In computer programming, a variable is a storage #
# location and an associated symbolic name (an identifier) #
# which contains some known or unknown quantity or #
# information, a value. The variable name is the usual way #
# to reference the stored value; this separation of name #
# and content allows the name to be used independently of #
# the exact information it represents. [...] The #
# identifier in computer source code can be bound to a #
# value during run time, and the value of the variable may #
# thus change during the course of program execution. #
############################################################
#
With that accurate definition in mind you can now understand how Python classes CAN and DO have variables, just as Python modules have variables; psst: they're called "global variables"!

Now, whilst i don't believe we should haphazardly re-define the definition of CS terms (or worse, re-invent the wheel by inventing new terms when perfectly good terms exist) I DO believe we should interpret these terms in their current context.

For instance, Python has no REAL "global variables", so we can happily refer to module level variables as global variables. However in many other languages (like Ruby for instance) we can declare REAL "global variables" that are known across all namespaces. And since Ruby also has modules which /themselves/ can contain variables, we would refer to "module level variables" as "module variables".

An instance method is a method that works on an instance of the
class, whereas a class method is meant to work on the class as a
whole

Allow me to use better terms:

An instance method is a method that is known to an
instance of the class only, whereas a class method is
known to all instances and accessible from the class
identifier

Now with that clear description in mind, apply it to variables:

An instance method is a method that is known to an
instance of the class only, whereas a class method is known
to all instances and accessible from the class identifier.

This transformation is without flaw because it is based on logic and not emotion.

...I don't know of anyone arguing that Python does not have
"methods".

Of course not because they would have to be insane. However, we should never adopt illogical terms just because a few folks cannot resolve the definition of the proper terms.

 

[Rick Johnson]

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!

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

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

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

 

[alex23]

Python classes CAN and DO have variables, just as Python modules
have variables; psst: they're called "global variables"!

Actually, they're called "module attributes", but don't let the facts
get in the way of your little rant. You never have before.

 

[Steven D'Aprano]

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.

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

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.

 

[Michael Torrie]

With that accurate definition in mind you can now understand how
Python classes CAN and DO have variables, just as Python modules have
variables; psst: they're called "global variables"!

Nice ascii graphic, but citation needed. What CS text book are you
quoting from?

Now, whilst i don't believe we should haphazardly re-define the
definition of CS terms (or worse, re-invent the wheel by inventing
new terms when perfectly good terms exist) I DO believe we should
interpret these terms in their current context.

Good to have you back, Rick. I think. Sounds like you need to go back
and review your computer language theory CS class that you took in
University if you want to appeal to authority and definitions. I was
taught very clearly what Dennis articulated. We spent about 2 weeks
going over the difference between variables, names of variables,
binding, and passing. And implementing everything in Scheme. Good
days. And we reviewed that again in my computer algorithms class.

 

[Michael Torrie]

What IS a variable Dennis?
#
############################################################
# Variable (ComputerScience) #
############################################################

Found the reference you are quoting here. It's from wikipedia.

 

[Rick Johnson]

[snip]

I won't reply to your last post on a line-by-line basis because i feel we are straying from my general point: which is that we should NEVER re-interpret existing words (in an illogical manner) whilst transforming them into specific disciplines.

My specific point is that the English word "variable" is unambiguous and transforms smoothly to an abstract idea of an identifier referencing an object, and also, that the reference is "variable" (or has the ability to change). The word "variable" is a WONDERFUL example of transforming existing words into specific esoteric disciplines.

Alternatively, you want to argue that the word "attribute" is a better choice NOT because "variable" cannot transform to a programming context, BUT because you want use "variable" to reference some "attribute" of an object...*smile*..., oh i see.

But seriously,
What is an "attribute" anyway?

############################################################
# Define: Attribute #
############################################################
# Noun: A quality or feature regarded as a characteristic #
# or inherent part of someone or something. #
############################################################

Interesting. And what about "inherent"?

############################################################
# Define: Inherent #
############################################################
# Adjective: Existing in something as a permanent, #
# essential, or characteristic attribute #
############################################################

Ahh... so an "attribute" is attached to an entity (okay, we could easily transform the word "entity" to a memory object, but) ...that is "permanent" AND "essential"! OPPS! Here is where your logic breaks down. Variables COULDNOT be considered permanent: neither existentially or referentially. Please re-consider this illogical transformation of the word "attribute".

[Slightly Tangential Meanderings Ahead...]
Okay, now that we've ironed-out the wrinkles in our "variable" and we see how "variable" traverses perfectly into a computing context, i want to talk about how some of our most /ingrained/ syntax is NOT correct! Specifically i want to talk about "class" and "def".

The words "class" and "def" are HORRIBLE choices for defining "classes" (oops, i should say objects, but it seems the brainwashing has run it's coarse!) and "methods/functions". I know, I know, your gut reaction is to _cling_to what is familiar -- and these words have become FAR TOO familiar to all of us -- but again, let's do some introspection of these words we "THINK"we understand.

Ask yourself. What /is/ a class?

A class is nothing more than a textual template defined by the programmer for which Python reads and creates OBJECTS in memory. If instead of "class" we used the word "object" to define a (wait for it...) "object" we would NOT ONLY be consistent and logical, we would inject more intuitiveness into our language. Can you imagine the confusion a new programmer would feel whentold that he must use "classes" to create "objects" when the only definition of classes he understands is "classrooms" and "classifications".

So the correct syntax follows:

OBJECT Car(object):
def __init__(self)
#....

same goes for methods/functions

FUNCTION foo(args):
.... pass

Of course i would be open to "obj" and "func" respectively (well maybe). But i favor the following syntax for even more intuitive consistency:

define object Car(...):
define function foo(...):

That is a work of logical fine art!. However a new problem arises: "function" an illogical choice. "Procedure" would be the obvious choice, however, old school CS majors YET AGAIN redefined a word into illogic oblivion.

Some people think Python's syntax is great, and i must confess i am one of those people, but even after all of Guido's whining about the failures of ABC's syntax he then went on to commit the same crimes[1]

[1] to a far less degree of course .

 

[Steven D'Aprano]

My specific point is that the English word "variable" is unambiguous

I'm sorry, do you mean "variable" the noun, or "variable" the adjective?

If you mean the adjective, do you mean something which naturally changes,
in the sense that the amount of rainfall is naturally variable, or a
collection of independent things which individually are constant but
collectively vary, such as the heights of children in a classroom are
variable?

If you mean the noun, do you mean a factor which is likely to vary, as in
"the weather is one variable to consider", or a quantity that is capable
of taking on a multitude of values, or a symbol which represents a fixed
but unknown quantity?

If you're going to claim that an English word is unambiguous, you
probably should choose an example with only one meaning.

we should NEVER
re-interpret existing words (in an illogical manner) whilst transforming
them into specific disciplines.

I'm sorry yet again, did you mean "discipline" in the sense of
punishment, "discipline" in the sense of learning by instruction and
exercise, "discipline" in the sense of submission to authority, or
"discipline" in the sense of a field of study?


I am sorry[1] to ignore the main points of your post in favour of
attacking the very foundations of your argument, but if you build your
argument on counter-factuals (assumptions about English language which
are not, in fact, true) then even if your reasoning is utterly logical in
every step, the conclusion is still dubious.



[1] Ah who am I kidding?

 

[Ranting Rick]

My specific point is that the English word "variable" is unambiguous

I'm sorry, do you mean "variable" the noun, or "variable" the adjective?
[snip: sliding down the rabbit hole of a polysemantic nightmare...]

And now my dear friend you arrive at the horrible truth. The truth
that your language is defeating you. The truth that you dare not speak
because of the fear of unfamiliarity. You don't like that feeling, you
fear it, you prefer the warmth of clinging to a warm fuzzy something,
EVEN IF that something is a abomination.

So what do we do?

Well the obvious answer is to scrap the whole thing and start over.
Start with a system of word creation that is intelligently expandable
instead of what we have now which is a haphazard at best. Stringing
bits of Greek with bits of Latin may increase your social status at
the local chess club, but you are only injecting more garbage into the
system. The whole architecture is flawed. It's flawed in greek, it's
flawed in latin, and it's flawed in Python. You cannot create gold
from lead: "Polish a turd, it's still a turd!"

But short of re-inventing the English language ( heck, you people
won't even _admit_ to the inconsistencies in Python syntax, much less
commit to _repairing_ them!) the flaws in natural language cannot be
used as an excuse to inject illogic/inconsistency/multiplicity at your
whim. We should hold ourselves to a higher standard.

Every keyword, syntactical structure, style, etc, etc, should be based
on logical foundations; not adolescent fads or propagating more
idiotic cultural traditions. You piss and moan about language X and
how asinine the language is, them you go and repeat the same stupid
mistakes simply because you don't want to "rock the boat"?!

"""Well, urm, i don't particularly like "aspect x" about this
language, but most programmers have internalized the practice and i
don't want to confuse them with intelligent design, consistency or
logic, so i'll just propagate more of this stupidity so everyone can
feel warm and fuzzy."""

Well thanks Mr. language designer, now we'll be corralling braces for
another fifty FREAKING YEARS!

PS: Grow a pair!

 

[Chris Angelico]

Every keyword, syntactical structure, style, etc, etc, should be based
on logical foundations; not adolescent fads or propagating more
idiotic cultural traditions. You piss and moan about language X and
how asinine the language is, them you go and repeat the same stupid
mistakes simply because you don't want to "rock the boat"?!

Rick, ever heard of the ELIZA Effect?

ChrisA

 

[alex23]

Rick, ever heard of the ELIZA Effect?

Can we _please_ stop feeding this troll?