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

 

[Paul Rubin]

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.

 

[Ben Finney]

That article is pretty weak.

It is responded to by Guido here:

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

 

[Graham Dumpleton]

It is responded to by Guido here:

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

In that blog, Guido says:

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

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

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

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

http://blog.dscpl.com.au/2007/09/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

 

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

 

[Ivan Voras]

TheFlyingDutchman a écrit :

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

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFG58DJldnAQVacBcgRA6lpAKCoGSO09VcoJUQEhCurF71GiawZqQCgn3ey
XThFOTV2AWN/i3LkfXhBDXw=
=bpRc
-----END PGP SIGNATURE-----

 

[Bjoern Schliessmann]

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

 

[Stefan Behnel]

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

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

Stefan

 

[Duncan Booth]

Python's

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

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

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

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

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

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

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

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

class C:
def method(self): pass

and

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

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

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

Another area to consider is what happens when I do:

foo = FooClass()

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

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

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

 

[Alex Martelli]

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

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

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

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

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

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

class C:
def method(self): pass

and

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

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

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

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

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

Another area to consider is what happens when I do:

foo = FooClass()

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

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

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

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

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

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


Alex

 

[Chris Mellon]

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


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


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

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

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

 

[Alex Martelli]

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

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

What would happen to stuff
like inspect.getargspec?

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

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

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

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

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

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


Alex

 

[TheFlyingDutchman]

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

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

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

not

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


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

a = MyClass()
a.SomeFunction(12)

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

 

[TheFlyingDutchman]

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

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

not

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

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

a = MyClass()
a.SomeFunction(12)

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

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

 

[Bjoern Schliessmann]

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

 

[Bjoern Schliessmann]

Bjoern Schliessmann wrote:


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

Umm, why? I didn't introduce it.

Regards,


Björn

 

[TheFlyingDutchman]

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

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

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

 

[Ben Finney]

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

 

[TheFlyingDutchman]

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

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

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

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


a = MyClass()

my_method(a,someParameter)

Then it makes sense to me to talk about it.

 

[Peter Decker]

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