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

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

Objects in Python

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

Contents

  Objects in Python shaun <shaun.wiseman91@gmail.com> - 2012-08-22 07:13 -0700
    Re: Objects in Python Joel Goldstick <joel.goldstick@gmail.com> - 2012-08-22 10:31 -0400
    Re: Objects in Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-08-22 17:31 +0300
    Re: Objects in Python Peter Otten <__peter__@web.de> - 2012-08-22 16:36 +0200
    Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 15:59 +0100
      Re: Objects in Python MRAB <python@mrabarnett.plus.com> - 2012-08-22 16:58 +0100
        Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 17:10 +0100
          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 17:30 +0100
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 18:06 +0100
              Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 19:07 +0100
                Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 20:13 +0100
      Re: Objects in Python Terry Reedy <tjreedy@udel.edu> - 2012-08-22 13:01 -0400
        Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 18:46 +0100
          Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-22 12:15 -0600
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 20:03 +0100
              Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 12:02 +1000
                Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:11 +0000
                  Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 15:26 +1000
                  Re: Objects in Python Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-08-23 20:02 +0200
                    Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-23 12:17 -0600
                      Re: Objects in Python Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-08-23 22:43 +0200
                    Re: Objects in Python 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 23:14 -0700
          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 19:23 +0100
          Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-22 14:03 -0500
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 20:45 +0100
              Re: Objects in Python MRAB <python@mrabarnett.plus.com> - 2012-08-22 21:31 +0100
              Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 21:46 +0100
                Methods versus functions [was Re: Objects in Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:07 +0000
              Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-22 16:31 -0500
                Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 10:19 +0100
                  Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-23 11:44 -0500
                    Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 18:56 +0100
          Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-23 09:58 +1000
            Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-22 18:10 -0600
            Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-22 23:49 -0500
              Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 06:55 +0000
                Re: Objects in Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-08-23 11:59 +0300
                  Re: Objects in Python MRAB <python@mrabarnett.plus.com> - 2012-08-23 12:28 +0100
                  Re: Objects in Python Jerry Hill <malaclypse2@gmail.com> - 2012-08-23 10:43 -0400
                  Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-23 12:17 -0500
                    Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 17:56 +0000
                      Variables vs names [was: Objects in Python] Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-23 14:22 -0500
                        Re: Variables vs names Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 10:02 +1000
                        Re: Variables vs names [was: Objects in Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-25 02:05 +0000
                          Re: Variables vs names Ben Finney <ben+python@benfinney.id.au> - 2012-08-25 15:24 +1000
                      Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-24 08:00 +1000
                        Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-25 03:04 +0000
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-25 16:34 +1000
                          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-25 09:55 +0100
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-25 20:23 +1000
                          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-25 12:01 +0100
                          Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-25 15:56 -0400
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 09:27 +1000
                          Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-25 20:43 -0400
                          Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-26 00:25 -0500
                      Re: Variables vs names [was: Objects in Python] Chris Angelico <rosuav@gmail.com> - 2012-08-24 09:34 +1000
                      Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 09:49 +1000
                      Re: Variables vs names [was: Objects in Python] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-23 19:52 -0400
                      Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-23 19:54 -0400
                      Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-24 10:01 +1000
                  Re: Objects in Python Terry Reedy <tjreedy@udel.edu> - 2012-08-23 13:17 -0400
              Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 00:16 +1000
              Re: Objects in Python Roy Smith <roy@panix.com> - 2012-08-23 20:36 -0400
                Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-24 11:34 +1000
                  Re: Objects in Python alex23 <wuwei23@gmail.com> - 2012-08-23 20:17 -0700
                    Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-24 04:14 -0500
                      Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-24 10:00 +0000
                        Re: Objects in Python Grant Edwards <invalid@invalid.invalid> - 2012-08-24 13:27 +0000
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-25 05:18 +1000
                        Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-26 00:45 -0500
                          Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 13:43 +0000
                            Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 23:58 +1000
                              Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 14:18 +0000
                                Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-27 00:54 +1000
                                  Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 22:47 +0000
                            Re: Objects in Python Roy Smith <roy@panix.com> - 2012-08-26 10:02 -0400
                              Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-27 00:14 +1000
                            Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-26 16:12 -0400
                              Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 23:29 +0000
                        Re: Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 16:22 +1000
                          Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 12:02 +0000
                            Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 23:34 +1000
                            Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-26 15:02 +0100
                            Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-27 00:05 +1000
                          Re: Objects in Python Roy Smith <roy@panix.com> - 2012-08-26 09:41 -0400
                Identity function id() [was Re: Objects in Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-24 10:06 +0000
            Re: Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 15:33 +1000
            Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-23 14:30 -0400
              Re: Objects in Python Alexander Blinne <news@blinne.net> - 2012-08-24 15:23 +0200
            Re: Objects in Python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2012-08-24 09:38 +0200
            Re: Objects in Python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2012-08-24 10:03 +0200
          Re: Objects in Python Walter Hurry <walterhurry@lavabit.com> - 2012-08-23 01:19 +0000
            Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:14 +0000
              Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 09:10 +0100
                Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-23 23:59 +1000
                  Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 15:20 +0100
                    Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 00:24 +1000
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 09:03 +0100
          Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:34 +0000
            Re: Objects in Python rusi <rustompmody@gmail.com> - 2012-08-23 10:04 -0700
    Re: Objects in Python John Gordon <gordon@panix.com> - 2012-08-22 15:03 +0000
    Re: Objects in Python shaun <shaun.wiseman91@gmail.com> - 2012-08-22 08:25 -0700
      Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 01:47 +1000
      Re: Objects in Python Dave Angel <d@davea.name> - 2012-08-22 11:51 -0400
      Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 17:13 +0100
      Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-22 11:29 -0600

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#27751

On Thu, 23 Aug 2012 12:17:03 -0500, Evan Driscoll wrote:

> I definitely *wouldn't* say "Python
> classes aren't really classes" -- even though (I assert) Python classes
> are *far* further from Simula-style (/Java/C++) classes than Python
> variables are from Java variables.

Well, Python classes are first-class (pun not intended) objects in their 
own right, and hence are data. Java and C++ classes are not, they are 
instructions to the compiler rather than data.

But other than that, what do you see as the difference between Python 
classes and Simula-style classes?



> On 08/23/2012 03:59 AM, Jussi Piitulainen wrote:
>> I would also avoid any distinction between an object and a "reference"
>> to an object, except as an implementation detail. It's not helpful.
> 
> Whaaaa....?
> 
> How would you describe it then? To me, that distinction is absolutely
> *fundamental* to understanding how languages like Python/Scheme/Java
> work, because it tells you how to reason about aliasing behavior in an
> unconvoluted way (which is essential to understanding how they work).
> 
> How would *you* suggest dealing with that issue?

Given:

x = some_object()
y = x

I could say that x and y are the same object, rather than x and y are 
references to the same object.

Sometimes, when I say "x", I mean the *name* x, which is a reference to 
some object.

Much more often though, when I say "x", I use it as a convenient label 
for some object. Rather than saying "the object which is referenced to by 
the name x", I just say "x".

Nearly always, the meaning is obvious in context.


[...]
> *However*, this thread wasn't really prompted by someone just trying to
> explain variables in different terms -- it was prompted by one of the
> many comments you see from time-to-time that "Python doesn't have
> variables – not as C or Java programmers would understand the term".

No offence to Ben Finney, but I think sometimes he's a bit too eager to 
emphasise the subtle differences between Python and other languages, 
rather than the similarities. (I used to be like Ben in this regard, but 
I got better -- or worse, depending on your perspective.)

Again, context is important: sometimes I will choose to gloss over the 
differences by calling x a variable, and sometimes I will emphasise the 
differences to C or Pascal by referring to name binding.


> To me, saying "here's an alternative way to look at variables" is great,
> but saying "Python doesn't have variables" is, IMO, at least as silly as
> what Jussi said. To me, dancing around the issue just leads to more
> confusing terminology and makes things worse.
> 
> (And this is reinforced by the fact that neither I nor Google seems to
> have really seen "Python doesn't have classes" ever used, when that
> statement is at least as true as "Python doesn't have variables".)

I think you are utterly wrong here.

Python has classes. They are created by the "class" keyword. Whether 
those classes are identical to Java classes is irrelevant -- in Python, 
these whatever-they-are-things are called "classes", and so Python has 
classes.

But Python does not have things called "variables". There is no 
"variable" keyword to create a variable. It is absolutely fundamental to 
the programming model of Python that it has objects which are bound to 
names in namespaces (and other entities, such as list items). That is 
*critical* -- Python uses name bindings.

But name bindings are a kind of variable. Named memory locations are a 
*different* kind of variable. The behaviour of C variables and Python 
variables do not follow the Liskov Substitution Principle -- you can't 
rip out the entire "names bound to objects" machinery of Python and 
replace it with C-like named memory locations without changing the high-
level behaviour of Python. And so by some ways of thinking it is *wrong* 
to treat name bindings and memory locations as "the same sort of entity". 
Hence, if C variables are variables, then Python name bindings can't be.

I used to agree with that reasoning. I no longer do, not entirely. While 
I see the differences between them -- for instance, C variables exist 
before they have a value assigned to them, Python name bindings do not -- 
I don't think the differences are important enough to *prohibit* use of 
the word "variable" to describe name bindings. Only to discourage it.



-- 
Steven

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

#27761 — Variables vs names [was: Objects in Python]

[Multipart message — attachments visible in raw view] — view raw

On 08/23/2012 12:56 PM, Steven D'Aprano wrote:
> On Thu, 23 Aug 2012 12:17:03 -0500, Evan Driscoll wrote:
> 
>> I definitely *wouldn't* say "Python
>> classes aren't really classes" -- even though (I assert) Python classes
>> are *far* further from Simula-style (/Java/C++) classes than Python
>> variables are from Java variables.
> 
> Well, Python classes are first-class (pun not intended) objects in their 
> own right, and hence are data. Java and C++ classes are not, they are 
> instructions to the compiler rather than data.
> 
> But other than that, what do you see as the difference between Python 
> classes and Simula-style classes?

So first, to some extent that's like saying "these two different things
are different in this important way, but other than that, what's the
difference?" :-)

But there are some other differences. (Not all of these are strictly
with classes per se, but I would say they all have strong interactions
with the object system.)

* Explicit 'self'. OK, this sounds just like a minor syntactic
  difference, and in some respect it is. (For some time I considered it
  an annoying piece of syntactic salt.) But it has significant
  interactions with other things which you can do, such as using a
  method as just a normal function ('type(c).f(c)' ~= 'c.f()')
  or attaching other functions to an instance or a class (more on that
  later).

  This is definitely my weakest argument. :-)

* Fields. In Simula-style classes, you can tell easily what fields a
  class and its objects contain. In Python, that question from some
  point of view doesn't even make sense (in the absence of __slots__).
  Fields are a property of the *objects* rather than the class, and
  two objects of the same class don't necessarily have the same fields.

  Related to this point we have...

* What it means for an object to have a particular class type. With
  Simula-style classes, if I have an object 'o' of class 'c', then I
  know that 'o' has the functions and fields defined by 'c'. Now, the
  virtual functions may have been overriden in base classes and stuff,
  and maydbe they'll always fail, but I at least know they're *there*.

  In Python, I know... well, nothing basically. As far as I know, it's
  possible to make it so that o's only relation to 'c' is what
  'type(o)' and 'instanceof' say. (And maybe you can even override
  those, I dunno!) You can go through and add/remove/replace functions.
  Two different objects of the same class may have completely disjoint
  sets of attributes.



> Given:
> 
> x = some_object()
> y = x
> 
> I could say that x and y are the same object, rather than x and y are 
> references to the same object.

Huh, fair enough.


>> To me, saying "here's an alternative way to look at variables" is great,
>> but saying "Python doesn't have variables" is, IMO, at least as silly as
>> what Jussi said. To me, dancing around the issue just leads to more
>> confusing terminology and makes things worse.
>>
>> (And this is reinforced by the fact that neither I nor Google seems to
>> have really seen "Python doesn't have classes" ever used, when that
>> statement is at least as true as "Python doesn't have variables".)
> 
> I think you are utterly wrong here.
> 
> Python has classes. They are created by the "class" keyword. Whether 
> those classes are identical to Java classes is irrelevant -- in Python, 
> these whatever-they-are-things are called "classes", and so Python has 
> classes.
> 
> But Python does not have things called "variables". There is no 
> "variable" keyword to create a variable.

OK, let's make a new language. I'll call it 'Python--' because at least
*I* wouldn't want to program in it. :-)

In Python--, any time you use a name, you have to prefix it with the
word 'variable':
  variable x = 4
  print(variable x)

Does Python-- have variables? Does Python? To me, the answer to those
questions basically has to be the same -- after all, the new 'variable'
keyword didn't really change the language, just have it a slightly
different concrete syntax. Heck, if I wanted to implement Python--, the
only thing I'd have to change in a Python implementation is the lexer!

And if you say "no, Python-- doesn't have variables, it just has
something that it wrongly calls variables", then it's no contradiction
to say "Python doesn't have classes, it just has something that it
wrongly calls classes."

Think of it as duck-typing the term "variable". :-) To me, Python locals
and globals look and quack like a variable.



Incidentally, I also realized another reason I don't like the 'names'
description. Take 'foo.bar'. (That is, the 'bar' attribute in object
'foo'.) Is 'foo.bar' a name? I'm not sure what the 'names' proponents
would say, but to me both answers are problematic. I *really* dislike a
'no' answer because to me, 'foo.bar' absolutely *is* a name for the
corresponding object. (This terminology has precedent.) But a 'yes'
answer, if you also reject 'variable', means you no longer have an
agreed-upon term for the names that are defined in the current scope --
and such a term is a really good thing to have! (<cheeky>I know, let's
call them variables. :-)</cheeky>)

