Python 3K or Python 2.9?

[TheFlyingDutchman]

Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

http://www.artima.com/weblogs/viewpo...?thread=214112

[Paul Rubin]

TheFlyingDutchman <zz******@aol.comwrites:

Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

http://www.artima.com/weblogs/viewpo...?thread=214112

That article is pretty weak.

[Ben Finney]

Paul Rubin <http://ph****@NOSPAM.invalidwrites:

TheFlyingDutchman <zz******@aol.comwrites:

Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

http://www.artima.com/weblogs/viewpo...?thread=214112

That article is pretty weak.

It is responded to by Guido here:

"A Response to Bruce Eckel"
<URL:http://www.artima.com/weblogs/viewpost.jsp?thread=214325>

--
\ "The trouble with eating Italian food is that five or six days |
`\ later you're hungry again." -- George Miller |
_o__) |
Ben Finney

[Graham Dumpleton]

On Sep 12, 2:14 pm, Ben Finney <[e-mail]>
wrote:

Paul Rubin <http://[e-mail]:

TheFlyingDutchman <[e-mail]:

Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

>http://www.artima.com/weblogs/viewpo...?thread=214112

That article is pretty weak.

It is responded to by Guido here:

"A Response to Bruce Eckel"
<URL:http://www.artima.com/weblogs/viewpost.jsp?thread=214325>

In that blog, Guido says:

"""Concurrency: It seems we're now happily out exploring here. I'm
looking forward to benchmarks showing that PP or similar (or
dissimilar!) solutions actually provide a performance gain. Another
route I'd like to see explored is integrating one such solution into
an existing web framework (or perhaps as WSGI middleware) so that web
applications have an easy way out without redesigning their
architecture."""

Maybe I don't fully understand where Guido is coming from, but
solutions for spreading web applications across multiple processes
have been available for a long time in solutions such as mod_python
and mod_fastcgi. With a view to improving further on these solutions
mod_wsgi has also been created.

All these solutions either use the multi process nature of the web
server, or themselves use multiple daemon processes to which requests
are distributed by Apache. End result is that one can make better use
of multi processor or multi core machines. Also, when using multi
threaded Apache worker MPM, because a lot of stuff is not even done in
Python code, such as static file serving, multiple cores can even be
used within the same process. Thus, in the larger context of how
Apache is implemented and what web applications provide, the GIL isn't
as big a problem as some like to believe it is as far as preventing
proper utilisation of the machines resources.

FWIW, I have blogged my own response to Guido's comment above at:

http://blog.dscpl.com.au/2007/09/par...d-modwsgi.html

Now over the years I have seen a lot of Python developers showing
quite a dislike for using Python integrated with Apache. As a result
the last thing people seem to want to do is fix such solutions up and
make them work better. Reality is though that unless a very good
solution for hosting Python with Apache comes up, you will probably
never see good cheap commodity web hosting for Python. Older solutions
simply aren't safe to use or are hard to set up and manage.

Creating lots of distinct Python processes and proxying to them, like
the purists would like to see, simply isn't going to happen as such
setups are too hard to manage and use up too much resources on a large
scale. Web hosting companies want something simple which they can
integrate into their existing PHP focused Apache installations and
which don't chew up huge amounts of additional resources, thereby
forcing a reduction in their site densities. To that end, we still
have a way to go.

An older blog entry of mine where I have covered these problems is:

http://blog.dscpl.com.au/2007/07/com...d-modwsgi.html

Graham

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

http://www.artima.com/weblogs/viewpo...?thread=214112

I'd say Mr Eckel fails to graps some of the great points about Python's
object model - the rant about the use of 'self' is a sure clue.

[Ivan Voras]

Bruno Desthuilliers wrote:

TheFlyingDutchman a écrit :

>Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:

http://www.artima.com/weblogs/viewpo...?thread=214112

I'd say Mr Eckel fails to graps some of the great points about Python's
object model - the rant about the use of 'self' is a sure clue.

What does "self" have to do with an object model? It's an
function/method argument that might as well be hidden in the compiler
without ever touching the role it has (if not, why?). I agree that it's
needless noise in a language.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFG58DJldnAQVacBcgRA6lpAKCoGSO09VcoJUQEhCurF7 1GiawZqQCgn3ey
XThFOTV2AWN/i3LkfXhBDXw=
=bpRc
-----END PGP SIGNATURE-----

[Bjoern Schliessmann]

Ivan Voras wrote:

What does "self" have to do with an object model? It's an
function/method argument that might as well be hidden in the
compiler without ever touching the role it has (if not, why?). I
agree that it's needless noise in a language.

If this was needless, why do C++ and Java have the "this" pointer?

Regards,
Björn

--
BOFH excuse #390:

Increased sunspot activity.

[Stefan Behnel]

Bjoern Schliessmann wrote:

>What does "self" have to do with an object model? It's an
function/method argument that might as well be hidden in the
compiler without ever touching the role it has (if not, why?). I
agree that it's needless noise in a language.

If this was needless, why do C++ and Java have the "this" pointer?

Be careful when you use the word "needless" in the context of Java.

Stefan

[Duncan Booth]

Ivan Voras <ivoras@_fer.hr_wrote:

>I'd say Mr Eckel fails to graps some of the great points about

Python's

>

>object model - the rant about the use of 'self' is a sure clue.

What does "self" have to do with an object model? It's an
function/method argument that might as well be hidden in the compiler
without ever touching the role it has (if not, why?). I agree that

it's

needless noise in a language.

You could add some syntax to Python such that '.x' was equivalent to
'<first argument of current function>.x' (either completely implicitly
or with some surrounding block that lets you specify the assumed
variable.

That wouldn't break anything in the syntax but the general feeling of
the Python community is that such a change would be undesirable as it is
better to write the variable name out explicitly.

As for omitting 'self' from method definitions, at first site you might
think the compiler could just decide that any 'def' directly inside a
class could silently insert 'self' as an additional argument. This
doesn't work though because not everything defined in a class has to be
an instance method: static methods don't have a self parameter at all,
class methods traditionally use 'cls' instead of 'self' as the name of
the first parameter and it is also possible to define a function inside
a class block and use it as a function. e.g.

class Weird:
def factory(arg):
"""Returns a function based on its argument"""

foo = factory("foo")
bar = factory("bar")
del factory

When factory is called, it is a simple function not a method. If it had
gained an extra parameter then either you would have to explicitly pass
it an instance of a not yet defined class when calling it, or the
compiler would have to somehow know that it had been defined with the
extra parameter and add it.

Basically it all boils down to having a consistent set of rules. Ruby
has one set of rules, but Python has a different set. Python's rules
mean you can interchange functions and methods more easily [at a cost of
having to write self out explicitly/with the advantage that you can
easily see references to self](delete as preferred). There is no
difference between:

class C:
def method(self): pass

and

def foo(self): pass
class C: pass
C.method = foo

both of these result in effectively the same class (although the second
one has a different name for the method in tracebacks).

That consistency really is important. Whenever I see a 'def' I know
exactly what parameters the resulting function will take regardless of
the context.

Another area to consider is what happens when I do:

foo = FooClass()

foo.bar(x)
# versus
f = foo.bar
f(x)

Both of these work in exactly the same way in Python: the self parameter
is bound to the method when you access 'foo.bar', not when you make the
call. That isn't the case in some other scripting languages. e.g. in
Javascript the first one would call bar with the magic 'this' parameter
set to foo, but in the second case it calls bar with 'this' set to the
global object.

My point here is that in Python the magic is clearly defined and
overridable (so we can have static or class methods that act
differently).

[Alex Martelli]

Duncan Booth <du**********@invalid.invalidwrote:
...

As for omitting 'self' from method definitions, at first site you might
think the compiler could just decide that any 'def' directly inside a
class could silently insert 'self' as an additional argument. This
doesn't work though because not everything defined in a class has to be
an instance method: static methods don't have a self parameter at all,
class methods traditionally use 'cls' instead of 'self' as the name of
the first parameter and it is also possible to define a function inside
a class block and use it as a function. e.g.

Actually you could do the "magic first-parameter insertion" just when
returning a bound or unbound method object in the function's __get__
special method, and that would cover all of the technical issues you
raise. E.g.:

class Weird:
def factory(arg):
"""Returns a function based on its argument"""

foo = factory("foo")
bar = factory("bar")
del factory

When factory is called, it is a simple function not a method. If it had

Sure, that's because the function object itself is called, not a bound
or unbound method object -- indeed. factory.__get__ never gets called
here.

class C:
def method(self): pass

and

def foo(self): pass
class C: pass
C.method = foo

both of these result in effectively the same class (although the second
one has a different name for the method in tracebacks).

And exactly the same would occur if the self argument was omitted from
the signature and magically inserted when __get__ does its job.

That consistency really is important. Whenever I see a 'def' I know
exactly what parameters the resulting function will take regardless of
the context.

And this non-strictly-technical issue is the only "true" one.

Another area to consider is what happens when I do:

foo = FooClass()

foo.bar(x)
# versus
f = foo.bar
f(x)

Both of these work in exactly the same way in Python: the self parameter

And so they would with the "__get__ does magic" rule, NP.

My point here is that in Python the magic is clearly defined and
overridable (so we can have static or class methods that act
differently).

And so it would be with that rule, since staticmethod &c create
different descriptor objects.

Really, the one and only true issue is that the Python community doesn't
like "magic". It would be perfectly feasible, we just don't wanna:-).
Alex

[Chris Mellon]

On 9/12/07, Alex Martelli <al***@mac.comwrote:

Duncan Booth <du**********@invalid.invalidwrote:
...

As for omitting 'self' from method definitions, at first site you might
think the compiler could just decide that any 'def' directly inside a
class could silently insert 'self' as an additional argument. This
doesn't work though because not everything defined in a class has to be
an instance method: static methods don't have a self parameter at all,
class methods traditionally use 'cls' instead of 'self' as the name of
the first parameter and it is also possible to define a function inside
a class block and use it as a function. e.g.

Actually you could do the "magic first-parameter insertion" just when
returning a bound or unbound method object in the function's __get__
special method, and that would cover all of the technical issues you
raise. E.g.:

class Weird:
def factory(arg):
"""Returns a function based on its argument"""

foo = factory("foo")
bar = factory("bar")
del factory

When factory is called, it is a simple function not a method. If it had

Sure, that's because the function object itself is called, not a bound
or unbound method object -- indeed. factory.__get__ never gets called
here.

class C:
def method(self): pass

and

def foo(self): pass
class C: pass
C.method = foo

both of these result in effectively the same class (although the second
one has a different name for the method in tracebacks).

And exactly the same would occur if the self argument was omitted from
the signature and magically inserted when __get__ does its job.

This would mean that mixing functions and methods would have to be
done like you do it in C++, with lots of careful knowledge and
inspection of what you're working with. What would happen to stuff
like inspect.getargspec?

Besides, if self isn't in the argument spec, you know that the very
next thing people will complain about is that it's not implicitly used
for locals, and I'll punch a kitten before I accept having to read
Python code guessing if something is a global, a local, or part of
self like I do in C++.

[Alex Martelli]

Chris Mellon <ar*****@gmail.comwrote:
...

Actually you could do the "magic first-parameter insertion" just when
returning a bound or unbound method object in the function's __get__
special method, and that would cover all of the technical issues you

...

This would mean that mixing functions and methods would have to be
done like you do it in C++, with lots of careful knowledge and
inspection of what you're working with.

Not particularly -- it would not require anything special that's not
required today.

What would happen to stuff
like inspect.getargspec?

It would return the signature of the function, if asked to analyze a
function, and the signature of the method, if asked to analyze a method.
Not exactly rocket science, as it happens.

Besides, if self isn't in the argument spec, you know that the very
next thing people will complain about is that it's not implicitly used
for locals,

Whether 'self' needs to be explicit as a function's first argument, and
whether it needs to be explicit (as a "self." ``prefix'') to access
instance variables (which is what I guess you mean here by "locals",
since reading it as written makes zero sense), are of course separate
issues.

and I'll punch a kitten before I accept having to read
Python code guessing if something is a global, a local, or part of
self like I do in C++.

Exactly: the technical objections that are being raised are bogus, and
the REAL objections from the Python community boil down to: we like it
better the way it is now. Bringing technical objections that are easily
debunked doesn't _strengthen_ our real case: in fact, it _weakens_ it.
So, I'd rather see discussants focus on how things SHOULD be, rather
than argue they must stay that way because of technical difficulties
that do not really apply.

The real advantage of making 'self' explicit is that it IS explicit, and
we like it that way, just as much as its critics detest it. Just like,
say, significant indentation, it's a deep part of Python's culture,
tradition, preferences, and mindset, and neither is going to go away (I
suspect, in fact, that, even if Guido somehow suddenly changed his mind,
these are issues on which even he couldn't impose a change at this point
without causing a fork in the community). Making up weak technical
objections (ones that ignore the possibilities of __get__ or focus on
something so "absolutely central" to everyday programming practice as
inspect.getargspec [!!!], for example;-) is just not the right way to
communicate this state of affairs.
Alex

[TheFlyingDutchman]

On Sep 12, 4:40 am, Bjoern Schliessmann <usenet-
[e-mail]:

Ivan Voras wrote:

What does "self" have to do with an object model? It's an
function/method argument that might as well be hidden in the
compiler without ever touching the role it has (if not, why?). I
agree that it's needless noise in a language.

If this was needless, why do C++ and Java have the "this" pointer?

"this" in C++ and Java is not shown in the parameter list, which was
what he was
complaining about. He wants

class MyClass:
def SomeFunction(someParameter):
self.someParameter = someParameter

not

class MyClass:
def SomeFunction(self, someParameter):
self.someParameter = someParameter
The confusing way about the current Python method when you first
encounter it is
why is "self" being passed in when you write the function but not
when you call it. If the compiler is smart enough to know that

a = MyClass()
a.SomeFunction(12)

SomeFunction() has a "self" implicitly added to the parameter list, it
seems that it should be smart enough to know that a function defined
in a class has a "self" implicitly added to the parameter list.

[TheFlyingDutchman]

>
"this" in C++ and Java is not shown in the parameter list, which was
what he was
complaining about. He wants

class MyClass:
def SomeFunction(someParameter):
self.someParameter = someParameter

not

class MyClass:
def SomeFunction(self, someParameter):
self.someParameter = someParameter

The confusing way about the current Python method when you first
encounter it is
why is "self" being passed in when you write the function but not
when you call it. If the compiler is smart enough to know that

a = MyClass()
a.SomeFunction(12)

SomeFunction() has a "self" implicitly added to the parameter list, it
seems that it should be smart enough to know that a function defined
in a class has a "self" implicitly added to the parameter list.

In C++ and Java I don't believe "this" is ever referred to as an
implicit function parameter. It is a (sometimes necessary) way to
reference the object inside one if it's methods. If it is in fact a
real parameter in the underlying compiled-code implementation, that
knowledge hurts more than it helps.

[Bjoern Schliessmann]

TheFlyingDutchman wrote:

In C++ and Java I don't believe "this" is ever referred to as an
implicit function parameter.

Oh yes, it is. All methods use it as a base address into instances.
Implicitly though.

It is a (sometimes necessary) way to reference the object inside
one if it's methods.

Also, I always like to use it explicitly. There's nothing worse than
to read others' source and not know if it's a global they access or
not.

If it is in fact a real parameter in the underlying compiled-code
implementation, that knowledge hurts more than it helps.

To which language are you referring here, Python or C++? No matter
what, I still don't really understand why it hurted.

Regards,
Björn

--
BOFH excuse #296:

The hardware bus needs a new token.

[Bjoern Schliessmann]

Stefan Behnel wrote:

Bjoern Schliessmann wrote:

>If this was needless, why do C++ and Java have the "this"
pointer?

Be careful when you use the word "needless" in the context of
Java.

Umm, why? I didn't introduce it.

Regards,
Björn

--
BOFH excuse #8:

static buildup

[TheFlyingDutchman]

On Sep 12, 3:53 pm, Bjoern Schliessmann <usenet-
[e-mail]:

TheFlyingDutchman wrote:

In C++ and Java I don't believe "this" is ever referred to as an
implicit function parameter.

Oh yes, it is. All methods use it as a base address into instances.
Implicitly though.

I am not talking about how the implementation of a C++ or Java
compiler uses the this pointer/this reference internally. I am talking
about how an author describes in English the "this" pointer/reference
in their book on programming C++ or Java.

I don't think you will find them saying that under the covers "this"
was passed to the method (if in fact it is). They just say that it
refers to the current object inside that object's method.

Here is a link to a tutorial where Sun is talking about the this
reference:
http://java.sun.com/docs/books/tutor...O/thiskey.html

If it is in fact a real parameter in the underlying compiled-code
implementation, that knowledge hurts more than it helps.

To which language are you referring here, Python or C++? No matter
what, I still don't really understand why it hurted.

I am referring to C++. If someone is trying to learn the language,
knowledge of the internal implemenation is counter-productive in my
opinion because it distracts from the details they need to learn. If
they are experienced and want to learn about the internals to
potentially help them code in the most blazingingly fast manner they
ideally would just be reminded they are using C++ and not some slower
byte-code executed language where it could possibly matter. ;)

[Ben Finney]

TheFlyingDutchman <zz******@aol.comwrites:

I am talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.

I don't think you will find them saying that under the covers "this"
was passed to the method (if in fact it is). They just say that it
refers to the current object inside that object's method.

In other words, it's magic, and the behaviour has to be explained so
the reader knows where the undeclared 'this' comes from.

How is that preferable to the magic of "instance is passed as the
first argument to a method"?
--
\ "If nothing changes, everything will remain the same." -- |
`\ Barne's Law |
_o__) |
Ben Finney

