Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Why the 'self' argument?

Reply
Thread Tools

Why the 'self' argument?

 
 
John Roth
Guest
Posts: n/a
 
      09-08-2003

"Harri Pesonen" <(E-Mail Removed)> wrote in message
news:7T47b.4753$(E-Mail Removed)...
> John Roth wrote:
>
> > "Harri Pesonen" <(E-Mail Removed)> wrote in message
> > news:TRr6b.4056$(E-Mail Removed).. .
> >
> >>Grant Edwards wrote:
> >>
> >>>In article <Ucp6b.3992$(E-Mail Removed)>, Harri Pesonen

> >
> >>Also I think that the class members should be explicitly declared. In
> >>general, it would be nice to have an option (like Option Explicit in
> >>Visual Basic) so that you can't assign to variables that have not been
> >>declared. It would probably make Python less error prone.

> >
> > I believe that is what __slots__ is for. That's run time rather than
> > compile time, but at least it gives you the error on the statement
> > that attempts to do an invalid assignment.

>
> Thanks guys, I hadn't heard of __slots__ before. Perhaps I am reading a
> too old book. Of course, a compile time check would be better...


__slots__ came in with 2.2 new style classes, and it's definitely
an advanced feature. There's also some thought that it may not
be the best way to do the job.

> >>Also if
> >>variable declarations could have the type, again some errors could be
> >>detected at compile time.

> >
> > It's quite possible to add run time type checking to Python, at a
> > significant cost in performance. See the descriptors material.

>
> I think that Python already has run time type checking. It does not
> allow "a" + 1, for example.


Actually, it doesn't. It has run time strong typing, which is a different
thing.

To me, at least, "type checking" implies a meta-operation, that is,
something that is outside of the operation itself insuring that the correct
types are used. In languages with static typing, that something is the
compiler.

Runtime type checking means that there is additional code somewhere
that checks that the object you are trying to bind is of an allowable
type; that code is basically supervisory in nature.

> > There's been quite a bit of work on a compile time type checking
> > system over the years, but it has never resulted in a proposal that

could
> > be agreed on.

>
> It would be quite simple to have "option explicit" like in Visual Basic,
> I believe. Like the following:
>
> option explicit
> var a = "asdf"
> b = 1 # error at compile time
> a = 123
> (var b, var c, var d) = (1, 2, 3)
> e = "asdf" # error at compile time


Things are not so simple. To do compile time type
checking, the compiler has to know the actual type
of the result of the expressions on the right hand side
of the assignments. In a dynamic language like Python,
that's not possible without very fundamental changes
to the nature of the language.

It's not a simple thing to do, and the fact that ML
family languages manage to do it without having
to have explicit type declarations (well, most of the
time anyway) is a major achievement, IMO.

The fact that Bicycle Repair Man manages to do it
as well as it does for Python is an even more
impressive achievement.

John Roth

>
> Harri
>



 
Reply With Quote
 
 
 
 
Terry Reedy
Guest
Posts: n/a
 
      09-09-2003

"John Roth" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> It's not a simple thing to do, and the fact that ML
> family languages manage to do it without having
> to have explicit type declarations (well, most of the
> time anyway) is a major achievement, IMO.