Evan

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

#27773 — Re: Variables vs names

[Multipart message — attachments visible in raw view] — view raw

Evan Driscoll <driscoll@cs.wisc.edu> writes:

> Incidentally, I also realized another reason I don't like the 'names'
> description. Take 'foo.bar'. (That is, the 'bar' attribute in object
> 'foo'.) Is 'foo.bar' a name?

It is a reference. That reference happens to be two names, one within
the other's namespace.

> I'm not sure what the 'names' proponents would say

Who are the “names” proponents? I wouldn't propose that “variable” be
replaced with “name” in all, or even most, cases. As you point out, it's
not a good replacement.

I propose “variable” be replaced by “reference” or “binding”, depending
on what is being discussed.

> but to me both answers are problematic. I *really* dislike a 'no'
> answer because to me, 'foo.bar' absolutely *is* a name for the
> corresponding object. (This terminology has precedent.)

There are two names though: ‘foo’ and ‘bar’. The syntax used combines
those names in a particular way, to specify a reference.

> But a 'yes' answer, if you also reject 'variable', means you no longer
> have an agreed-upon term for the names that are defined in the current
> scope -- and such a term is a really good thing to have!

You've lost me here. I would call those names in the current scope
“names”, and I agree that calling what your example presents “a name” is
confusing.

