Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #35352 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 02:59 -0800
    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Peter Otten <__peter__@web.de> - 2012-12-22 12:43 +0100
      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 04:38 -0800
        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Peter Otten <__peter__@web.de> - 2012-12-22 14:54 +0100
          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 08:36 -0800
          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 08:36 -0800
      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 04:38 -0800
        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 04:45 -0800
          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Terry Reedy <tjreedy@udel.edu> - 2012-12-22 16:30 -0500
        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 04:45 -0800
          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Alexander Blinne <news@blinne.net> - 2012-12-22 18:26 +0100
            Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 10:10 -0800
              Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Alexander Blinne <news@blinne.net> - 2012-12-22 20:29 +0100
                Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-22 12:43 -0800
                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Alexander Blinne <news@blinne.net> - 2012-12-22 22:59 +0100
                    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-23 01:32 -0800
                      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Terry Reedy <tjreedy@udel.edu> - 2012-12-23 20:53 -0500
                    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Alexander Blinne <news@blinne.net> - 2012-12-24 14:10 +0100
                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dave Angel <d@davea.name> - 2012-12-22 17:03 -0500
                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Cameron Simpson <cs@zip.com.au> - 2012-12-23 21:55 +1100
                    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-23 12:59 -0800
                      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Peter Otten <__peter__@web.de> - 2012-12-23 22:14 +0100
                    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-23 12:59 -0800
                      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Roy Smith <roy@panix.com> - 2012-12-23 16:15 -0500
                        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-23 13:42 -0800
                          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2012-12-23 23:38 +0000
                          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-12-24 00:01 -0500
                          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Thomas Bach <thbach@students.uni-mainz.de> - 2012-12-24 06:18 +0100
                          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dave Angel <d@davea.name> - 2012-12-24 00:19 -0500
                            Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-24 00:23 -0800
                              Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Cameron Simpson <cs@zip.com.au> - 2012-12-24 21:32 +1100
                              Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dave Angel <d@davea.name> - 2012-12-24 10:48 -0500
                                Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Ranting Rick <rantingrickjohnson@gmail.com> - 2012-12-24 21:10 -0800
                                  Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-25 04:55 -0800
                                    Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-12-25 16:04 -0500
                              Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dave Angel <d@davea.name> - 2012-12-24 11:47 -0500
                              Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dave Angel <d@davea.name> - 2012-12-24 18:09 -0500
                            Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-24 00:23 -0800
                            Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-25 13:44 +0000
                              Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-25 06:41 -0800
                                Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dave Angel <d@davea.name> - 2012-12-25 12:10 -0500
                                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-25 09:31 -0800
                                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-25 09:31 -0800
                                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Rick Johnson <rantingrickjohnson@gmail.com> - 2012-12-25 12:16 -0800
                                    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-12-25 16:08 -0500
                                      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Rick Johnson <rantingrickjohnson@gmail.com> - 2012-12-25 15:42 -0800
                                        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Michael Torrie <torriem@gmail.com> - 2012-12-26 12:20 -0700
                                        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Michael Torrie <torriem@gmail.com> - 2012-12-26 11:58 -0700
                                      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Rick Johnson <rantingrickjohnson@gmail.com> - 2012-12-25 15:42 -0800
                                        Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) alex23 <wuwei23@gmail.com> - 2012-12-25 19:18 -0800
                                  Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Rick Johnson <rantingrickjohnson@gmail.com> - 2012-12-25 12:16 -0800
                                    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-25 22:56 +0000
                                      Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Rick Johnson <rantingrickjohnson@gmail.com> - 2012-12-25 16:19 -0800
                                        Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-26 08:29 +0000
                                          Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Rick Johnson <rantingrickjohnson@gmail.com> - 2012-12-26 20:07 -0800
                                            Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-27 05:02 +0000
                                              Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Ranting Rick <rantingrickjohnson@gmail.com> - 2012-12-26 22:50 -0800
                                                Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) Chris Angelico <rosuav@gmail.com> - 2012-12-27 23:58 +1100
                                                  Re: Require help migrating from Perl to Python 2.7 (namespaces) alex23 <wuwei23@gmail.com> - 2012-12-27 05:25 -0800
    Re: [Help] [Newbie] Require help migrating from Perl to Python 2.7 (namespaces) prilisauer@googlemail.com - 2012-12-23 01:36 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#35490

