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 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#27764

On 8/23/12 20:17 , Ian Kelly wrote:

...

>>> Well, there you go. There *is* something wrong with having six variables
>>> called 'q'.

>> Sometimes you don't want only six variables called 'q' but a hundred
>> of them :-)
>>
>>    def fac(q):
>>        if q < 1 :
>>            return 1
>>        else:
>>            return q * fac(q-1)
>>
>>    print(fac(100))

> That's only one variable called 'q', instantiated 100 times simultaneously.

Bare with me, i come from a C world, and think of each variable,
whatever its name or scope, as a piece of memory and therefore
different.
btw. I like the idea of simultaneously instantiation :-)

Jan Kuiken

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

#27904

Jan Kuiken於 2012年8月24日星期五UTC+8上午2時02分00秒寫道：
> On 8/23/12 06:11 , Steven D'Aprano wrote:
> 
> 
> 
> >> 2) Related to the above, you can infinitely nest scopes. There's nothing
> 
> >> wrong with having six variables called 'q'; you always use the innermost
> 
> >> one. Yes, this can hurt readability
> 
> >
> 
> > Well, there you go. There *is* something wrong with having six variables
> 
> > called 'q'.
> 
> 
> 
> Sometimes you don't want only six variables called 'q' but a hundred
> 
> of them :-)
> 
> 
> 
>    def fac(q):
> 
>        if q < 1 :
> 
>            return 1
> 
>        else:
> 
>            return q * fac(q-1)
> 
> 
> 
>    print(fac(100))
> 


> 
> 
> 
> 
> Jan Kuiken

The long integer arithmetic operations are built in. 
This makes mathematicians and designers focused on the theory side.

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

#27669

On 22/08/2012 18:46, lipska the kat wrote:
> On 22/08/12 18:01, Terry Reedy wrote:
>> On 8/22/2012 10:59 AM, lipska the kat wrote:
>>
>>> There is no real enforced concept of information hiding, no binding of
>>> type to variable in fact no concept of typing at all as far as I can
>>> see.
>>
>> Given that type(valid_name) always returns a type(class), that is a
>> slightly strange statement.
>
> [snip]
>
> Well I'm a beginner so I'm allowed to make strange statements.
> However I don't think it's that strange and here's why.
>
> If, in a language, I find I am able to say
>
> a = 1
>
> then later, in the same scope I can say
>
> a = "foo"
>
> then later again in the same scope I can say
>
> a = ([1,2,3], "xyz", True)
>
> then, and I may be missing something here, to me, that doesn't say
> 'strongly typed' that says 'no typing constraints whatsoever'
>
> If you can show me a 'type' that cannot be assigned to
>
> a
>
> in the same scope then I would be most interested to know, I haven't
> found one yet.

You've said nothing above except that any object you like can be bound 
to a Python name.  The name 'a' is never used.  What happens when you 
actually do something with the object that you've bound to 'a'?

>
> We need to separate out the 'view' from the 'implementation' here.
> Most developers I know, if looking at the code and without the possibly
> dubious benefit of knowing that in Python 'everything is an object'
> would not call this 'strong typing'

I really despair that after ten years of using Python people still seem 
to be incapable of distinguishing strong, static, weak and dynamic 
typing.  Not that it's a specific Python problem of course, just that I 
always get to read about it here.

>
> Once again, this is not a criticism, it's an observation
>
> It is OK to to make (possibly erroneous) observations isn't it?

Not if undoes concepts that computer scientists have patiently been 
trying to explain for years.

>
> Thanks for taking the time to reply.
>
> lipska
>


-- 
Cheers.

Mark Lawrence.

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

#27675

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

On 08/22/2012 12:46 PM, lipska the kat wrote:
> If you can show me a 'type' that cannot be assigned to
> 
> a
> 
> in the same scope then I would be most interested to know, I haven't
> found one yet.

As other people have said, you've just pointed out the difference
between static typing and dynamic typing -- and how the former types
variables (or "names") and the latter types objects. I just have a few
things to add to your post and others.