Have I clarified by rejecting your simple use of “name” in this example?
Does my usage of the term “reference” help, as I think it does in this
and most other comparable examples?

-- 
 \        “The fact of your own existence is the most astonishing fact |
  `\    you'll ever have to confront. Don't dare ever see your life as |
_o__)    boring, monotonous, or joyless.” —Richard Dawkins, 2010-03-10 |
Ben Finney

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

#27847 — Re: Variables vs names [was: Objects in Python]

On Thu, 23 Aug 2012 14:22:08 -0500, Evan Driscoll wrote:

> On 08/23/2012 12:56 PM, Steven D'Aprano wrote:
>> On Thu, 23 Aug 2012 12:17:03 -0500, Evan Driscoll wrote:
>> 
>>> I definitely *wouldn't* say "Python
>>> classes aren't really classes" -- even though (I assert) Python
>>> classes are *far* further from Simula-style (/Java/C++) classes than
>>> Python variables are from Java variables.
>> 
>> Well, Python classes are first-class (pun not intended) objects in
>> their own right, and hence are data. Java and C++ classes are not, they
>> are instructions to the compiler rather than data.
>> 
>> But other than that, what do you see as the difference between Python
>> classes and Simula-style classes?
> 
> So first, to some extent that's like saying "these two different things
> are different in this important way, but other than that, what's the
> difference?" :-)

Yes, exactly. I acknowledge a difference between the two, and ask you 
what differences you see.

Many languages do not have "first-class functions" -- you cannot pass a 
function to another function as an argument, or generate them on the fly 
at runtime. But the ability of functions to be treated as data is not an 
essential part of being-a-function, so I see no problem with describing 
both Pascal functions and Python functions as functions.

Likewise, being able to pass classes around as data and generate them on 
the fly is not an essential part of being-a-class, to I see no problem 
with describing both Java classes and Python classes as classes.


> But there are some other differences. (Not all of these are strictly
> with classes per se, but I would say they all have strong interactions
> with the object system.)

I don't believe that any of those differences in behaviour are either 
critical, or (as you acknowledge) strictly in the concept of *class* 
itself. I think they're interesting differences, but I don't think they 
are essential to the nature of "classness" in the same way that having a 
fixed memory address is essential to the nature of "memory location 
variable" or a name in a namespace is essential to "name binding 
variable".


[...]
>> Python has classes. They are created by the "class" keyword. Whether
>> those classes are identical to Java classes is irrelevant -- in Python,
>> these whatever-they-are-things are called "classes", and so Python has
>> classes.
>> 
>> But Python does not have things called "variables". There is no
>> "variable" keyword to create a variable.
> 
> OK, let's make a new language. I'll call it 'Python--' because at least
> *I* wouldn't want to program in it. :-)
> 
> In Python--, any time you use a name, you have to prefix it with the
> word 'variable':
>   variable x = 4
>   print(variable x)
> 
> Does Python-- have variables? 

Of course, because that's what Python-- calls them. Whether Python-- is 
*justified* in calling them variables is a more interesting question.

I think it is, in the sense that name bindings are a kind of variable, 
and fixed memory locations are a different kind of variable. But I also 
think that it isn't, for exactly the reasons why I prefer to describe 
Python (without the minuses) as having name bindings rather than 
variables "in the C or Pascal sense".

Ultimately what is important are the semantics of the words, not the 
words themselves. Objections to use of "variable" are, I believe, 
*pragmatic* objections that the word comes with too much baggage to be 
safe to use, not that name bindings aren't a type of variable.


> Think of it as duck-typing the term "variable". :-) To me, Python locals
> and globals look and quack like a variable.

And so they should, since name bindings are a way of implementing the 
abstract Variable kind, so to speak.


> Incidentally, I also realized another reason I don't like the 'names'
> description. Take 'foo.bar'. (That is, the 'bar' attribute in object
> 'foo'.) Is 'foo.bar' a name? 

Is "Evan Driscoll" a name? Or is it two names?

There is no contradiction to say that "Evan Driscoll" is both a name (a 
"compound name", if you like, or fully-qualified name) and two names (a 
personal name plus a family name).

foo.bar is both a fully-qualified name and two names: the name of the 
namespace and the name of the attribute in the namespace.


> I'm not sure what the 'names' proponents
> would say, but to me both answers are problematic. I *really* dislike a
> 'no' answer because to me, 'foo.bar' absolutely *is* a name for the
> corresponding object. (This terminology has precedent.) But a 'yes'
> answer, if you also reject 'variable', means you no longer have an
> agreed-upon term for the names that are defined in the current scope

"Local names".

We also have "global names" for those in the global scope, "builtin 
names" for those in the built-ins, and "nonlocal names".



-- 
Steven

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

#27850 — Re: Variables vs names

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> On Thu, 23 Aug 2012 14:22:08 -0500, Evan Driscoll wrote:
>
> > In [the hypothetical language] Python--, any time you use a name,
> > you have to prefix it with the word 'variable':
> >   variable x = 4
> >   print(variable x)
> > 
> > Does Python-- have variables? 
>
> Of course, because that's what Python-- calls them. Whether Python--
> is *justified* in calling them variables is a more interesting
> question.

How many legs does a horse have, if you call the tail a leg?

Four. Calling the tail a leg doesn't make it so.


Similarly, I don't care that Python-- uses the term “variable”, it only
has variables if it has things which meet a sensible definition of
“variable”. So no, “because that's what Python-- calls them” is not
sufficient.

> I think it is, in the sense that name bindings are a kind of variable,
> and fixed memory locations are a different kind of variable. But I
> also think that it isn't, for exactly the reasons why I prefer to
> describe Python (without the minuses) as having name bindings rather
> than variables "in the C or Pascal sense".

To emphasise what may not be apparent to some newcomers, Steven and I
are virtually in exact agreement here. We talk more about where we
differ because that's what interests us :-)

-- 
 \              “In the long run, the utility of all non-Free software |
  `\      approaches zero. All non-Free software is a dead end.” —Mark |