[TheFlyingDutchman]

On Sep 12, 5:47 pm, Ben Finney <[e-mail]>
wrote:

TheFlyingDutchman <[e-mail]:

I am talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.

I don't think you will find them saying that under the covers "this"
was passed to the method (if in fact it is). They just say that it
refers to the current object inside that object's method.

In other words, it's magic, and the behaviour has to be explained so
the reader knows where the undeclared 'this' comes from.

I would disagree that it _has_ to be explained where it came from. I
think knowing that the compiler is providing it is sufficient. Any
further knowledge of what the compiler is doing under the covers to
provide it is unnecessary. Sun made no mention of where "this" comes
from in that link I provided.

>
How is that preferable to the magic of "instance is passed as the
first argument to a method"?

I would mention that an instance is passed as the first parameter
argument of a method if the methods were declared with the extra
argument and called with the extra argument:
a = MyClass()

my_method(a,someParameter)

Then it makes sense to me to talk about it.

[Peter Decker]

On 9/12/07, Ben Finney <bi****************@benfinney.id.auwrote:

TheFlyingDutchman <zz******@aol.comwrites:

I am talking about how an author describes in English the "this"
pointer/reference in their book on programming C++ or Java.

I don't think you will find them saying that under the covers "this"
was passed to the method (if in fact it is). They just say that it
refers to the current object inside that object's method.