First, from some point of view, you're correct. From a type theory point
of view "dynamically typed" is an oxymoron, because *by definition*
(from this point of view) types are a property of variables (and
expressions). For example, Ben Pierce says (in "Types and Programming
Languages"):

  The word "static" is sometimes added explicitly...to distinguish
  the sorts of compile-time analyses we are considering here from the
  dynamic or latent typing found in languages such as Scheme, where
  run-time type tags are used to distinguish different kinds of
  structures in the heap. Terms like "dynamically typed" are arguably
  misnomers and should probably be replaced by "dynamically checked,"
  but the usage is standard.

(And the usage is standard because it's just really useful to be able to
say "dynamically-typed" instead of "uni-typed with runtime checks of
things that act like types". (I don't think Pierce's "dynamically
checked" is specific enough. :-))


Second, this concept isn't *so* unfamiliar to you. If I give you the
following Java code:

  void foo(Object o) { ... }

and ask what type 'o' is, there are kind of two answers. The first is
that 'o' is an 'Object'. But you can't make an Object -- that's an
abstract class. (IIRC. If it's not then just bear with me; you get the
idea. :-)) So from a strictly static type-theory point of view, 'foo' is
unusable because it takes a type which you can never create. But of
course that's not the case, because in actual Java 'o' has some dynamic
type which is a subclass of 'Object'.

Though I'm sure this statement will be *really* popular with this list
</sarcasm>, if it puts your mind at ease a little, you can imagine that
there are no primitive types and Python names all have type 'Object',
but that you can refer to the functions in an object's dynamic type
without explicitly downcasting. (The analogy isn't perfect.)


On 08/22/2012 01:15 PM, Ian Kelly wrote:
> The classic example of weak typing is concatenation of strings and
> numbers, e.g. ("abc" + 123).  Weakly typed languages like JavaScript
> will implicitly coerce the number to a string and perform the
> concatenation.  Strongly typed languages like Python will raise a
> TypeError instead.

I would also say don't get *too* caught up in categorizing everything
into "strong" and "weak"; that's a spectrum, and where things fall is a
lot more interesting than just "here or there". Really it's even more
complex than just a linear spectrum -- Language A can be stronger than
Language B in one respect but weaker in another.

In particular, it's possible to have rather stronger typing than Python
(especially with respect to Booleans, but in some other respects as well).

Evan

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

#27680

On 22/08/12 20:03, Evan Driscoll wrote:
> On 08/22/2012 12:46 PM, lipska the kat wrote:
>> If you can show me a 'type' that cannot be assigned to
>>
>> a
>>
>> in the same scope then I would be most interested to know, I haven't
>> found one yet.
>
[snip]

>
> Second, this concept isn't *so* unfamiliar to you. If I give you the
> following Java code:
>
>    void foo(Object o) { ... }
>
> and ask what type 'o' is, there are kind of two answers. The first is
> that 'o' is an 'Object'. But you can't make an Object -- that's an
> abstract class. (IIRC. If it's not then just bear with me; you get the
> idea. :-)) So from a strictly static type-theory point of view, 'foo' is
> unusable because it takes a type which you can never create. But of
> course that's not the case, because in actual Java 'o' has some dynamic
> type which is a subclass of 'Object'.

Well I think this is where I'm struggling a bit.

looking at this method declaration I can see that the method takes an 
argument of type Object (and just FYI class Object is not abstract and 
you can do Object o = new Object()) and does not return a value.
I know that for the lifetime of this JVM, whatever o turns out to be it 
will always be an Object. I can't assign a primitive to o as ints chars 
floats etc are certainly not Objects. There are certain invariants that 
give me a warm and comfortable feeling inside.

compare this to a function declaration in Python

def foo(self):

... I can learn nothing about this function by looking at the first line

If I see

def foo(self, someVar=1):

I can determine that foo takes an argument that, at some time or other 
is or has been a number of some description but I can't rely on it and I 
have no idea what is returned and that's where I think I'm having trouble.

But I will get over it and I will learn the language and I may look back 
on these exchanges and say ... I was wrong, this is so much better that 
what I was used to, or maybe I won't. I'll let you know

Thank you for your calm and reasoned response.

Disclaimer:
None of my comments above should be construed as criticisms
they are just observations.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#27683

On 22/08/2012 20:45, lipska the kat wrote:
> On 22/08/12 20:03, Evan Driscoll wrote:
>> On 08/22/2012 12:46 PM, lipska the kat wrote:
>>> If you can show me a 'type' that cannot be assigned to
>>>
>>> a
>>>
>>> in the same scope then I would be most interested to know, I haven't
>>> found one yet.
>>
> [snip]
>
>>
>> Second, this concept isn't *so* unfamiliar to you. If I give you the
>> following Java code:
>>
>>    void foo(Object o) { ... }
>>
>> and ask what type 'o' is, there are kind of two answers. The first is
>> that 'o' is an 'Object'. But you can't make an Object -- that's an
>> abstract class. (IIRC. If it's not then just bear with me; you get the
>> idea. :-)) So from a strictly static type-theory point of view, 'foo' is
>> unusable because it takes a type which you can never create. But of
>> course that's not the case, because in actual Java 'o' has some dynamic
>> type which is a subclass of 'Object'.
>
> Well I think this is where I'm struggling a bit.
>
> looking at this method declaration I can see that the method takes an
> argument of type Object (and just FYI class Object is not abstract and
> you can do Object o = new Object()) and does not return a value.
> I know that for the lifetime of this JVM, whatever o turns out to be it
> will always be an Object. I can't assign a primitive to o as ints chars
> floats etc are certainly not Objects. There are certain invariants that
> give me a warm and comfortable feeling inside.
>
> compare this to a function declaration in Python
>
> def foo(self):
>
[snip]
That's not actually a declaration but a definition. :-)

