Re: Python 3K or Python 2.9?

[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




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Bruno Desthuilliers]

Aahz a écrit :
> In article <[EMAIL PROTECTED]>,
> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
> 
(snip)
>(For those joining only recently, my full legal name is "Aahz", which I
>changed from my former name precisely because of attitudes like Bruno's.)
>>
>>For the record, I usually don't give a damn about what
>>name/nickname/whatever peoples use.
> 
> 
> Then why mention pseudonyms at all?

My fault - I'm sometimes a bit overreactive, and Mr TheFlyingDutchman, 
(aka zzbbaadd) was starting to get on my nerves. I know I shouldn't have 
post this one, and I apologize.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Aahz]

In article <[EMAIL PROTECTED]>,
Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>Aahz a écrit :
>> In article <[EMAIL PROTECTED]>,
>> Steve Holden  <[EMAIL PROTECTED]> wrote:
>>> Aahz wrote:
 In article <[EMAIL PROTECTED]>,
 Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
> Aahz a écrit :
>> In article <[EMAIL PROTECTED]>,
>> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>>> 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.  You can't tell what is
 or is not a pseudonym online.  For all I know, "Bruno Desthulliers" is a
 pseudonym.  While I recognize that there is some social advantage to
 linking consistent identifiers with people, I have I think understandable
 irritation with people who insist that names follow certain patterns.

 (For those joining only recently, my full legal name is "Aahz", which I
 changed from my former name precisely because of attitudes like Bruno's.)
>
>For the record, I usually don't give a damn about what
>name/nickname/whatever peoples use.

Then why mention pseudonyms at all?
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Bruno Desthuilliers]

Aahz a écrit :
> In article <[EMAIL PROTECTED]>,
> Steve Holden  <[EMAIL PROTECTED]> wrote:
>> Aahz wrote:
>>> In article <[EMAIL PROTECTED]>,
>>> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
 Aahz a écrit :
> In article <[EMAIL PROTECTED]>,
> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>> 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.  You can't tell what is
>>> or is not a pseudonym online.  For all I know, "Bruno Desthulliers" is a
>>> pseudonym.  While I recognize that there is some social advantage to
>>> linking consistent identifiers with people, I have I think understandable
>>> irritation with people who insist that names follow certain patterns.
>>>
>>> (For those joining only recently, my full legal name is "Aahz", which I
>>> changed from my former name precisely because of attitudes like Bruno's.)

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

>> ... coupled with a certain bloody-mindedness that forces you to rub 
>> people's noses in your ability to choose to do so? ;-)
> 
> While there's certainly some truth to that, it is also the case that I
> have seen people like Bruno take exception to some people's born names.
> After all, there are people whose parents chose to name them "Moon Unit".

But then adding the lastname (ie 'Zappa') could clear the possible 
confusion !-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Bruno Desthuilliers]

Aahz a écrit :
> In article <[EMAIL PROTECTED]>,
> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>> Aahz a écrit :
>>> In article <[EMAIL PROTECTED]>,
>>> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
 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.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Aahz]

In article <[EMAIL PROTECTED]>,
Steve Holden  <[EMAIL PROTECTED]> wrote:
>Aahz wrote:
>> In article <[EMAIL PROTECTED]>,
>> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>>> Aahz a écrit :
 In article <[EMAIL PROTECTED]>,
 Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>
> 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.  You can't tell what is
>> or is not a pseudonym online.  For all I know, "Bruno Desthulliers" is a
>> pseudonym.  While I recognize that there is some social advantage to
>> linking consistent identifiers with people, I have I think understandable
>> irritation with people who insist that names follow certain patterns.
>> 
>> (For those joining only recently, my full legal name is "Aahz", which I
>> changed from my former name precisely because of attitudes like Bruno's.)
> 
>... coupled with a certain bloody-mindedness that forces you to rub 
>people's noses in your ability to choose to do so? ;-)

While there's certainly some truth to that, it is also the case that I
have seen people like Bruno take exception to some people's born names.
After all, there are people whose parents chose to name them "Moon Unit".

For that matter, there are plenty of people who are better known by some
nickname that is not their legal name.  And even before I changed my
name, I had plenty of problems from people believing that my name was a
nickname and "helpfully" fixing it.  (Which is really where my attitude
comes from, and the practical difficulties of having only one legal name
are not that much larger than my former difficulties.)  Overall, I think
that Bruno's attitude is more injurious to community than letting people
be known by whatever name they choose.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Steve Holden]

Aahz wrote:
> In article <[EMAIL PROTECTED]>,
> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>> Aahz a écrit :
>>> In article <[EMAIL PROTECTED]>,
>>> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
 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.  You can't tell what is
> or is not a pseudonym online.  For all I know, "Bruno Desthulliers" is a
> pseudonym.  While I recognize that there is some social advantage to
> linking consistent identifiers with people, I have I think understandable
> irritation with people who insist that names follow certain patterns.
> 
> (For those joining only recently, my full legal name is "Aahz", which I
> changed from my former name precisely because of attitudes like Bruno's.)
> 
... coupled with a certain bloody-mindedness that forces you to rub 
people's noses in your ability to choose to do so? ;-)

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline
-- 
http://mail.python.org/mailman/listinfo/python-list

Using pseudonyms (was Re: Python 3K or Python 2.9?)

[Aahz]

In article <[EMAIL PROTECTED]>,
Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>Aahz a écrit :
>> In article <[EMAIL PROTECTED]>,
>> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>>>
>>> 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.  You can't tell what is
or is not a pseudonym online.  For all I know, "Bruno Desthulliers" is a
pseudonym.  While I recognize that there is some social advantage to
linking consistent identifiers with people, I have I think understandable
irritation with people who insist that names follow certain patterns.

(For those joining only recently, my full legal name is "Aahz", which I
changed from my former name precisely because of attitudes like Bruno's.)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

Aahz a écrit :
> In article <[EMAIL PROTECTED]>,
> Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>> 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).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Aahz]

In article <[EMAIL PROTECTED]>,
Bruno Desthuilliers  <[EMAIL PROTECTED]> wrote:
>
>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 ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :
> On Sep 17, 4:02 am, Steve Holden <[EMAIL PROTECTED]> wrote:
(snip)

> I made a complaint about a small design choice.

It's by no mean 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.

Most beginners still find Python easy to use AFAICT. At least, I know a 
lot of *non* programmers using it.

> Doing so made it a clean and clear language. My preference
> is for everything to be as clean and clear as possible. 

Mine too, and that's why I like Python the way it is : syntactic sugar 
for the common cases, *and* and easy way to play with lower levels when 
necessary.

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

"us" ? Who is "us" ?

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

Good news, there's a language designed exactly for "average programmers" 
that find these kind of features - as well as anything as complex as 
operator overloading, metaclasses, descriptors, higher order functions, 
multiple inheritance, lazy evaluation, and anything dynamic - way too 
"elite". It's named Java. The only drawback is that instead of "elite 
features", you'll have to resort to mumbo-jumbo overcomplexified "design 
patterns" and write ten times more code to solve the simplest things.

To make a long story short: if you don't understand some "advanced" 
Python's features, then just don't use them. But have mercy and let us 
"elite programmers" (lol...) use more of Python's power.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 17, 4:02 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> 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".

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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=2.

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.782648
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.546038
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.032648
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 | 

Re: Python 3K or Python 2.9?

[Daniel Larsson]

On 9/13/07, Stefan Bellon <[EMAIL PROTECTED]> wrote:
>
> 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 that's debatable :)

"SIMULA 67 was formally standardized on the first meeting of the SIMULA
Standards Group (SSG) in February 1968."

 http://en.wikipedia.org/wiki/Simula
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :
> 
> If you wanna know why the Renault Dauphine requires the driver to pull
> down on the rearview mirror in order to shift into reverse you simply
> need to open the hood and remove the engine and disassemble the
> transmission and you will see that it has no way of distinguishing a
> shift into third from a shift into reverse without a rearview mirror
> pull. But these days most people just open the glove compartment when
> shifting into reverse which works just as well!
>  

Very interesting engineering problem. But a bit out of date and totally 
unrelated to Python. Anything else ?
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Python 3K or Python 2.9?

[Delaney, Timothy (Tim)]

Ben Finney wrote:

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

Only in the case that "instance" is an instance of "Class", and not an
instance of a subclass of "Class". For example, the following are not
equivalent:

class A(object):
def func(self):
print 'A'

class B(A):
def func(self):
super(B, self).func()
print 'B'

a = A()
b = B()

A.func(a)
A.func(b)
B.func(b)
a.func()
b.func()

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

If you wanna know why the Renault Dauphine requires the driver to pull
down on the rearview mirror in order to shift into reverse you simply
need to open the hood and remove the engine and disassemble the
transmission and you will see that it has no way of distinguishing a
shift into third from a shift into reverse without a rearview mirror
pull. But these days most people just open the glove compartment when
shifting into reverse which works just as well!
 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :
>> 
>>
>> 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
>>
>> 
> 
> 
> 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!
> 
> 


Hi, I'm totally unable to understand the difference between higher order 
functions and language statements, nor why the first approach is way 
better than the second. I'm totally clueless about Python's object model 
despite many posts explaining it and pointing to relevant documentation. 
And, ho, yes, I don't even understand the expression "syntactic sugar", 
but I guess it must some dummy concept invented by the guy that wrote 
Python whatever his name might be.

So I insist on posting that all this is a kludge and that Python should 
be how I think it could be instead of trying to understand why it is the 
way it is and why people actually using it like the way it is.

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

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


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!


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

Erik Jones a écrit :
> On Sep 14, 2007, at 11:54 PM, David Trudgett wrote:
> 
>> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
>>
(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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

John Roth a écrit :
> On Sep 12, 11:35 am, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
> 
>>On Sep 12, 4:40 am, Bjoern Schliessmann <[EMAIL PROTECTED]> wrote:
>>
>>>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.

I suppose that by header, you mean prototype or signature. But anyway, 
it's not a *method* signature, it's a *function* signature - and the 
compiler persists to have nothing to do with all this...

> 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), 

"those silly @ things" has *nothing* to do with methods nor with 
attributes. It's just syntactic sugar for HOFs. Period.

> thus showing that unneeded complexity breeds more unneeded
> complexity.

John, there are plenty of other OOPls around that don't requires neither 
explicit use of the instance/class reference nor mention of it in the 
function . If after having read this whole thread and all relevant 
documentation, you still don't understand why Python works that way and 
why most of us are *totally* happy with the way it works, I strongly 
suggest that you switch to another language. Not that I have nothing 
personal against you, but it should be quite clear that this part of 
Python is not going to change - FWIW, as Alex pointed out, I doubt even 
GvR could impose such a change now.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Erik Jones]

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

> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
>
>> 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®
[EMAIL PROTECTED]
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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[David Trudgett]

TheFlyingDutchman <[EMAIL PROTECTED]> writes:

> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Ricardo Aráoz]

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.



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





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[George Sakkis]

On Sep 12, 1:35 pm, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:

> On Sep 12, 4:40 am, Bjoern Schliessmann <[EMAIL PROTECTED]> wrote:
> > 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/weblog/arch_d7_2006_12_16.shtml#e583

George

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[John Roth]

On Sep 12, 11:35 am, TheFlyingDutchman <[EMAIL PROTECTED]> wrote:
> On Sep 12, 4:40 am, Bjoern Schliessmann <[EMAIL PROTECTED]> wrote:
> > 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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Terry Reedy]

"Bjoern Schliessmann" <[EMAIL PROTECTED]> wrote 
in message news:[EMAIL PROTECTED]
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



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Duncan Booth]

Piet van Oostrum <[EMAIL PROTECTED]> wrote:

>> Ben Finney <[EMAIL PROTECTED]> (BF) wrote:
> 
>>BF> The latter two statements are equivalent. The
>>'instance.method(args)' BF> syntax 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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_ATTR1 (meth)
>   6 CALL_FUNCTION0
>   9 RETURN_VALUE
> 
> The function gets wrapped as a bound method as part of LOAD_ATTR. 
> When the compiler sees (args), it does not know and does not
> care about the
> particular type that  will 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)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bjoern Schliessmann]

Bruno Desthuilliers wrote:
> A method is a thin wrapper around a function, usually instanciated
> and returned by the __get__ method [1] of the function itself when
> the function is looked up as an attribute of a class or an
> instance:
> [...]

That's interesting, thank you for the explanation.

> They aren't, and you should perhaps read the manual - all this is
> documented.

Found it. :)
 
Regards,


Björn

-- 
BOFH excuse #144:

Too few computrons available.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

Bjoern Schliessmann a écrit :
> 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?

A method is a thin wrapper around a function, usually instanciated and 
returned by the __get__ method [1] of the function itself when the 
function is looked up as an attribute of a class or an instance:

 >>> class Foo(object):
... def meth(self):
... print "in %s meth" % self
...
 >>> Foo.__dict__['meth']

 >>> Foo.meth

 >>> Foo().meth
>
 >>>

[1] you may want to read about the descriptor protocol which is the base 
mechanism on which methods and properties (computed attributes) are based.

>> (ok, I know, you meant "functions declared within a class
>> statement").
> 
> I think that those functions _are_ special ones

They aren't, and you should perhaps read the manual - all this is 
documented.

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

Once again, the compiler has *nothing* to do with this. Else, how could 
you do this:

 >>> def fun(obj):
... print obj
...
 >>> Foo.fun = fun
 >>> Foo.fun

 >>> Foo().fun
>
 >>> fun

 >>> Foo.__dict__['fun']

 >>>


> So IMHO, "method definition" makes sense.

It doesn't.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Terry Reedy]

"Bjoern Schliessmann" <[EMAIL PROTECTED]> wrote 
in message news:[EMAIL PROTECTED]
|> - 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 class> statement").

| 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_ATTR1 (meth)
  6 CALL_FUNCTION0
  9 RETURN_VALUE

The function gets wrapped as a bound method as part of LOAD_ATTR.  When the 
compiler sees (args), it does not know and does not care about the 
particular type that  will 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_FUNCTION0
  6 RETURN_VALUE

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

Terry Jan Reedy





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Aahz]

In article <[EMAIL PROTECTED]>,
Alex Martelli <[EMAIL PROTECTED]> wrote:
>Chris Mellon <[EMAIL PROTECTED]> wrote:
>> 
>> 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 ([EMAIL PROTECTED])   <*> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Aahz]

In article <[EMAIL PROTECTED]>,
Ben Finney  <[EMAIL PROTECTED]> wrote:
>
>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 ([EMAIL PROTECTED])   <*> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Terry Reedy]

"TheFlyingDutchman" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| 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.

 



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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").
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

>
> > Here is a link to a tutorial where Sun is talking about the this
> > reference:
> >http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html
>
> That's a tutorial for getting you started, no reference
> documentation or in-depth course.
>
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."



"this" is hard to query on but I would be interested in seeing some
site talking about Java where "this" is mentioned as being "passed
in".



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Alex Martelli]

TheFlyingDutchman <[EMAIL PROTECTED]> 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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bjoern Schliessmann]

TheFlyingDutchman wrote:

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

Ah, okay.
 
> 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.

Mh, in my book, there is (quickly translated from german):

| Instance pointer (C++ only) 
| 
| The /this/ pointer is a feature of all non-static class methods.
| Every non static method is extended internally by a /this/
| argument. To that argument the compiler passes a pointer to the
| instance for which the method is being called.
(Dirk Louis, C/C++-Kompendium, Markt&Technik-Verlag, 2000)

And that's only from the pointer chapter. The OOP chapters are more
detailed. And no, it's no book about compiler architecture, it's a
compendium.

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