In other words, it's magic, and the behaviour has to be explained so
the reader knows where the undeclared 'this' comes from.

How is that preferable to the magic of "instance is passed as the
first argument to a method"?

So everything that isn't passed explicitly is "magic"? I suppose
__builtin__ counts as magic, too?

Define 'self' as a keyword, and its usage becomes no more magical than
'def' or 'break'.

--

# p.d.

[Ben Finney]

TheFlyingDutchman <zz******@aol.comwrites:

I would mention that an instance is passed as the first parameter
argument of a method if the methods were declared with the extra
argument and called with the extra argument:

a = MyClass()

my_method(a,someParameter)

Are you unaware that this is the way it works already?

>>class Foo(object):

... def bar(self, baz):
... print baz
...

>>foo = Foo()
Foo.bar("spam")

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

>>Foo.bar(foo, "spam")

spam

>>foo.bar("spam")

spam

The latter two statements are equivalent. The 'instance.method(args)'
syntax is just sugar for 'Class.method(instance, args)'.

--
\ "Choose mnemonic identifiers. If you can't remember what |
`\ mnemonic means, you've got a problem." -- Larry Wall |
_o__) |
Ben Finney

[Ben Finney]

"Peter Decker" <py******@gmail.comwrites:

On 9/12/07, Ben Finney <bi****************@benfinney.id.auwrote:

How is that preferable to the magic of "instance is passed as the
first argument to a method"?

So everything that isn't passed explicitly is "magic"?

No. Everything that's not explicit is "magic", in that it potentially
needs to be explained to a newcomer the first time they encounter it.

--
\ "Pinky, are you pondering what I'm pondering?" "I think so, |
`\ Brain, but if the plural of mouse is mice, wouldn't the plural |
_o__) of spouse be spice?" -- _Pinky and The Brain_ |
Ben Finney