_o__)                                                    Pilgrim, 2006 |
Ben Finney

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

#27767

On Fri, Aug 24, 2012 at 3:56 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> But name bindings are a kind of variable. Named memory locations are a
> *different* kind of variable. The behaviour of C variables and Python
> variables do not follow the Liskov Substitution Principle -- you can't
> rip out the entire "names bound to objects" machinery of Python and
> replace it with C-like named memory locations without changing the high-
> level behaviour of Python. And so by some ways of thinking it is *wrong*
> to treat name bindings and memory locations as "the same sort of entity".
> Hence, if C variables are variables, then Python name bindings can't be.

Yet Python's variables are extremely close to C's pointer variables.
If you allocate all your "real data" on the heap and do everything
with pointers, you'll have semantics very similar to Python's (except
that things aren't refcounted, so you have massive memory leaks). In
fact, that's how the Python-C API handles things - a PyObject*
basically _is_ a Python object, as far as C's concerned.

But again, that probably doesn't help explain the variables. Unless
you've come from (or can at least imagine) an environment in which you
use pointers for *everything*.

ChrisA

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

#27848

On Fri, 24 Aug 2012 08:00:59 +1000, Chris Angelico wrote:

> On Fri, Aug 24, 2012 at 3:56 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> But name bindings are a kind of variable. Named memory locations are a
>> *different* kind of variable. The behaviour of C variables and Python
>> variables do not follow the Liskov Substitution Principle -- you can't
>> rip out the entire "names bound to objects" machinery of Python and
>> replace it with C-like named memory locations without changing the
>> high- level behaviour of Python. And so by some ways of thinking it is
>> *wrong* to treat name bindings and memory locations as "the same sort
>> of entity". Hence, if C variables are variables, then Python name
>> bindings can't be.
> 
> Yet Python's variables are extremely close to C's pointer variables.

Not really. Pointer variables are no different from any other variable: 
you have a named memory location that contains some data. In this case, 
the data happens to be a link to another chunk of memory. The pointer 
variable itself is just a named location containing data, same as a char 
variable, a float variable, etc. The data is a pointer rather than a char 
or float, and the operations which you can do to pointers are different 
to those you can do to chars or floats, but that's true of any data type.

In languages without pointers, like Fortran 77, you can more or less 
simulate them with a fixed array of memory as the heap, with integer 
indexes into that array as pointers. These "pointer variables" are no 
different from other "integer variables" except in the meaning you, the 
programmer, gives them. This is no different from how C or Pascal treat 
pointers, except that those languages have syntactical support for 
pointer operations and Fortran 77 doesn't.


> If
> you allocate all your "real data" on the heap and do everything with
> pointers, you'll have semantics very similar to Python's

You're confusing two different levels of explanation here. On the one 
hand, you're talking about C semantics, where you are explicitly 
responsible for managing unnamed data via indirection (pointers). 
Typically, the *pointers* get given names, the data does not.

On the other hand, you talk about Python, where you have no access at all 
to the pointers and memory addresses. You manage the data you actually 
care about by giving them names, and then leave it up to the Python 
virtual machine to transparently manage whatever indirection is needed to 
make it work.

The fact that the end result is the same is hardly surprising -- Python's 
VM is built on top of C pointer indirection, so of course you can start 
with pointers and end up with Python semantics. But the practice of 
coding are very different:

* in C, I care about identifiers ("names") in order to explicitly manage 
addresses and pointers as a means to reach the data I actually care about;

* in Python, I care about identifiers in order to reach the data I 
actually care about.



-- 
Steven

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

#27852

On Sat, Aug 25, 2012 at 1:04 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> You're confusing two different levels of explanation here. On the one
> hand, you're talking about C semantics, where you are explicitly
> responsible for managing unnamed data via indirection (pointers).
> Typically, the *pointers* get given names, the data does not.
>
> On the other hand, you talk about Python, where you have no access at all
> to the pointers and memory addresses. You manage the data you actually
> care about by giving them names, and then leave it up to the Python
> virtual machine to transparently manage whatever indirection is needed to
> make it work.
> ...
> * in C, I care about identifiers ("names") in order to explicitly manage
> addresses and pointers as a means to reach the data I actually care about;
>
> * in Python, I care about identifiers in order to reach the data I
> actually care about.

Yet the two are almost the same. Python objects don't have names, they
just have their own data. (Leaving aside functions, which have their
names as data for the benefit of tracebacks and such.) A C pointer has
a name; a Python identifier has (or is, if you like) a name. They're
very different in how you use them only because C doesn't naturally
work with everything on the heap and pointers everywhere. In fact,
when I was interfacing Python and C, there were a few places where I
actually handed objects to Python and kept manipulating them, simply
because the Python data model suited what I was trying to do; but what
I was doing was using PyObject *some_object as though it were a Python
variable. I even did up a trivial C++ class that encapsulated the
INCREF/DECREF work, so my LocalPyObject really could be treated as a
local variable, Python-style.

Where's the difference?

ChrisA

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

#27857

On 25/08/2012 07:34, Chris Angelico wrote:
> On Sat, Aug 25, 2012 at 1:04 PM, Steven D'Aprano

I'm just wondering out aloud if the number of times this type of thread 
has been debated here will fit into a Python long or float?

-- 
Cheers.

Mark Lawrence.

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

#27862

On Sat, Aug 25, 2012 at 6:55 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> I'm just wondering out aloud if the number of times this type of thread has
> been debated here will fit into a Python long or float?

Well, when I have to store currency information, I like to store it as
an integer, using the native currency's "small unit" (eg the cent in
dollar+cent currencies). In this instance, instead of trying to count
the threads (which would be fractional), just count the number of
posts. It then is an integer, and I've yet to find any integer that
can't be represented as a Python long (or, in 3.x, int).

