Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:
additions (or lack of additions) in Python 3:
-
-
Re: Python 3K or Python 2.9?
TheFlyingDutchm an <zzbbaadd@aol.c omwrites:That article is pretty weak.Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:
>
http://www.artima.com/weblogs/viewpo...?thread=214112
-
Re: Python 3K or Python 2.9?
Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:
It is responded to by Guido here:TheFlyingDutchm an <zzbbaadd@aol.c omwrites:>Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:
http://www.artima.com/weblogs/viewpo...?thread=214112
That article is pretty weak.
"A Response to Bruce Eckel"
<URL:http://www.artima.com/weblogs/viewpost.jsp?th read=214325>
--
\ "The trouble with eating Italian food is that five or six days |
`\ later you're hungry again." -- George Miller |
_o__) |
Ben Finney
Comment
-
Re: Python 3K or Python 2.9?
On Sep 12, 2:14 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:In that blog, Guido says:Paul Rubin <http://phr...@NOSPAM.i nvalidwrites:>>TheFlyingDutchm an <zzbba...@aol.c omwrites:Python user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:>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?th read=214325>
"""Concurre ncy: 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:
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:
Graham
Comment
-
Re: Python 3K or Python 2.9?
TheFlyingDutchm an a écrit :I'd say Mr Eckel fails to graps some of the great points about Python'sPython user and advocate Bruce Eckel is disappointed with the
additions (or lack of additions) in Python 3:
>
>
object model - the rant about the use of 'self' is a sure clue.
Comment
-
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote:What does "self" have to do with an object model? It's anTheFlyingDutchm an a écrit :I'd say Mr Eckel fails to graps some of the great points about Python's>Python user and advocate Bruce Eckel is disappointed with the
>additions (or lack of additions) in Python 3:
>>
>http://www.artima.com/weblogs/viewpo...?thread=214112
object model - the rant about the use of 'self' is a sure clue.
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
iD8DBQFG58DJldn AQVacBcgRA6lpAK CoGSO09VcoJUQEh CurF71GiawZqQCg n3ey
XThFOTV2AWN/i3LkfXhBDXw=
=bpRc
-----END PGP SIGNATURE-----
Comment
-
Re: Python 3K or Python 2.9?
Ivan Voras wrote:
If this was needless, why do C++ and Java have the "this" pointer?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.
Regards,
Björn
--
BOFH excuse #390:
Increased sunspot activity.
Comment
-
Re: Python 3K or Python 2.9?
Bjoern Schliessmann wrote:Be careful when you use the word "needless" in the context of Java.>>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?
Stefan
Comment
-
Re: Python 3K or Python 2.9?
Ivan Voras <ivoras@_fer.hr _wrote:
Python's>I'd say Mr Eckel fails to graps some of the great points aboutit'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 thatYou could add some syntax to Python such that '.x' was equivalent toneedless noise in a language.
'<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).
Comment
-
Re: Python 3K or Python 2.9?
Duncan Booth <duncan.booth@i nvalid.invalidw rote:
...Actually you could do the "magic first-parameter insertion" just whenAs 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.
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 boundclass 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
or unbound method object -- indeed. factory.__get__ never gets called
here.
And exactly the same would occur if the self argument was omitted fromclass 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).
the signature and magically inserted when __get__ does its job.
And this non-strictly-technical issue is the only "true" one.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 so they would with the "__get__ does magic" rule, NP.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 it would be with that rule, since staticmethod &c createMy point here is that in Python the magic is clearly defined and
overridable (so we can have static or class methods that act
differently).
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
Comment
-
Re: Python 3K or Python 2.9?
On 9/12/07, Alex Martelli <aleax@mac.comw rote:Duncan Booth <duncan.booth@i nvalid.invalidw rote:
...>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.:
>This would mean that mixing functions and methods would have to be>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.
>
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.getargs pec?
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++.
Comment
-
Re: Python 3K or Python 2.9?
Chris Mellon <arkanes@gmail. comwrote:
......Actually you could do the "magic first-parameter insertion" just when
returning a bound or unbound method object in the function's __get__
special method, and that would cover all of the technical issues youNot particularly -- it would not require anything special that's notThis 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.
required today.
It would return the signature of the function, if asked to analyze aWhat would happen to stuff
like inspect.getargs pec?
function, and the signature of the method, if asked to analyze a method.
Not exactly rocket science, as it happens.
Whether 'self' needs to be explicit as a function's first argument, andBesides, 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 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.
Exactly: the technical objections that are being raised are bogus, andand 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++.
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.getargs pec [!!!], for example;-) is just not the right way to
communicate this state of affairs.
Alex
Comment
-
Re: Python 3K or Python 2.9?
On Sep 12, 4:40 am, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n.. .@spamgourmet.c omwrote:"this" in C++ and Java is not shown in the parameter list, which wasIvan 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?
>
what he was
complaining about. He wants
class MyClass:
def SomeFunction(so meParameter):
self.someParame ter = someParameter
not
class MyClass:
def SomeFunction(se lf, someParameter):
self.someParame ter = 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.
Comment
-
Re: Python 3K or Python 2.9?
In C++ and Java I don't believe "this" is ever referred to as an>
"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(so meParameter):
self.someParame ter = someParameter
>
not
>
class MyClass:
def SomeFunction(se lf, someParameter):
self.someParame ter = 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.
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.
Comment
-
Re: Python 3K or Python 2.9?
TheFlyingDutchm an wrote:
Oh yes, it is. All methods use it as a base address into instances.In C++ and Java I don't believe "this" is ever referred to as an
implicit function parameter.
Implicitly though.
Also, I always like to use it explicitly. There's nothing worse thanIt is a (sometimes necessary) way to reference the object inside
one if it's methods.
to read others' source and not know if it's a global they access or
not.
To which language are you referring here, Python or C++? No matterIf it is in fact a real parameter in the underlying compiled-code
implementation, that knowledge hurts more than it helps.
what, I still don't really understand why it hurted.
Regards,
Björn
--
BOFH excuse #296:
The hardware bus needs a new token.
Comment
Comment