[TheFlyingDutchman]

>>Foo.bar(foo, "spam")
>>foo.bar("spam")

That looks like a case of "There's more than one way to do it". ;)
The first form is definitely consistent with the
method declaration, so there's a lot to be said for using that style
when teaching people to make classes -send self, receive self.

The latter two statements are equivalent. The 'instance.method(args)'
syntax is just sugar for 'Class.method(instance, args)'.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for "easier
way of doing it"?

[Steven D'Aprano]

On Wed, 12 Sep 2007 19:40:04 -0700, TheFlyingDutchman wrote:

> >>Foo.bar(foo, "spam")
>>foo.bar("spam")

That looks like a case of "There's more than one way to do it". ;) The
first form is definitely consistent with the method declaration, so
there's a lot to be said for using that style when teaching people to
make classes -send self, receive self.

I think it is a horrible thing to teach beginners. Would you teach them
to write 1.__add__(1) instead of 1+1?

I think that beginners should be taught to write

instance.method(arguments)

and then only introduced to

class.method(instance, arguments)

when they progress to needing to know what happens under the hood.

>The latter two statements are equivalent. The 'instance.method(args)'
syntax is just sugar for 'Class.method(instance, args)'.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with sugar
as related to syntax. Is it being used as a synonym for "easier way of
doing it"?

"Syntactic sugar" is not really well defined, it's a fuzzy concept, but
in a nutshell it is special syntax made to "sweeten" the language by
giving an easier way to write common tasks.

It's hard to find examples of syntactic sugar that everybody agrees are
syntactic sugar, but I consider the following to be good (in the sense of
useful, obvious and well-thought-out) examples:

alist[-1] for alist[len(alist)-1]

list comprehensions and generator expressions
Perhaps less attractive, but still very(?) useful, examples of syntactic
sugar are decorators and the "X if C else Y" ternary operator.

--
Steven

[Ben Finney]

TheFlyingDutchman <zz******@aol.comwrites:

(Please, preserve attribution lines so it's clear who wrote what in
your quoted material.)

>>Foo.bar(foo, "spam")
>>foo.bar("spam")

That looks like a case of "There's more than one way to do it". ;)

Indeed, but there's only one *obvious* way to do it. (The latter, in
this case.)

The first form is definitely consistent with the method declaration,
so there's a lot to be said for using that style when teaching
people to make classes -send self, receive self.

Sure, go ahead and teach that way if you like; it'll work fine.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for
"easier way of doing it"?

Specifically an easier way of doing it provided by the language syntax
(hence "syntactic sugar"). As in, "the form 'foo += 1' is syntactic
sugar for 'foo = foo + 1'".

--
\ "I don't know half of you half as well as I should like, and I |
`\ like less than half of you half as well as you deserve." -- |
_o__) Bilbo Baggins |
Ben Finney

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

On Sep 12, 4:40 am, Bjoern Schliessmann <usenet-
[e-mail]:

>Ivan Voras wrote:

>>What does "self" have to do with an object model? It's an
function/method argument that might as well be hidden in the
compiler without ever touching the role it has (if not, why?). I
agree that it's needless noise in a language.

If this was needless, why do C++ and Java have the "this" pointer?

"this" in C++ and Java is not shown in the parameter list, which was
what he was
complaining about. He wants

class MyClass:
def SomeFunction(someParameter):
self.someParameter = someParameter

not

class MyClass:
def SomeFunction(self, someParameter):
self.someParameter = someParameter
The confusing way about the current Python method when you first
encounter it is
why is "self" being passed in when you write the function

At this stage, it's not "passed in", it's declared in the arguments list.

but not
when you call it.

It *is* passed when you call the function.

If the compiler is smart enough to know that

The compiler has absolutely nothing to do with it. It's the object model
that takes care of this. Quick explanation:

- functions objects implement the descriptor protocol.
- when a function which is an attribute of a class is looked up on an
instance of that class, the __get__ method of the function object is
called with the instance (and class) as arguments.
- this method returns a closure wrapping the instance, the class and the
function object itself
- when this closure is called, it itself prepends the instance to the
args it receives, calls the function with these args, and returns the
result.

This is why you need tho declare the instance as the first argument, but
don't need to pass it explicitely *when calling the function as a method
of an object*. Notice that you can still use the function directly,
passing the instance by yourself. And that you can define a function
outside a class and then attach it to a class. To make a long story
short, Python's methods are just thin temporary wrappers around plain
functions.

a = MyClass()
a.SomeFunction(12)

SomeFunction() has a "self" implicitly added to the parameter list, it
seems that it should be smart enough to know that a function defined
in a class has a "self" implicitly added to the parameter list.

The compiler has nothing to do with it, and where you define the
function is totally orthogonal:

def truc(obj):
print obj

class Toto(object):
pass

Toto.trac = truc

t = Toto()
t.trac()

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

> >>Foo.bar(foo, "spam")
>>foo.bar("spam")

That looks like a case of "There's more than one way to do it". ;)

Nope, on the contrary. The nice thing with this model is that you don't
have distinct rules for functions and methods, since methods are just
plain functions.

>The latter two statements are equivalent. The 'instance.method(args)'
syntax is just sugar for 'Class.method(instance, args)'.

I think I saw where Guido Van Rossum had referred to something as
"syntactic sugar" in some python.org page. I am not familiar with
sugar as related to syntax. Is it being used as a synonym for "easier
way of doing it"?

Yes. "syntactic sugar" mostly means "nicer, simpler syntax for something
that could be done without". And one of the *great* strength of Python
is that it exposes both the syntactic sugar for the most common uses
case and the underlying implementation for most advanced tricks.

[Piet van Oostrum]

>>>>TheFlyingDutchman <zz******@aol.com(T) wrote:

>TThe confusing way about the current Python method when you first
Tencounter it is
T why is "self" being passed in when you write the function but not
Twhen you call it.

It *is* passed when you call it, but it is written before the method name
instead of after it. Some people have called this an "infix" call similar
to infix operators.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Piet van Oostrum]

>>>>Ben Finney <bi****************@benfinney.id.au(BF) wrote:

>BFThe latter two statements are equivalent. The 'instance.method(args)'
BFsyntax is just sugar for 'Class.method(instance, args)'.

It is more than just syntactic sugar because the Class is derived from the
instance at runtime.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Alex Martelli]

TheFlyingDutchman <zz******@aol.comwrote:

>>Foo.bar(foo, "spam")
>>foo.bar("spam")

That looks like a case of "There's more than one way to do it". ;)
The first form is definitely consistent with the
method declaration, so there's a lot to be said for using that style
when teaching people to make classes -send self, receive self.

On the other hand, the second form is not polymorphic: it doesn't allow
for foo to be an instance of some OTHER class (possibly subclassing Foo
and overriding bar) -- it will call the Foo version of bar anyway.

type(foo).bar(foo, "spam") *IS* almost semantically equivalent to the
obviousy simpler foo.bar("spam") -- but doesn't cover the possibility
for foo to do a *per-instance* override of 'bar'.

getattr(foo, 'bar', functools.partial(type(foo).bar, foo))("spam") is
getting closer to full semantic equivalence. And if you think that's
"another OBVIOUS way of doing it" wrt foo.bar("spam"), I think your
definition of "obvious" may need a reset (not to mention the fact that
the "equivalent" version is way slower;-).

Foo.bar(foo, "spam")'s different semantics are important when any
implementation of type(foo).bar (or other method yet) wants to BYPASS
polymorphism to redirect part of the functionality to a specific type's
implementation of bar ('super' may help in some cases, but it keeps some
polymorphic aspects and pretty often you just want to cut all
polymorphism off and just redirect to ONE specific implementation).
Alex

[TheFlyingDutchman]

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list. But since Python 3 was
"code-named" 3000 (implying but not delivering big changes... I don't
think it required big changes) and since it still has an explicit
object parameter it's a given that it's not gonna happen in any
revisions.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods. But Perl does it as well.
I think the label "mainstream OO language" is as valid being applied
to Perl as it is to Python.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

[Wildemar Wildenburger]

TheFlyingDutchman wrote:

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.

(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))

/W

[TheFlyingDutchman]

>
Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.

(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))

But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.

[Stefan Bellon]

On Thu, 13 Sep, TheFlyingDutchman wrote:

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods.

Ada 95 does. And Ada 95 was the first standardized OO language. Now
with Ada 2005 you can either pass the the object explicitly as first
parameter (like in Ada 95) or you can call the method on the object
(like in Java, C++, Python, ...) and the object is passed implicitly.

--
Stefan Bellon

[Marc 'BlackJack' Rintsch]

On Thu, 13 Sep 2007 10:10:57 -0700, TheFlyingDutchman wrote:

>Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.

(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))

But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

That information is usually in the `__init__()` method and the class
docstring.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.

This should either be obvious or in the docstring.

Ciao,
Marc 'BlackJack' Rintsch

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list.

def fun(obj, *args, **kw):
# generic code here that do something with obj

import some_module
some_module.SomeClass.fun = fun

This is why uniformity is important.

But anyway, I think it's quite clear that Python won't drop the explicit
self, so it looks like you have to live with it or choose another language.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods.

to methods. class methods gets the class as first parameter.

Anyway, there are a lot of things that Python doesn't do like "other
mainstream OO languages", and that's a GoodThing.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

I definitively think you'd be happier with some other language.

[TheFlyingDutchman]

>
(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))

Maybe you can sneak Jython into the mix. Just describe it as "this
Java scripting language".

[Bjoern Schliessmann]

TheFlyingDutchman wrote:

Here's a FAQ item where they refer to it as I think Python should
have done it - a special predefined variable:

Maybe. Personally, I like it the way it is in Python.

Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

Regards,
Björn

--
BOFH excuse #135:

You put the disk in upside down.

[Wildemar Wildenburger]

TheFlyingDutchman wrote:

>(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))

Maybe you can sneak Jython into the mix. Just describe it as "this
Java scripting language".

Hehe, devious idea. I might just try that. :)

/W

[Bruno Desthuilliers]

Bjoern Schliessmann a écrit :

TheFlyingDutchman wrote:

>>Here's a FAQ item where they refer to it as I think Python should
have done it - a special predefined variable:

Maybe. Personally, I like it the way it is in Python.

Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

The problem being that there's no such thing as a "method declaration"
in Python - only functions being attributes of a class...

(ok, I know, you meant "functions declared within a class statement").

[Terry Reedy]

"TheFlyingDutchman" <zz******@aol.comwrote in message
news:11*********************@g4g2000hsf.googlegrou ps.com...
| Here's a FAQ item where they refer to it as I think Python should have
| done it - a special predefined variable:
|
| http://www.faqs.org/docs/javap/c5/s5.html
|
| "Java provides a special, predefined variable named "this" that you
| can use for such purposes. The variable, this, is used in the source
| code of an instance method to refer to the object that contains the
| method. This intent of the name, this, is to refer to "this object,"
| the one right here that this very method is in. If x is an instance
| variable in the same object, then this.x can be used as a full name
| for that variable. If otherMethod() is an instance method in the same
| object, then this.otherMethod() could be used to call that method.
| Whenever the computer executes an instance method, it automatically
| sets the variable, this, to refer to the object that contains the
| method."

In Python, methods are (functions) contained in (are attributes of)
classes. Hence, by the above, 'this' or 'self' would be set to the class
and not the instance. So the above would require some rewording for
Python.

[Bjoern Schliessmann]

Bruno Desthuilliers wrote:

Bjoern Schliessmann a écrit :

>Why don't you make a preprocessor which accepts method
declarations without "self" and fixes them?

The problem being that there's no such thing as a "method
declaration" in Python

Yep, there are only definitions. I'm sorry.

- only functions being attributes of a class...

What, IYHO, is the difference between a method and a function?

(ok, I know, you meant "functions declared within a class
statement").

I think that those functions _are_ special ones since the compiler
is able to make "method(instance, a, b)" out of
"instance.method(a, b)". So IMHO, "method definition" makes sense.

Regards,
Björn

--
BOFH excuse #144:

Too few computrons available.

[Steven D'Aprano]

On Thu, 13 Sep 2007 20:59:06 +0200, Bjoern Schliessmann wrote:

TheFlyingDutchman wrote:

>Here's a FAQ item where they refer to it as I think Python should have
done it - a special predefined variable:

Maybe. Personally, I like it the way it is in Python.

Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

If you look at the thread "parameter list notation" from ten days or so
ago, TheFlyingDutchman has forked Python and is working on a very special
new language, PIEthun 3.01B. I for one am looking forward to seeing all
the very special features of PIEthun.

--
Steven.

[Aahz]

In article <87************@benfinney.id.au>,
Ben Finney <bi****************@benfinney.id.auwrote:

>
Specifically an easier way of doing it provided by the language syntax
(hence "syntactic sugar"). As in, "the form 'foo += 1' is syntactic
sugar for 'foo = foo + 1'".

Except, of course, that it isn't, quite. ;-)
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html

[Aahz]

In article <1i***************************@mac.com>,
Alex Martelli <al***@mac.comwrote:

>Chris Mellon <ar*****@gmail.comwrote:

>>
and I'll punch a kitten before I accept having to read
Python code guessing if something is a global, a local, or part of
self like I do in C++.

Exactly: the technical objections that are being raised are bogus, and
the REAL objections from the Python community boil down to: we like it
better the way it is now. Bringing technical objections that are easily
debunked doesn't _strengthen_ our real case: in fact, it _weakens_ it.
So, I'd rather see discussants focus on how things SHOULD be, rather
than argue they must stay that way because of technical difficulties
that do not really apply.

The real advantage of making 'self' explicit is that it IS explicit, and
we like it that way, just as much as its critics detest it. Just like,
say, significant indentation, it's a deep part of Python's culture,
tradition, preferences, and mindset, and neither is going to go away (I
suspect, in fact, that, even if Guido somehow suddenly changed his mind,
these are issues on which even he couldn't impose a change at this point
without causing a fork in the community). Making up weak technical
objections (ones that ignore the possibilities of __get__ or focus on
something so "absolutely central" to everyday programming practice as
inspect.getargspec [!!!], for example;-) is just not the right way to
communicate this state of affairs.

While you have a point, I do think that there is no solution that allows
the following code to work with no marker distinguishing the local bar
from the instance's bar; the only question is how you want to mark up
your code:

class C:
def foo(self, bar):
print bar, self.bar

x = C()
x.bar = 'abc'
x.foo()

From that standpoint, there is a technical objection involved. Of
course, the solution can be any of a number of different marker systems
(or even choosing to have no marker and not permit a method to access
both object attributes and locals of the same name), and Python has
chosen to force the use of a marker for all object attributes, while also
choosing to have disjoint namespaces WRT globals and locals for any one
name.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html

[TheFlyingDutchman]

If you look at the thread "parameter list notation" from ten days or so

ago, TheFlyingDutchman has forked Python and is working on a very special
new language, PIEthun 3.01B.
I for one am looking forward to seeing all
the very special features of PIEthun.

It will be named PIEthun 3000 as it comes out of Beta. But you're not
alone. From the emails I have been receiving there is anticipation and
excitement from Mumbai to Dusseldorf to Caracas.

[Terry Reedy]

"Bjoern Schliessmann" <us**************************@spamgourmet.comwro te
in message news:5k************@mid.individual.net...
|- only functions being attributes of a class...

|What, IYHO, is the difference between a method and a function?

A method is a function accessed as an attribute of a class or instance.
As an object type, it is a *runtime* function wrapper.

|(ok, I know, you meant "functions declared within a classstatement").

| I think that those functions _are_ special ones

Thinking does not make things so.

|since the compiler is able to make "method(instance, a, b)" out of
|"instance.method(a, b)".

No it does not. The method wrapping is done at runtine. The compiler is
ignorant of the wrapping that will be done.

>>class C:

def meth(self): pass

>>c = C()
import dis
def f(): return c.meth()

>>dis.dis(f)

1 0 LOAD_GLOBAL 0 (c)
3 LOAD_ATTR 1 (meth)
6 CALL_FUNCTION 0
9 RETURN_VALUE

The function gets wrapped as a bound method as part of LOAD_ATTR. When the
compiler sees <expr>(args), it does not know and does not care about the
particular type that <exprwill become. It just assumes that it will be
callable and emits the code to call it. Consider

>>def g(): return C()

>>dis.dis(g)

1 0 LOAD_GLOBAL 0 (C)
3 CALL_FUNCTION 0
6 RETURN_VALUE

It does not notice and does not care that 'C' will be bound to a class.

Terry Jan Reedy

[Bjoern Schliessmann]

Terry Reedy wrote:

No it does not. The method wrapping is done at runtine. The
compiler is ignorant of the wrapping that will be done.

Agreed, after reading the docs.

>>>dis.dis(f)

1 0 LOAD_GLOBAL 0 (c)
3 LOAD_ATTR 1 (meth)
6 CALL_FUNCTION 0
9 RETURN_VALUE

The function gets wrapped as a bound method as part of LOAD_ATTR.
When the compiler sees <expr>(args), it does not know and does not
care about the
particular type that <exprwill become. It just assumes that it
will be
callable and emits the code to call it. Consider

That's interesting. BTW, do you know something (apart from the dis
docs) that's worth reading if you're interested in Python byte
code?

Regards,
Björn

--
BOFH excuse #138:

BNC (brain not connected)

[Duncan Booth]

Piet van Oostrum <pi**@cs.uu.nlwrote:

>>>>>Ben Finney <bi****************@benfinney.id.au(BF) wrote:

>>BFThe latter two statements are equivalent. The
'instance.method(args)' BFsyntax is just sugar for
'Class.method(instance, args)'.

It is more than just syntactic sugar because the Class is derived from
the instance at runtime.

Other differences that mean it isn't just sugar:

you can save the bound method created by 'instance.method' but not with the
expanded version.

The equivalence depends on the type of 'method', other expansions are
possible: e.g. Class.method(Class, args) or Class.method(args) or invent
your own.

[Terry Reedy]

"Bjoern Schliessmann" <us**************************@spamgourmet.comwro te
in message news:5k************@mid.individual.net...
That's interesting. BTW, do you know something (apart from the dis
docs) that's worth reading if you're interested in Python byte
code?

------------------
That is the only Python specific thing I remember reading. Of course, it
helps that I learned assembler a long time ago, and that I have used an HP
reverse-polish notation calculator (a fixed-size stack machine), and that I
have seen and understand algorithms for turning prefix and infix to postfix
notation.

tjr