ChrisA

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

#27863

On 25/08/2012 11:23, Chris Angelico wrote:
> On Sat, Aug 25, 2012 at 6:55 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> I'm just wondering out aloud if the number of times this type of thread has
>> been debated here will fit into a Python long or float?
>
> Well, when I have to store currency information, I like to store it as
> an integer, using the native currency's "small unit" (eg the cent in
> dollar+cent currencies). In this instance, instead of trying to count
> the threads (which would be fractional), just count the number of
> posts. It then is an integer, and I've yet to find any integer that
> can't be represented as a Python long (or, in 3.x, int).
>
> ChrisA
>

That could have been fun in the good old days of pounds, shillings and 
pence.  Why they had to complicate things by going decimal I shall never 
know.  Bring back simplistic imperial measures for everything, that's 
what I say.

Using long just shows I've still got a Python 2 hat on.  Still when 
those fine people who develop Matplotlib deliver 1.2 with its Py3k 
compliance, aided or hindered by me testing on Windows, Python 3.3 here 
I come.

I suppose an alternative to long (or int) or float would have been the 
Decimal class from the decimal module?  Opinions on this anybody?

-- 
Cheers.

Mark Lawrence.

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

#27885

On Sat, 25 Aug 2012 09:55:27 +0100, Mark Lawrence
<breamoreboy@yahoo.co.uk> declaimed the following in
gmane.comp.python.general:

> 
> I'm just wondering out aloud if the number of times this type of thread 
> has been debated here will fit into a Python long or float?

	Well, since I don't think one can have a fractional debate (maybe if
someone starts a thread and NOBODY ever follows up on it), then float's
don't gain us anything there.

	Presuming a double-precision float, we would have 14-15 significant
digits for the mantissa -- so anything greater than
(9)99,999,999,999,999 will have lost accuracy. In contrast Python longs
have effectively unlimited significant digits.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#27889

On Sun, Aug 26, 2012 at 5:56 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Sat, 25 Aug 2012 09:55:27 +0100, Mark Lawrence
> <breamoreboy@yahoo.co.uk> declaimed the following in
> gmane.comp.python.general:
>
>>
>> I'm just wondering out aloud if the number of times this type of thread
>> has been debated here will fit into a Python long or float?
>
>         Well, since I don't think one can have a fractional debate (maybe if
> someone starts a thread and NOBODY ever follows up on it), then float's
> don't gain us anything there.
>
>         Presuming a double-precision float, we would have 14-15 significant
> digits for the mantissa -- so anything greater than
> (9)99,999,999,999,999 will have lost accuracy. In contrast Python longs
> have effectively unlimited significant digits.

I wonder if some people are applying an alternative form of duck
typing - if it quacks like a "should Python have variables" debate, it
gets silenced with that universal grey tape...