As I remember, part of the cost (for ML at least) is having separate
operators for ints and floats. Bye bye generic functions. I don't
remember if there was any escape from the type straightjacket (like
#define max(a,b) ... in C). And one has to adjust to and feel
comfortable enough with the view that multiparam functions are a
composition of single param functions. But I agree that the type
inferencing is an interesting achievement.

Terry J. Reedy


 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      09-09-2003

"Terry Reedy" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "John Roth" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > It's not a simple thing to do, and the fact that ML
> > family languages manage to do it without having
> > to have explicit type declarations (well, most of the
> > time anyway) is a major achievement, IMO.

>
> As I remember, part of the cost (for ML at least) is having separate
> operators for ints and floats.


As well as separate operators for a number of other things. This
isn't unique to ML, though. For other reasons, Perl has a seperate
set of operators for string versus numeric comparisons, and even
Python has separate operators for division.

> Bye bye generic functions.


Actually, they seem to be able to have generic functions, at least
in some restricted cases.

> I don't
> remember if there was any escape from the type straightjacket (like
> #define max(a,b) ... in C). And one has to adjust to and feel
> comfortable enough with the view that multiparam functions are a
> composition of single param functions.


I'm not sure how central currying is to the type inference
mechanism.

> But I agree that the type
> inferencing is an interesting achievement.


Yes, it is. That is, I think, my point. If we want to have some
form of static typing and still keep Python reasonably close to the
streamlined language we all know and love, this seems like an
interesting research direction.

John Roth

>
> Terry J. Reedy
>
>



 
Reply With Quote
 
Harri Pesonen
Guest
Posts: n/a
 
      09-09-2003
John Roth wrote:
> "Harri Pesonen" <(E-Mail Removed)> wrote in message
> news:7T47b.4753$(E-Mail Removed)...
>>
>>It would be quite simple to have "option explicit" like in Visual Basic,
>>I believe. Like the following:
>>
>>option explicit
>>var a = "asdf"
>>b = 1 # error at compile time
>>a = 123
>>(var b, var c, var d) = (1, 2, 3)
>>e = "asdf" # error at compile time

>
> Things are not so simple. To do compile time type
> checking, the compiler has to know the actual type
> of the result of the expressions on the right hand side
> of the assignments. In a dynamic language like Python,
> that's not possible without very fundamental changes
> to the nature of the language.


In fact I didn't mean *type* checking above but checking that the
variable has been declared. Adding "option explicit" would not be so
hard, I believe.

Then you could have (to almost get back to the subject):

class A:
var a # declare member variables
def __init__(self, a): # should be __init__(a)
self.a = a # OK because a has been defined

a1 = A("test")
a1.a # OK
a1.b = 1 # error at compile time

Type checking could be an extension to the above...

var a as str

Harri

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      09-09-2003

"John Roth" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Terry Reedy" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > #define max(a,b) ... in C). And one has to adjust to and feel
> > comfortable enough with the view that multiparam functions are a
> > composition of single param functions.

>
> I'm not sure how central currying is to the type inference
> mechanism.


Completely central in that the type of functions *is* a curried type
(in the *MLs I have looked at). For instance, the type of a binary
int function is displayed something like:

func(int)==>func(int)==>int

with ==> associative right to left. The type of f(i,j)=>int is 'a
function (of i) returning [a function (of j) returning an int]'. As I
said, takes some adjustment for most. But occasional mental exercise
like this is probably good for the brain.

Terry J. Reedy


 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      09-11-2003
On Thu, 11 Sep 2003 11:33:38 +0000 (UTC), Grzegorz Staniak <(E-Mail Removed)> wrote:
[...]
>To sum up what I've learnt here and from the FAQ: 'self' could actually be
>any string (it is 'self' by convention), as its role is only to serve as
>the first argument of methods in order to facilitate the process of
>associating method calls with their context. It would be possible (even if
>not obviously desirable) to implement method definitions in such a way
>as to avoid the first argument completely, i.e.
>
> def something():
> ...
>
>so actually it's just a question of implementation. Having little
>experience with object-oriented programming, I won't try to relate to
>pro and contra arguments that have been given in the discussion, I just
>have one more question: isn't it a little superfulous to have to use the
>'classmethod()' builtin to declare class methods? I'd think giving a
>class object name as the first argument should suffice?
>

I think you may have misunderstood classmethod. Rebinding a class attribute
with the result of classmethod makes a method that
works differently from an ordinary method. It means that the class itself will
be bound to the first argument, even if the method is called as an attribute
of an instance of the class. E.g.,

>>> class A(object):

... def cm(*args): return args
... cm = classmethod(cm)
... def m(*args): return args
...
>>> class B(A): pass

...
>>> a= A()
>>> b= B()
>>> a.cm()

(<class '__main__.A'>,)
>>> a.m()

(<__main__.A object at 0x00902350>,)
>>> b.cm()

(<class '__main__.B'>,)
>>> b.m()

(<__main__.B object at 0x008F9690>,)

and note:

>>> A.cm()

(<class '__main__.A'>,)
>>> B.cm()

(<class '__main__.B'>,)

but:
>>> A.m()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unbound method m() must be called with A instance as first argument (got nothing instead)
>>> B.m()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unbound method m() must be called with B instance as first argument (got nothing instead)

also, you don't have to do it inside the class definition, and it's not about a specific
attribute name -- i.e. you don't have to write xxx = classmethod(xxx) as is conventional,
unless the following is fooling me.

>>> def bar(*args): return 'bar %r'%args

...
>>> class C(B): pass

...
>>> C.cmbar = classmethod(bar)
>>> c=C()
>>> c.cmbar()

"bar <class '__main__.C'>"
>>> C.cmbar()

"bar <class '__main__.C'>"
>>> c.cm()

(<class '__main__.C'>,)
>>> c.m()

(<__main__.C object at 0x00902170>,)

Of course the result is not *identical*, since you can see the original function name
(note that you get a *bound* method either way with a classmethod, vs the ordinary C.m/c.m)

>>> C.cmbar

<bound method type.bar of <class '__main__.C'>>
>>> c.cmbar

<bound method type.bar of <class '__main__.C'>>
>>> C.cm

<bound method type.cm of <class '__main__.C'>>
>>> c.cm

<bound method type.cm of <class '__main__.C'>>
>>> C.m

<unbound method C.m>
>>> c.m

<bound method C.m of <__main__.C object at 0x00902170>>

Regards,
Bengt Richter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments