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

[John Roth]

On Sep 12, 11:35 am, TheFlyingDutchman <[e-mail]:

On Sep 12, 4:40 am, Bjoern Schliessmann <[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.

Pretty close. This is one of the things that's always puzzled me about
the discussion. Making self and cls keyword pseudo-constants that get
the current instance and class from the stack frame (or raise an
exception) would eliminate them from the method header.

It would ALSO eliminate a whole level of indirection in method
invocation and get rid of the instancemethod, classmethod and
staticmethod wrapper classes. This would be a significant
simplification. If it had been done earlier, it would have eliminated
most of the justification for method attributes (those silly @
things), thus showing that unneeded complexity breeds more unneeded
complexity.

John Roth

[George Sakkis]

On Sep 12, 1:35 pm, TheFlyingDutchman <[e-mail]:

On Sep 12, 4:40 am, Bjoern Schliessmann <[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

If one *really* wants this, it is doable in python too:
http://www.voidspace.org.uk/python/w..._16.shtml#e583

George

[=?ISO-8859-1?Q?Ricardo_Ar=E1oz?=]

Bruno Desthuilliers wrote:

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.

<Ironic>

Hi, I'm new to Python, I don't even fully know the language, never done
a full project in Python. What's more, probably I'll never will.
But that's not the point, the point is I want YOU people to modify the
language you know in and out, the program with which you've done many
systems, I want you to change it to suit my whims, so that I'll be
comfortable with the 3 ten liners I'll write.
TIA

</Ironic>

[David Trudgett]

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

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.

Several languages use the "object.method(args)" form, which is syntactic
sugar for "method(object, other_args)" which Ada, for instance, uses.
Knowing this clears up half the confusion (the object /is/ passed as a
parameter whichever syntax is used).

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

David Trudgett
--
These are not the droids you are looking for. Move along.

[Erik Jones]

On Sep 14, 2007, at 11:54 PM, David Trudgett wrote:

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

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

Several languages use the "object.method(args)" form, which is
syntactic
sugar for "method(object, other_args)" which Ada, for instance, uses.
Knowing this clears up half the confusion (the object /is/ passed as a
parameter whichever syntax is used).

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

Yes, that is really the crux of the issue, though. While the former
may be syntactic sugar for the latter, once any syntactic sugar has
become prevalent enough, it becomes the expected norm and the latter
becomes clutter or, at best, awkward. It's something that really
just takes a little use until you get to the point where you don't
usually think of it but, every so often, the thought creeps in. I'm
not complaining, just pointing out if you step out of this particular
box, you'll realize that it really is a pointless one. Saying,
"because that's how Python does it" may be the only valid reason, but
that argument is about on par with a six year old's "just because...".

Erik Jones

Software Developer | Emma®
er**@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

[Bruno Desthuilliers]

Erik Jones a écrit :

On Sep 14, 2007, at 11:54 PM, David Trudgett wrote:

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

(snip)

>>
Several languages use the "object.method(args)" form, which is syntactic
sugar for "method(object, other_args)" which Ada, for instance, uses.
Knowing this clears up half the confusion (the object /is/ passed as a
parameter whichever syntax is used).

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

Yes, that is really the crux of the issue, though. While the former
may be syntactic sugar for the latter, once any syntactic sugar has
become prevalent enough, it becomes the expected norm

Being "the expected norm" is not enough to qualify has "being the right
thing to do".

and the latter
becomes clutter or, at best, awkward.

Until you want to dynamically add some generic function taking an object
as first arg as a method of a class or instance. Exposing most of the
inner working of it's object model is one of the greatest strength of
Python. And that's one of the reasons I (and probably other people here)
like this language.

It's something that really just
takes a little use until you get to the point where you don't usually
think of it but, every so often, the thought creeps in. I'm not
complaining, just pointing out if you step out of this particular box,
you'll realize that it really is a pointless one. Saying, "because
that's how Python does it" may be the only valid reason, but that
argument is about on par with a six year old's "just because...".

If you really think the only rationale for this is "just because", then
you're missing something IMHO.

[TheFlyingDutchman]

>
<Ironic>

Hi, I'm new to Python, I don't even fully know the language, never done
a full project in Python. What's more, probably I'll never will.
But that's not the point, the point is I want YOU people to modify the
language you know in and out, the program with which you've done many
systems, I want you to change it to suit my whims, so that I'll be
comfortable with the 3 ten liners I'll write.
TIA

</Ironic>

<Zobionic>
Hi, I've used Python and have fallen in love with it. I know exactly
how Guido pronounces his name and since I saw him use the obtuse
phrase syntactic sugar I try and work it into every discussion I have
on Python syntax. I hate it when anyone offers criticism of Guido's
language. I have a picture of Bruce Eckel with a red universal not
sign over it on my wall and I throw my mechanical pencils at it every
night. I am especially upset when someone talks bad about kluges like
@staticmethod or FunctionName = staticmethod(FunctionName). Sure "def
static" or "static def" would be so much cleaner, simpler and clearer
but let's face it my fellow Pythonistas, this language may have
started out based on what was easy for people to learn and use but
we're in Nerdville now and clean and clear have become roadblocks! I
have so much more respect for Perl and the way it developed now!
</Zombionic>

[TheFlyingDutchman]

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

They can be told all they want by the compiler/runtime - implicitly -
under-the-covers, out-of-sight.

[Steve Holden]

TheFlyingDutchman wrote:

>The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

They can be told all they want by the compiler/runtime - implicitly -
under-the-covers, out-of-sight.

I wish you would keep these deep insightful comments to yourself. Your
knowledge of the interpreter internals appears to be based on
examination by crystal ball.

You conveniently ignore the fact that the situation described by David
Trudgett (and, by the way, your quoting with no attributions is also
becoming tiresome very quickly) is a *design choice*, not a mistake.
It's done precisely to make an explicit reference to the instance
available to methods.

You also conveniently ignore the fact that changing tis would also
change other aspects of the language, such as the ability to graft
functions into instances and classes as methods.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

[Robin Becker]

Graham Dumpleton wrote:

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

........

Well I have been trying out a system very like PP. For various reasons I prefer
to write my own scheduler based on more traditional code, but it's very easy to
get SSH based workers going. Agreed it's a noddy system, but I find the
following timings for the pp callback demo with start=1, end=200000000.

All the workers are similar to a pp local worker, but some are controlled via
ssh and hence have to be initialised by an argument like -c"exec input()" which
downloads some bootstrap code; I find that an easy way to utilize a server which
already has ssh.

The local workers are clearly dominant, but even though app1,app3,app4 are not
in the same country they can still be used to provide useful work.

I suspect most people won't want to use either ssh or socket based workers when
64 cpu machines arrive. The worker farm topology is also a bit wrong for
massively parallel stuff.

################################################## ##############
Starting scheduler with 1 workers(1 local)
Partial sum is 0.69314718306 | diff = -2.50006693125e-009
Job execution statistics:
job count | % of all jobs | job time sum | time per job | worker
128 | 100.00 | 59.7190 | 0.466555 | local:3676
128 | 100.00 | 59.7190 | 0.466555 | all local
128 | 100.00 | 59.7190 | 0.466555 | total
Time elapsed since scheduler creation 59.7820000648
Real average time 0.467046875507
Starting scheduler with 2 workers(2 local)
Partial sum is 0.69314718306 | diff = -2.50006693125e-009
Job execution statistics:
job count | % of all jobs | job time sum | time per job | worker
64 | 50.00 | 31.5300 | 0.492656 | local:324
64 | 50.00 | 31.2190 | 0.487797 | local:3684
128 | 100.00 | 62.7490 | 0.490227 | all local
128 | 100.00 | 62.7490 | 0.490227 | total
Time elapsed since scheduler creation 31.5460000038
Real average time 0.24645312503
Starting scheduler with 3 workers(2 local)
Partial sum is 0.69314718306 | diff = -2.50006704228e-009
Job execution statistics:
job count | % of all jobs | job time sum | time per job | worker
53 | 41.41 | 25.6580 | 0.484113 | local:2392
52 | 40.63 | 25.5150 | 0.490673 | local:416
23 | 17.97 | 24.2500 | 1.054348 | ssh:RLUK_robin:20457
105 | 82.03 | 51.1730 | 0.487362 | all local
128 | 100.00 | 75.4230 | 0.589242 | total
Time elapsed since scheduler creation 25.7349998951
Real average time 0.20105468668
Starting scheduler with 4 workers(2 local)
Partial sum is 0.69314718306 | diff = -2.50006704228e-009
Job execution statistics:
job count | % of all jobs | job time sum | time per job | worker
46 | 35.94 | 22.2200 | 0.483043 | local:2328
46 | 35.94 | 22.4670 | 0.488413 | local:3580
21 | 16.41 | 22.3150 | 1.062619 | ssh:RLUK_robin:20500
15 | 11.72 | 21.9730 | 1.464867 | ssh:app1:3549
92 | 71.88 | 44.6870 | 0.485728 | all local
128 | 100.00 | 88.9750 | 0.695117 | total
Time elapsed since scheduler creation 23.0320000648
Real average time 0.179937500507

Starting scheduler with 5 workers(2 local)
Partial sum is 0.69314718306 | diff = -2.50006704228e-009
Job execution statistics:
job count | % of all jobs | job time sum | time per job | worker
40 | 31.25 | 19.3600 | 0.484000 | local:1376
41 | 32.03 | 19.7030 | 0.480561 | local:3608
18 | 14.06 | 19.1090 | 1.061611 | ssh:RLUK_robin:20524
14 | 10.94 | 19.1110 | 1.365071 | ssh:app1:3596
15 | 11.72 | 19.0950 | 1.273000 | ssh:app3:44316
81 | 63.28 | 39.0630 | 0.482259 | all local
128 | 100.00 | 96.3780 | 0.752953 | total
Time elapsed since server creation 19.9850001335
Real average time 0.156132813543

Starting scheduler with 7 workers(2 local)
Partial sum is 0.69314718306 | diff = -2.50006693125e-009
Job execution statistics:
job count | % of all jobs | job time sum | time per job | worker
31 | 24.22 | 14.9540 | 0.482387 | local:2588
31 | 24.22 | 15.0630 | 0.485903 | local:472
13 | 10.16 | 14.0790 | 1.083000 | ssh:RLUK_robin:20548
9 | 7.03 | 14.7680 | 1.640889 | ssh:app1:3626
11 | 8.59 | 14.3260 | 1.302364 | ssh:app3:44344
15 | 11.72 | 14.2990 | 0.953267 | ssh:app4:61396
18 | 14.06 | 14.4050 | 0.800278 | ssh:app5:1258
62 | 48.44 | 30.0170 | 0.484145 | all local
128 | 100.00 | 101.8940 | 0.796047 | total
Time elapsed since scheduler creation 15.2030000687
Real average time 0.118773438036
################################################## ##############
--
Robin Becker

[TheFlyingDutchman]

On Sep 17, 4:02 am, Steve Holden <[e-mail]:

TheFlyingDutchman wrote:

The other half of the confusion is cleared up by considering that
Python methods are ordinary functions that don't magically "know" in
which "class" context they are executing: they must be told via the
first parameter.

They can be told all they want by the compiler/runtime - implicitly -
under-the-covers, out-of-sight.

I wish you would keep these deep insightful comments to yourself. Your
knowledge of the interpreter internals appears to be based on
examination by crystal ball.

I am not talking about the way it does it, but rather, the way it
could do it or... could have done it. That requires no knowledge of
how the interpreter currently does it unless I am proposing something
that no interpreter in the world could ever do.

>
You conveniently ignore the fact that the situation described by David
Trudgett (and, by the way, your quoting with no attributions is also
becoming tiresome very quickly) is a *design choice*, not a mistake.
It's done precisely to make an explicit reference to the instance
available to methods.

For your own information, supercilious references to the interpreter
internals become tiresome quickly.

I made a complaint about a small design choice. I also made it in the
past tense at least once ("should have done it") and explicitly
expressed that I knew it wasn't going to happen. Python was created
based on a language that was designed to make it easy to use by
beginners. Doing so made it a clean and clear language. My preference
is for everything to be as clean and clear as possible. If I didn't
I'd never have bothered with Python since Perl is much more popular
among programmers I have come across.

Jury-rigging new features is going to make the elite happy but very
likely will be viewed differently by us average programmers.

change other aspects of the language, such as the ability to graft
functions into instances and classes as methods.

Those are elite-type features that make code harder to understand by
average programmers and probably the elite as well. To paraphrase
someone "He thought he'd solve the problem by grafting functions into
classes and grafting classes into methods. Then he had two problems".

[Aahz]

In article <46***********************@news.free.fr>,
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>
But what, given that I'm an AOL user still thinking it's kewl to hide
behind a pseudo, what else would you expect ?

What exactly is a "pseudo", pray tell?
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.

[Bruno Desthuilliers]

Aahz a écrit :

In article <46***********************@news.free.fr>,
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>But what, given that I'm an AOL user still thinking it's kewl to hide
behind a pseudo, what else would you expect ?

What exactly is a "pseudo", pray tell?

Sorry : a pseudonym (a nickname).

[Bruno Desthuilliers]

Aahz a écrit :

In article <46***********************@news.free.fr>,
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>Aahz a écrit :

>>In article <46***********************@news.free.fr>,
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:
But what, given that I'm an AOL user still thinking it's kewl to hide
behind a pseudo, what else would you expect ?
What exactly is a "pseudo", pray tell?

Sorry : a pseudonym (a nickname).

You apparently missed the thrust of my sarcasm.

Obviously, yes.

[Ben Finney]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ites:

For the record, I usually don't give a damn about what
name/nickname/whatever peoples use.

With the caveat "... so long as they consistently use one name in a
given context", I concur.

--
\ "I saw a sign: 'Rest Area 25 Miles'. That's pretty big. Some |
`\ people must be really tired." -- Steven Wright |
_o__) |
Ben Finney

[Alex Martelli]

Aahz <aa**@pythoncraft.comwrote:

For that matter, there are plenty of people who are better known by some
nickname that is not their legal name.

Yep. For example, some people whose legal name is "Alessandro" (which
no American is ever going to be able to spell right -- ONE L, TWO S's,
NOT an X or a J instead, "DRO" ending rather than "DER", etc), might
choose to avoid the hassle and go by "Alex" (just to make up a case...).
Alex

[Paddy]

On Sep 19, 5:07 am, [e-mail] (Alex Martelli) wrote:

Aahz <[e-mail]:

For that matter, there are plenty of people who are better known by some
nickname that is not their legal name.

Yep. For example, some people whose legal name is "Alessandro" (which
no American is ever going to be able to spell right -- ONE L, TWO S's,
NOT an X or a J instead, "DRO" ending rather than "DER", etc), might
choose to avoid the hassle and go by "Alex" (just to make up a case...).

Alex

.... and someone whose nickname is Paddy which is very common, and who
finds it hard to remember birthdates decides to add the days in the
month that his first two children were born on to his used name and
now only gets worried near his partners birthday :-)

- Paddy.

[Ron Adam]

TheFlyingDutchman wrote:

I am not talking about the way it does it, but rather, the way it
could do it or... could have done it. That requires no knowledge of
how the interpreter currently does it unless I am proposing something
that no interpreter in the world could ever do.

Yes, there are a couple of things that could have been changed. But from
what I can tell there are a number of reasons why things where chosen to be
the way they are.

Two of those reasons is to make the core C code smaller and easier to
maintain and also to make it easier to understand how things work.
Exposing the inner workings as visible python code vs hidden C code helps
both of those.

Another benefit of exposing more of the class machinery of Pythons objects
as python code, is it makes it possible to modify more of how things work
directly with python code. A good way to see how this works is studying
how descriptors and properties work.

http://users.rcn.com/python/download/Descriptor.htm

You will find there is much more of python written in python than it may
first seem. In some cases the built in classes and modules are written in
C, yet they still work as if they are written in Python.

So if you can find a way to do things like removing self in python in such
a way that it doesn't require adding more to the Core interpreter, then it
might be considered.

What I've found is as my skills improve, I take more advantage of being
able to modify and/or introspect how things work. This allows more choices
on how I might solve a particular problem.

I also think there a lots of improvements that could be made to other parts
of python such as the libraries that would be of much more practical benefit.

Regards,
Ron

[Ron Adam]

TheFlyingDutchman wrote:

I am not talking about the way it does it, but rather, the way it
could do it or... could have done it. That requires no knowledge of
how the interpreter currently does it unless I am proposing something
that no interpreter in the world could ever do.

Yes, there are a couple of things that could have been changed. But from
what I can tell there are a number of reasons why things where chosen to be
the way they are.

Two of those reasons is to make the core C code smaller and easier to
maintain and also to make it easier to understand how things work.
Exposing the inner workings as visible python code vs hidden C code helps
both of those.

Another benefit of exposing more of the class machinery of Pythons objects
as python code, is it makes it possible to modify more of how things work
directly with python code. A good way to see how this works is studying
how descriptors and properties work.

http://users.rcn.com/python/download/Descriptor.htm

You will find there is much more of python written in python than it may
first seem. In some cases the built in classes and modules are written in
C, yet they still work as if they are written in Python.

So if you can find a way to do things like removing self in python in such
a way that it doesn't require adding more to the Core interpreter, then it
might be considered.

What I've found is as my skills improve, I take more advantage of being
able to modify and/or introspect how things work. This allows more choices
on how I might solve a particular problem.

I also think there a lots of improvements that could be made to other parts
of python such as the libraries that would be of much more practical benefit.

Regards,
Ron

[Bruno Desthuilliers]

Ron Adam a écrit :

>

TheFlyingDutchman wrote:

>I am not talking about the way it does it, but rather, the way it
could do it or... could have done it. That requires no knowledge of
how the interpreter currently does it unless I am proposing something
that no interpreter in the world could ever do.

(snip)

So if you can find a way to do things like removing self in python in
such a way that it doesn't require adding more to the Core interpreter,
then it might be considered.

By who ? As far as I'm concerned, I don't want 'self' to be removed, and
I'm probably not the only one here.

>
What I've found is as my skills improve, I take more advantage of being
able to modify and/or introspect how things work. This allows more
choices on how I might solve a particular problem.

The changes required by removing self would make most of this either
painfull or near impossible AFAICT.

I also think there a lots of improvements that could be made to other
parts of python such as the libraries that would be of much more
practical benefit.

indeed.

[Ron Adam]

Bruno Desthuilliers wrote:

Ron Adam a écrit :

>>
TheFlyingDutchman wrote:

>>I am not talking about the way it does it, but rather, the way it
could do it or... could have done it. That requires no knowledge of
how the interpreter currently does it unless I am proposing something
that no interpreter in the world could ever do.

(snip)

>So if you can find a way to do things like removing self in python in
such a way that it doesn't require adding more to the Core interpreter,
then it might be considered.

By who ? As far as I'm concerned, I don't want 'self' to be removed, and
I'm probably not the only one here.

The term "might be considered" in this case is a very very small
possibility. It would need to be a very good solution which has some very
nice benifits over the current way. As you say below, it's probably not
possible.

This was more of a challenge to get anyone who thinks it's worth doing to
learn more about how python works rather than just propose arbitrary ideas.

>What I've found is as my skills improve, I take more advantage of being
able to modify and/or introspect how things work. This allows more
choices on how I might solve a particular problem.

The changes required by removing self would make most of this either
painfull or near impossible AFAICT.

Right, It would have a cascade effect in many places.

>I also think there a lots of improvements that could be made to other
parts of python such as the libraries that would be of much more
practical benefit.

indeed.

Cheers,
Ron