ChrisA

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

#27893

On Sun, 26 Aug 2012 09:27:14 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> 
> I wonder if some people are applying an alternative form of duck
> typing - if it quacks like a "should Python have variables" debate, it
> gets silenced with that universal grey tape...
>
	Which all too often is mis-used...

	Expose it to a season of direct sunlight and varying temperatues and
it rapidly decomposes, leaving a messy residue...*


* I used to use it to hold a dual-band rubber-duck antenna mount to the
window of my apartment... Every few months I'd end up peeling off a
cracking plastic layer, and having to clean up dried loose-weave gauze,
and scraping off the gum -- in order to re-apply a fresh layer.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#27902

On 08/24/2012 10:04 PM, Steven D'Aprano wrote:
> The fact that the end result is the same is hardly surprising -- Python's
> VM is built on top of C pointer indirection, so of course you can start
> with pointers and end up with Python semantics. But the practice of
> coding are very different:
>
> * in C, I care about identifiers ("names") in order to explicitly manage
> addresses and pointers as a means to reach the data I actually care about;
>
> * in Python, I care about identifiers in order to reach the data I
> actually care about.
>
So I find this comment very interesting. It makes me wonder if the root 
cause of our (pretty minor) disagreement is in some sense related to our 
mental models of *C* variables. I'm actually not much of a C programmer 
specifically, but I do a lot of C++ stuff. Of those two descriptions, 
I'd actually say that the Python description sounds more like how I 
think about variables in C++ most of the time.