That's a tutorial for getting you started, no reference
documentation or in-depth course.

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

In a language like C++ it is beneficial to know some inner
workings -- in the same way like it's beneficial to know some inner
workings of a computer if you want to use it.

BTW, C is not for nothing called "portable assembler" :)

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

I don't know if it's just me, but I tend to understand stuff like
virtual methods much better if I know *why* they exist, and not
just *that* they do. That makes judging if and when I need them
easier.

Regards,


Björn

-- 
BOFH excuse #192:

runaway cat on system.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Piet van Oostrum]

> Ben Finney <[EMAIL PROTECTED]> (BF) wrote:

>BF> The latter two statements are equivalent. The 'instance.method(args)'
>BF> syntax 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 <[EMAIL PROTECTED]>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Piet van Oostrum]

> TheFlyingDutchman <[EMAIL PROTECTED]> (T) wrote:

>T> The confusing way about the current Python method when you first
>T> encounter it is
>T>  why is "self" being passed in when you write the function but not
>T> when 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 <[EMAIL PROTECTED]>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Bruno Desthuilliers]

TheFlyingDutchman a écrit :
> On Sep 12, 4:40 am, Bjoern Schliessmann  [EMAIL PROTECTED]> wrote:
>> 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()

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Ben Finney]

TheFlyingDutchman <[EMAIL PROTECTED]> writes:

(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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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"?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Ben Finney]

"Peter Decker" <[EMAIL PROTECTED]> writes:

> On 9/12/07, Ben Finney <[EMAIL PROTECTED]> wrote:
> > 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Ben Finney]

TheFlyingDutchman <[EMAIL PROTECTED]> writes:

> 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 "", 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Peter Decker]

On 9/12/07, Ben Finney <[EMAIL PROTECTED]> wrote:
> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
>
> > 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 12, 5:47 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > 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.




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Ben Finney]

TheFlyingDutchman <[EMAIL PROTECTED]> writes:

> 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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

On Sep 12, 3:53 pm, Bjoern Schliessmann  wrote:
> 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/tutorial/java/javaOO/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. ;)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[TheFlyingDutchman]

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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Alex Martelli]

Chris Mellon <[EMAIL PROTECTED]> wrote:
   ...
> > 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Chris Mellon]

On 9/12/07, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Duncan Booth <[EMAIL PROTECTED]> wrote:
>...
> > 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++.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Alex Martelli]

Duncan Booth <[EMAIL PROTECTED]> wrote:
   ...
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Duncan Booth]

Ivan Voras <[EMAIL PROTECTED]> 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 
'.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).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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/viewpost.jsp?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.




signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[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/viewpost.jsp?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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Graham Dumpleton]

On Sep 12, 2:14 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Paul Rubin  writes:
> > TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > > Python user and advocate Bruce Eckel is disappointed with the
> > > additions (or lack of additions) in Python 3:
>
> > >http://www.artima.com/weblogs/viewpost.jsp?thread=214112
>
> > That article is pretty weak.
>
> It is responded to by Guido here:
>
>"A Response to Bruce Eckel"
> 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/parallel-python-discussion-and-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/commodity-shared-hosting-and-modwsgi.html

Graham


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Ben Finney]

Paul Rubin  writes:

> TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> > Python user and advocate Bruce Eckel is disappointed with the
> > additions (or lack of additions) in Python 3:
> > 
> > http://www.artima.com/weblogs/viewpost.jsp?thread=214112
> 
> That article is pretty weak.

It is responded to by Guido here:

   "A Response to Bruce Eckel"
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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

[Paul Rubin]

TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> Python user and advocate Bruce Eckel is disappointed with the
> additions (or lack of additions) in Python 3:
> 
> http://www.artima.com/weblogs/viewpost.jsp?thread=214112

That article is pretty weak.
-- 
http://mail.python.org/mailman/listinfo/python-list

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/viewpost.jsp?thread=214112

-- 
http://mail.python.org/mailman/listinfo/python-list