The function's body is bound to the name at runtime, so:

     def double_it(x):
         return x * 2

is not far from:

     double_it = lambda x: x * 2

The only declarations are "global" and "nonlocal" (and the latter
exists only in recent versions of Python).

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

#27684

On 22/08/2012 21:31, MRAB wrote:
> On 22/08/2012 20:45, lipska the kat wrote:
>>
>> compare this to a function declaration in Python
>>
>> def foo(self):
>>
> [snip]
> That's not actually a declaration but a definition. :-)
>
> The function's body is bound to the name at runtime, so:
>
>      def double_it(x):
>          return x * 2
>
> is not far from:
>
>      double_it = lambda x: x * 2
>
> The only declarations are "global" and "nonlocal" (and the latter
> exists only in recent versions of Python).

Looking at the self I'm assuming that's a method and not a function.

-- 
Cheers.

Mark Lawrence.

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

#27693 — Methods versus functions [was Re: Objects in Python]

On Wed, 22 Aug 2012 21:46:29 +0100, Mark Lawrence wrote:

>> On 22/08/2012 20:45, lipska the kat wrote:
>>>
>>> compare this to a function declaration in Python
>>>
>>> def foo(self):
[...]
> Looking at the self I'm assuming that's a method and not a function.


Actually, it is a function. It doesn't get turned into a method until you 
try to use it.

The way methods work in Python is this:

Function objects are created by the "def" statement, regardless of 
whether that is inside a class or not. So:

class X(object):
    def spam(self, value):
        pass

creates a single function object which takes one argument, self, and 
sticks in in the class namespace X.__dict__['spam'] = spam

When you look up the name "spam" on an X instance:

x = X()
x.spam(42)

Python does it's usual attribute lookup stuff, finds the name "spam" in 
the class namespace, and extracts the function object. So far that's just 
ordinary attribute access. This is where it gets interesting...

Function objects are *descriptors*, which means that they have a __get__ 
method:

py> (lambda x: None).__get__
<method-wrapper '__get__' of function object at 0xb71bd77c>

Python sees that __get__ method and calls it with some appropriate 
arguments (the class object and the instance object, I believe) and the 
__get__ method constructs a method on the fly, handles the automatic bind-
instance-to-self magic, and returns the method object. And then finally 
Python calls the method object with whatever arguments you provided.

As they say, "You can solve any problem in computer science with 
sufficient layers of indirection". This descriptor protocol, as they call 
it, is the mechanism behind methods, class methods, static methods, 
properties, and probably other things as well.

You can do all sorts of funky things with descriptors -- google for 
"descriptor protocol", "data descriptor", "non-data descriptor" etc. if 
you are interested. Here's a trivial, but useful, one:

http://code.activestate.com/recipes/577030-dualmethod-descriptor/