Obviously there are differences between value and reference semantics 
between the two languages, but thinking about some variable being 
located at some address in memory is something that I actually do pretty 
rarely; I basically think of variables as naming data, and addresses 
mostly come into play when thinking about points-to and aliasing 
information at a more abstract level, much the same as I do in Python.

Evan

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

#27768 — Re: Variables vs names [was: Objects in Python]

On Fri, Aug 24, 2012 at 5:22 AM, Evan Driscoll <driscoll@cs.wisc.edu> wrote:
> In Python--, any time you use a name, you have to prefix it with the
> word 'variable':
>   variable x = 4
>   print(variable x)

That gets really unwieldy. You should shorten it to a single symbol.
And your language could be called Python Hypertext Preprocessor.

ChrisA

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

#27769

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> No offence to Ben Finney, but I think sometimes he's a bit too eager
> to emphasise the subtle differences between Python and other
> languages, rather than the similarities.

No offense taken.

> Again, context is important:

Indeed. Note that my assertion was in response to someone *already*
confused by pre-conceived notions about what “variable” means, and
misguided attempts to apply those to Python.

If it's over-eager to attempt to head off such confusion in others who
might be reading, then I deny the charge. Others have said it helps, so
I'll keep doing it.

> I don't think the differences are important enough to *prohibit* use of 
> the word "variable" to describe name bindings. Only to discourage it.

I wholly agree.

-- 
 \     “Facts do not cease to exist because they are ignored.” —Aldous |
  `\                                                            Huxley |
_o__)                                                                  |
Ben Finney

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

#27770 — Re: Variables vs names [was: Objects in Python]

On Thu, 23 Aug 2012 14:22:08 -0500, Evan Driscoll <driscoll@cs.wisc.edu>
declaimed the following in gmane.comp.python.general:

> 
> Incidentally, I also realized another reason I don't like the 'names'
> description. Take 'foo.bar'. (That is, the 'bar' attribute in object
> 'foo'.) Is 'foo.bar' a name? I'm not sure what the 'names' proponents
> would say, but to me both answers are problematic. I *really* dislike a
> 'no' answer because to me, 'foo.bar' absolutely *is* a name for the
> corresponding object. (This terminology has precedent.) But a 'yes'
> answer, if you also reject 'variable', means you no longer have an
> agreed-upon term for the names that are defined in the current scope --
> and such a term is a really good thing to have! (<cheeky>I know, let's
> call them variables. :-)</cheeky>)
>

	Let me complicate that... <G>

	It is a fully qualified name when one wishes to work with the
entirety of the object the name is bound to... It is a partially
qualified name with respect to any sub-components of that object.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#27771

On Fri, 24 Aug 2012 08:00:59 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> 
> But again, that probably doesn't help explain the variables. Unless
> you've come from (or can at least imagine) an environment in which you
> use pointers for *everything*.
>
	... but can not manipulate the pointer directly <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#27772

On Fri, Aug 24, 2012 at 9:54 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Fri, 24 Aug 2012 08:00:59 +1000, Chris Angelico <rosuav@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>>
>> But again, that probably doesn't help explain the variables. Unless
>> you've come from (or can at least imagine) an environment in which you
>> use pointers for *everything*.
>>
>         ... but can not manipulate the pointer directly <G>

Right, obviously pointer arithmetic doesn't make sense in Python. But
that's (almost) guaranteed by the fact that there is NOTHING you can
do with bare integers.

foo q = new q; /* note that 'foo' is a typedef that hides the asterisk */
foo w = q +1; /* Pointer arith! Impossible. */

But!

foo e = q + one; /* one is the object representing the integer 1 */

This isn't pointer arithmetic. No C compiler will let you add two
pointers. You can subtract one from another, but you get back a bare
integer, which won't go into a 'foo', so the only thing you could do
that would break stuff is:

foo r = q + (w - e); /* Syntactically valid */

So you just won't do pointer arith if everything's a pointer.

There, I think I just broke a few minds. My task here is done.

ChrisA

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

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

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

csiph-web