On 12/25/2012 09:41 AM, prilisauer@googlemail.com wrote:
> Hello Steven,
>
> to "learn python" I've bought a book, and it's not a "thin" one :-) it's more a 788p. long documentation about python.
>
> BUT!!!!! I have to say: The autor started using the "self." argument at the chapter classes. So You've shown me the book descr. non "correct" way. Better using this book heating my home?! :-)
>
> Patrick

You still are being imprecise.  You don't give a title or author, and
you refer to the "chapter classes" whatever that is.  Do you mean the
chapter about classes?  If so, that's exactly where 'self' should be
introduced.

How about copying an example function that uses self, that you think is
incorrect ?  If it is incorrect, perhaps we should give the author some
feedback.

We all make mistakes, like my referring to class methods when I meant
instance methods.  But I didn't figure it was time to introduce class
methods, so I wasn't trying to make the distinction.  My error.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#35491

By the way i haven't add the Title because it's a german only book named
"Python 3: Das umfangreiche Handbuch, Published by Galileo Computing" 

and also, because I've registered to first check if the Autor has allready published a update. Too many information's could ocurre in an avalanche 

I see a big failure:

1. I answer to quick

[toc] | [prev] | [next] | [standalone]

#35492

By the way i haven't add the Title because it's a german only book named
"Python 3: Das umfangreiche Handbuch, Published by Galileo Computing" 

and also, because I've registered to first check if the Autor has allready published a update. Too many information's could ocurre in an avalanche 

I see a big failure:

1. I answer to quick

[toc] | [prev] | [next] | [standalone]

#35495

On Tuesday, December 25, 2012 11:10:49 AM UTC-6, Dave Angel wrote:

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

[toc] | [prev] | [next] | [standalone]

#35498

On Tue, 25 Dec 2012 12:16:16 -0800 (PST), Rick Johnson
<rantingrickjohnson@gmail.com> declaimed the following in
gmane.comp.python.general:

> On Tuesday, December 25, 2012 11:10:49 AM UTC-6, Dave Angel wrote:
> 
> > 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? 

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

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#35500

On Tuesday, December 25, 2012 3:08:21 PM UTC-6, Dennis Lee Bieber wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#35537

On 12/25/2012 04:42 PM, Rick Johnson wrote:
> What IS a variable Dennis?
> #
> ############################################################
> #                Variable (ComputerScience)                #
> ############################################################

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

[toc] | [prev] | [next] | [standalone]

#35538

On 12/25/2012 04:42 PM, Rick Johnson wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#35501

On Tuesday, December 25, 2012 3:08:21 PM UTC-6, Dennis Lee Bieber wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#35508 — Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces)

On 26 Dec, 09:42, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#35496

On Tuesday, December 25, 2012 11:10:49 AM UTC-6, Dave Angel wrote:

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

[toc] | [prev] | [next] | [standalone]

#35499

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

> On Tuesday, December 25, 2012 11:10:49 AM UTC-6, Dave Angel wrote:
> 
>> 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, 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?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#35503

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!

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

[toc] | [prev] | [next] | [standalone]

#35518

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

[toc] | [prev] | [next] | [standalone]

#35570

On Wednesday, December 26, 2012 2:29:13 AM UTC-6, Steven D'Aprano wrote:
> [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 COULD NOT 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 when told 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 :-).

[toc] | [prev] | [next] | [standalone]

#35575

On Wed, 26 Dec 2012 20:07:53 -0800, Rick Johnson wrote:

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

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#35586 — Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces)

On Dec 26, 11:02 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 26 Dec 2012 20:07:53 -0800, Rick Johnson wrote:
> > 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!

[toc] | [prev] | [next] | [standalone]

#35614 — Re: [Newbie] Require help migrating from Perl to Python 2.7 (namespaces)

On Thu, Dec 27, 2012 at 5:50 PM, Ranting Rick
<rantingrickjohnson@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#35619 — Re: Require help migrating from Perl to Python 2.7 (namespaces)

On 27 Dec, 22:58, Chris Angelico <ros...@gmail.com> wrote:
> Rick, ever heard of the ELIZA Effect?

Can we _please_ stop feeding this troll?

[toc] | [prev] | [next] | [standalone]

#35403

secondly, it is absolutely not bad meaned, but, why does people post, their personal meaning, but nothing about the "Posters" Problem?

Everybody is free to read or not, but correcting the WWW could became a very very big task, (maybe it's easier to climb the 7 summits)

Best Regards.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web