-- 
Steven

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

#27686

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

On 08/22/2012 02:45 PM, lipska the kat wrote:
> On 22/08/12 20:03, Evan Driscoll wrote:
>> Second, this concept isn't *so* unfamiliar to you. If I give you the
>> following Java code:
>>
>>    void foo(Object o) { ... }
>>
> looking at this method declaration I can see that the method takes an
> argument of type Object (and just FYI class Object is not abstract and
> you can do Object o = new Object()) and does not return a value.
> I know that for the lifetime of this JVM, whatever o turns out to be it
> will always be an Object. I can't assign a primitive to o as ints chars
> floats etc are certainly not Objects. There are certain invariants that
> give me a warm and comfortable feeling inside.

I'm not saying it's nothing, but "can't assign a primitive" isn't much
of an invariant in the broad scheme of things when you can pass items as
diverse as lists, GUI buttons, files, etc. I would say it's more like if
you see 'int x' then *that* imposes a pretty big invariant, but passing
'Object' imposes almost nothing.

This is especially true considering the fact that you actually *can* say
'foo(4)' and Java will go and autobox the 4 into Integer(4) for you.

(BTW, this analogy suggests a way that's actually fairly useful for how
to look at Python coming from the Java perspective: Python just lacks
primitive types and things like integers are always boxed. Thus *all*
Python variables are essentially references.)

Evan

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

#27712

On 22/08/12 22:31, Evan Driscoll wrote:
> On 08/22/2012 02:45 PM, lipska the kat wrote:
>> On 22/08/12 20:03, Evan Driscoll wrote:
>>> Second, this concept isn't *so* unfamiliar to you. If I give you the
>>> following Java code:
>>>
>>>     void foo(Object o) { ... }
>>>
>> looking at this method declaration I can see that the method takes an
>> argument of type Object (and just FYI class Object is not abstract and
>> you can do Object o = new Object()) and does not return a value.
>> I know that for the lifetime of this JVM, whatever o turns out to be it
>> will always be an Object. I can't assign a primitive to o as ints chars
>> floats etc are certainly not Objects. There are certain invariants that
>> give me a warm and comfortable feeling inside.
>
> I'm not saying it's nothing, but "can't assign a primitive" isn't much
> of an invariant in the broad scheme of things

Well we don't want to turn this into a language comparison thread do we, 
that might upset too many people but I can't remember ever writing a 
method that took an Object as argument, you just can't do that much with 
an Object. I do however often write methods that take an interface as 
argument knowing that in future, any classes I write that implement this 
interface would just work thanks to subtype polymorphism

A method 'declaration' such as this in an interface

Product getProductByBarcode(Barcode b) throws CrappyProductException;

tells me a whole lot about what the 'definition' in an implementing 
class might do, in fact I might well get away with just reading the 
interface and using the method without having to delve into the code.

And I think this is the nub of the problem at the moment. I'm in a 
particular mindset, almost 'locked in' you might say and when I see a 
Python function that doesn't give me what I need straight away I get 
annoyed.

I will get over it.

> when you can pass items as
> diverse as lists, GUI buttons, files, etc. I would say it's more like if
> you see 'int x' then *that* imposes a pretty big invariant, but passing
> 'Object' imposes almost nothing.

Well you may be able to pass them in but you couldn't really do anything 
meaningful with them as you are restricted to operations on Object, I 
suppose you could pepper your code with tests to check the runtime type 
of a reference but it all gets a bit messy.

[snip]

> Thus *all*
> Python variables are essentially references.)

That makes sense

Thanks for taking the time to reply. It really is most valuable to me.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#27743

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

On 08/23/2012 04:19 AM, lipska the kat wrote:
> Well we don't want to turn this into a language comparison thread do we,
> that might upset too many people but I can't remember ever writing a
> method that took an Object as argument, you just can't do that much with
> an Object.

In the pre-Java-1.5 days, functions that took Objects were *very*
common; e.g. every collections class. Even now there are probably
lingering cases where either there's some code that hasn't been
genericized or is too much work to genericize to make it worthwhile. (I
do very little Java programming so can't point to any concrete cases if
you would (reasonably) reject the example of java.util.collections being
used in their non-generic form.)

Anyway, the point wasn't that 'foo(Object o)' is common, just that
you've probably seen something which is somewhat comparable.

Evan

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

#27752

On 23/08/12 17:44, Evan Driscoll wrote:
> On 08/23/2012 04:19 AM, lipska the kat wrote:
>> Well we don't want to turn this into a language comparison thread do we,
>> that might upset too many people but I can't remember ever writing a
>> method that took an Object as argument, you just can't do that much with
>> an Object.
>
> In the pre-Java-1.5 days, functions that took Objects were *very*
> common;

Well the Collections framework does expose methods that take Objects but 
generally you override certain methods in class Object when you want to 
compare Objects, in fact String comparison is a really interesting area 
due to the way Java internalizes Strings at compile time... but that is 
way to off topic for here.

regards

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#27687

lipska the kat <lipskathekat@yahoo.co.uk> writes:

> If, in a language, I find I am able to say
>
> a = 1
>
> then later, in the same scope I can say
>
> a = "foo"
>
> then later again in the same scope I can say
>
> a = ([1,2,3], "xyz", True)
>
> then, and I may be missing something here, to me, that doesn't say
> strongly typed' that says 'no typing constraints whatsoever'

You haven't discovered anything about types; what you have discovered is
that Python name bindings are not variables.

In fact, Python doesn't have variables – not as C or Java programmers
would understand the term. What it has instead are references to objects
(with names as one kind of reference).

The documentation unfortunately calls these references “variables” in
various places, which IMO compounds the confusion in newcomers
experienced with other languages. It's best, I think, to reject the idea
that Python has variables, and think in terms of references instead.

Any reference (with some very narrow specific exclusions, like ‘None’)
can be re-bound to any other object without regard to the previous
binding.

> We need to separate out the 'view' from the 'implementation' here.
> Most developers I know, if looking at the code and without the
> possibly dubious benefit of knowing that in Python 'everything is an
> object' would not call this 'strong typing'

Those people are confused, then. Python is strongly typed: objects
always know their type, the type is always exact, and the type of an
object can't be changed.

This is always true regardless of whether the object is referred to
zero, one, or many times.

Python is dynamically typed: References (and hence names) don't have
types.

> It is OK to to make (possibly erroneous) observations isn't it?

One of our long-time regulars (Aahz, whom I haven't seen for a long
time, sadly) quipped that the best way to get correct information on
Usenet is not to ask a question, but to post incorrect information.
That's not a license for such behaviour, but an observation on its
effectiveness.

I'd say that so long as you phrase your assertions to indicate the level
of confidence and possibility of error, that's okay.

-- 
 \          “Generally speaking, the errors in religion are dangerous; |
  `\    those in philosophy only ridiculous.” —David Hume, _A Treatise |
_o__)                                           of Human Nature_, 1739 |
Ben Finney

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

#27688

On Wed, Aug 22, 2012 at 5:58 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Those people are confused, then. Python is strongly typed: objects
> always know their type, the type is always exact, and the type of an
> object can't be changed.

Except when it can.

>>> class A: pass
...
>>> class B: pass
...
>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> isinstance(a, B)
False
>>> a.__class__ = B
>>> type(a)
<class '__main__.B'>
>>> isinstance(a, A)
False
>>> isinstance(a, B)
True

Cheers,
Ian

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

#27697

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

On 8/22/2012 18:58, Ben Finney wrote:
> You haven't discovered anything about types; what you have discovered is
> that Python name bindings are not variables.
> 
> In fact, Python doesn't have variables – not as C or Java programmers
> would understand the term. What it has instead are references to objects
> (with names as one kind of reference).

OK, I've seen this said a few times, and I have to ask: what do you mean
by this? I consider myself pretty decent at Python and other languages,
and I really don't get it.

Especially the comparison to Java variables. Java programmers are quite
used to variables which are references to objects: everything that's not
a primitive type is a reference, and it's kinda hard to determine
whether primitives are references or actual primitives.

And many other languages have reference behavior and still call their
bindings "variables", e.g. Scheme.

Evan

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

#27700

On Wed, 22 Aug 2012 23:49:17 -0500, Evan Driscoll wrote:

> On 8/22/2012 18:58, Ben Finney wrote:
>> You haven't discovered anything about types; what you have discovered
>> is that Python name bindings are not variables.
>> 
>> In fact, Python doesn't have variables – not as C or Java programmers
>> would understand the term. What it has instead are references to
>> objects (with names as one kind of reference).
> 
> OK, I've seen this said a few times, and I have to ask: what do you mean
> by this? I consider myself pretty decent at Python and other languages,
> and I really don't get it.

I think the point that Ben would like to make is that while "name 
binding" is a specific kind of "variable", the word "variable" comes with 
too much baggage from the old-school C, Pascal etc. style of variables-
are-named-memory-locations. Most of the time, the differences are 
unimportant, but when they are important, if your mental image is that 
Python "variables" (name bindings) are like C or Pascal 
"variables" (memory locations), you're going to get confused.


[...]
> And many other languages have reference behavior and still call their
> bindings "variables", e.g. Scheme.

Yes, well in my opinion, a great deal of the terminology in use is 
absolutely dire. E.g. both Ruby and Java have the exact same parameter 
binding strategy as Python, only the Ruby people call theirs "call by 
reference" and the Java people call theirs "call by value", *both of 
which are identical*, and NEITHER of which are the same thing that C and 
Pascal programmers will understand by call by value *or* call by 
reference.

http://mail.python.org/pipermail/tutor/2010-December/080505.html



-- 
Steven

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

#27709

Steven D'Aprano writes:
> On Wed, 22 Aug 2012 23:49:17 -0500, Evan Driscoll wrote:
> 
> > On 8/22/2012 18:58, Ben Finney wrote:
> >> You haven't discovered anything about types; what you have
> >> discovered is that Python name bindings are not variables.
> >> 
> >> In fact, Python doesn't have variables – not as C or Java
> >> programmers would understand the term. What it has instead are
> >> references to objects (with names as one kind of reference).
> > 
> > OK, I've seen this said a few times, and I have to ask: what do
> > you mean by this? I consider myself pretty decent at Python and
> > other languages, and I really don't get it.
> 
> I think the point that Ben would like to make is that while "name
> binding" is a specific kind of "variable", the word "variable" comes
> with too much baggage from the old-school C, Pascal etc. style of
> variables- are-named-memory-locations. Most of the time, the
> differences are unimportant, but when they are important, if your
> mental image is that Python "variables" (name bindings) are like C
> or Pascal "variables" (memory locations), you're going to get
> confused.

I don't get it either. To me the python-has-no-variables campaigners
seem confused. As far as I can see, Python can be seen in terms of
variables bound to (locations containing) values perfectly well, in a
way that should be quite familiar to people who come from Java (or
Lisp, Scheme like me).

It is very bad that people campaign here against the terminology that
is used in the official Python language reference and the Python
tutorial.

Best would be to simply explain how the variables, values, assignment,
and calls work in Python, the way the language reference and tutorial
actually do.

If the no-variables campaign is to continue, the language reference
and the tutorial should be changed to match. I would consider it a mad
move, but the current practice of badmouthing the official wording is
not healthy either.

> [...]
> > And many other languages have reference behavior and still call
> > their bindings "variables", e.g. Scheme.
> 
> Yes, well in my opinion, a great deal of the terminology in use is
> absolutely dire. E.g. both Ruby and Java have the exact same
> parameter binding strategy as Python, only the Ruby people call
> theirs "call by reference" and the Java people call theirs "call by
> value", *both of which are identical*, and NEITHER of which are the
> same thing that C and Pascal programmers will understand by call by
> value *or* call by reference.

That's indeed such a mess that those call-by-* terms may be now best
avoided. I would also avoid any distinction between an object and a
"reference" to an object, except as an implementation detail. It's not
helpful. It only leads to the confusion where it seems that Java (or
Python) does not actually have objects at all, only references to
objects, which in turn don't exist, so, er, what.

The swap function is helpful. Why doesn't it work? Because it assigns
to different variables that are local to the function. If I pass it a
list, why can it then swap the elements? Because that is the same
list, not a copy. Get used to it. Works for me.

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

#27726

On 23/08/2012 09:59, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
>> On Wed, 22 Aug 2012 23:49:17 -0500, Evan Driscoll wrote:
>>
>> > On 8/22/2012 18:58, Ben Finney wrote:
>> >> You haven't discovered anything about types; what you have
>> >> discovered is that Python name bindings are not variables.
>> >>
>> >> In fact, Python doesn't have variables – not as C or Java
>> >> programmers would understand the term. What it has instead are
>> >> references to objects (with names as one kind of reference).
>> >
>> > OK, I've seen this said a few times, and I have to ask: what do
>> > you mean by this? I consider myself pretty decent at Python and
>> > other languages, and I really don't get it.
>>
>> I think the point that Ben would like to make is that while "name
>> binding" is a specific kind of "variable", the word "variable" comes
>> with too much baggage from the old-school C, Pascal etc. style of
>> variables- are-named-memory-locations. Most of the time, the
>> differences are unimportant, but when they are important, if your
>> mental image is that Python "variables" (name bindings) are like C
>> or Pascal "variables" (memory locations), you're going to get
>> confused.
>
> I don't get it either. To me the python-has-no-variables campaigners
> seem confused. As far as I can see, Python can be seen in terms of
> variables bound to (locations containing) values perfectly well, in a
> way that should be quite familiar to people who come from Java (or
> Lisp, Scheme like me).
>
[snip]
In Java a variable exists even when it has not been assigned a value.
In Python, on the other hand, the basic model is that a 'variable'
doesn't exist until it has been bound to an value (although, for
efficiency reasons, that's not entirely true, because at compile time
CPython will identify the local variables in a function and allocate a
'slot' for it).

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

#27739

On Thu, Aug 23, 2012 at 4:59 AM, Jussi Piitulainen
<jpiitula@ling.helsinki.fi> wrote:
> I don't get it either. To me the python-has-no-variables campaigners
> seem confused. As far as I can see, Python can be seen in terms of
> variables bound to (locations containing) values perfectly well, in a
> way that should be quite familiar to people who come from Java (or
> Lisp, Scheme like me).

Personally, when I was learning python I found the idea of python
having names and values (rather than variables and references) to
clear up a lot of my misconceptions of the python object model.  I
think it's done the same for other people too, especially those who
come from the C world, where a variable is a named and typed location
in memory.

Perhaps those that come from the Java and Lisp world don't find the
name/value paradigm as helpful.  Still, it seems silly to excoriate
people on the list for trying to explain python fundamentals in
several different ways.  Sometimes explaining the same idea in
different words helps people understand the concept better.

-- 
Jerry

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

#27747

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

[I have some things to say to a few people so I'm just putting it all in
one rather than clutter up your email box even more.]

On 08/23/2012 12:33 AM, Chris Angelico wrote:
> [Snip discussion on names vs variables]
>
> Does that sort things out, or just make things more confusing?
>
> ChrisA

I... am not sure. I don't think it really told me anything new. I think
it's just that I don't think that any of the distinctions (nor all of
them put together) makes it worthwhile to reject a perfectly good term
in common use just because the behavior of Python variables is a bit
different from the behavior of variables in *some* other languages.

For instance, I don't get annoyed that both Java and Python use the
terms "class" and "object" for similar but still very different things.
And while I think it's worth saying "Python classes and objects are
rather different from Java's", 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.


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?


On 08/23/2012 09:43 AM, Jerry Hill wrote:
> On Thu, Aug 23, 2012 at 4:59 AM, Jussi Piitulainen wrote:
>> I don't get it either. To me the python-has-no-variables campaigners
>> seem confused. As far as I can see, Python can be seen in terms of
>> variables bound to (locations containing) values perfectly well, in a
>> way that should be quite familiar to people who come from Java (or
>> Lisp, Scheme like me).
>
> ...
>
> Perhaps those that come from the Java and Lisp world don't find the
> name/value paradigm as helpful.  Still, it seems silly to excoriate
> people on the list for trying to explain python fundamentals in
> several different ways.  Sometimes explaining the same idea in
> different words helps people understand the concept better.

I agree with this, and I'm happy that people found it useful.

*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".
That's a different than saying "here's another way of looking at Python
variables", and that instance is even toned down compared to a lot of
the instances you'll find (which will often omit the qualification at
the end).

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

Evan

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

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

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

csiph-web