On Thu, 9 Feb 2006 10:35:37 +0100, rumours say that Frithiof Andreas
Jensen [EMAIL PROTECTED] might have written:
If one was trying to detect fanatics of any creed, a certain indicator would
be that they have absolutely no sense of humour - they suffer from a
yet-to-be-described variant of autism
DH [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Frithiof Andreas Jensen wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
Ok, there might be five programmers and one imam. The imam does not like
anything more
But the point is, the current situation is not newbie-friendly (I can
tell, I am a newbie)
I will agree to that, as I consider myself still new. _But_, it's a
stumbling stone only briefly. Get enough nagging error messages, and
you learn and move on. I agree with the grandparent poster that it is
Frithiof Andreas Jensen wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
Ok, there might be five programmers and one imam. The
On 2006-02-08, Ben Wilson [EMAIL PROTECTED] wrote:
But the point is, the current situation is not newbie-friendly (I can
tell, I am a newbie)
I will agree to that, as I consider myself still new. _But_, it's a
stumbling stone only briefly. Get enough nagging error messages, and
you learn and
On 04 Feb 2006 11:03:00 +
[EMAIL PROTECTED] (Jens Theisen) wrote:
n.estner wrote:
Yes, I 100% agree to that point!
But the point is, the current situation is not
newbie-friendly (I can tell, I am a newbie): I declare a
method with 3 parameters but when I call it I only pass
2
Jean-Paul Calderone [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I'm not sure I follow. Surely you're not suggesting that this doesn't
work:
class X:
... def foo(self):
... print 'X.foo', self
...
class A(X):
... pass
...
o =
n.estner wrote:
Yes, I 100% agree to that point!
But the point is, the current situation is not newbie-friendly (I can
tell, I am a newbie): I declare a method with 3 parameters but when I
call it I only pass 2 parameters. That's confusing. If I declare a
member variable, I write: self.x =
Donn Cave wrote:
Quoth [EMAIL PROTECTED]:
| Still see no problem. Of course, it goes without saying that
| Python 2.4 doesn't work this way, but given that it's theoretically
| possible for f(a) to be resolved similarly to a.f, then I really
| do not see what you're seeing here. The
Quoth [EMAIL PROTECTED]:
...
| The first point is: Python has global functions, as well as methods. If
| f(a) should look up f inside a first, that would shadow any global or
| local f. That's bad, because python is dynamically typed, and you
| sometimes down' know what a is. Things like
Terry Hancock [EMAIL PROTECTED] wrote:
On Thu, 02 Feb 2006 19:27:55 -0600
DH [EMAIL PROTECTED] wrote:
But I think most people who don't like the extraneous
'self' in python just consider it a minor inconvenience
and don't even notice it after using python for a while.
After
[EMAIL PROTECTED] wrote:
What do you think?
The impression I get from your suggestion is that you
haven't really understood Python. I'm sure that some
things could be better designed or better documented,
but your suggestions would actually make things worse.
Sorry.
Today, Python has a
That usage (self is second parameter to B.test) is bound
to cause trouble in general, but in this case doesn't have
any effect I can see. The function call test would be
resolved from its first parameter, instance of A, and that
function would return 1. One of us is missing something
here,
Yes, that's what I had in mind when I said it could be made
recursion-safe. It's still not thread-safe, but I think that could be
done too, using thread-local-variables instead of globals.
class TestB:
@memberFunction
def do(x):
z = __ # lambda's shouldn't directly reference
On Fri, 03 Feb 2006 12:00:52 +0100, Magnus Lycka wrote:
Today, Python has a syntactic shortcut. If 'a' is an
instance of class 'A', a.f(x,y,z) is a shortcut for
A.f(a,x,y,z).
It is easy to work around (break?) that behaviour:
class A(object):
def foo(self):
print normal method
First of all, you are using a really poor example of a method,
since it doesn't use any attributes of the Foo instance.
Agreed. I tried to post a short example, and it obviously was to short
to make my point clear. lets take a longer one. Current syntax:
class Pair:
def __init__(self,
I still see newbie-friendliness as a
MAJOR plus for Python -- it increases the chance that users
of your software will become contributors.
Yes, I 100% agree to that point!
But the point is, the current situation is not newbie-friendly (I can
tell, I am a newbie): I declare a method with 3
On Fri, 03 Feb 2006 03:23:00 -0800, n.estner wrote:
That usage (self is second parameter to B.test) is bound
to cause trouble in general, but in this case doesn't have
any effect I can see. The function call test would be
resolved from its first parameter, instance of A, and that
function
You could try running it to see:
class A:
... def test(a, **kwargs): return 1
...
class B:
... def test(b, **kwargs): return 2
...
test(a=A(), b=B())
Traceback (most recent call last):
File stdin, line 1, in ?
NameError: name 'test' is not defined
Oops! You have
Op 2006-02-03, [EMAIL PROTECTED] schreef [EMAIL PROTECTED]:
First of all, you are using a really poor example of a method,
since it doesn't use any attributes of the Foo instance.
Agreed. I tried to post a short example, and it obviously was to short
to make my point clear. lets take a longer
On Fri, 03 Feb 2006 03:51:03 -0800, n.estner wrote:
My alternative syntax suggestion would be this one:
class Pair:
def self.__init__(a,b):
self.a = a
self.b = b
def self.sum():
return self.a + self.b
def this.product ():
return this.a +
On Fri, 03 Feb 2006 03:59:10 -0800, n.estner wrote:
I still see newbie-friendliness as a
MAJOR plus for Python -- it increases the chance that users
of your software will become contributors.
Yes, I 100% agree to that point!
But the point is, the current situation is not newbie-friendly (I
[EMAIL PROTECTED] wrote:
The main reason (at least for me) is that there's simply too much
magic in it. Why does the expression left of the '.' get promoted to
the first parameter?
One of the reasons I like Lua is because it doesn't do this, instead
using the : operator to designate
Op 2006-02-03, Ben Sizer schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
The main reason (at least for me) is that there's simply too much
magic in it. Why does the expression left of the '.' get promoted to
the first parameter?
One of the reasons I like Lua is because it doesn't do
[EMAIL PROTECTED] wrote:
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
bang ! You're dead !
(no no, just kidding !-)
class Foo:
old-style classes are deprecated.
class Foo(object):
Magnus Lycka [EMAIL PROTECTED] wrote:
...
which isn't needed at all. So far, the existence of x.y somewhere
in Python always implied that x was already introduced explicitly
in the program, and you suggest that we violate that both in the
Almost... import (and from) statements are
Steven D'Aprano [EMAIL PROTECTED] wrote:
...
Why shouldn't
def self.x():
declare two new identifiers (x and self), too?
Sure, but now the call foo.bar
call?
has special meaning inside a def statement
than elsewhere. Elsewhere, foo.bar is an attribute access, looking up
attribute
On Fri, 03 Feb 2006 07:40:38 -0800, Alex Martelli wrote:
Steven D'Aprano [EMAIL PROTECTED] wrote:
...
Why shouldn't
def self.x():
declare two new identifiers (x and self), too?
Sure, but now the call foo.bar
call?
Call? Who said anything about a call?
*wink*
Okay, poor
...
Unfortunately, none of this suggests that it's reasonable to have
def x.y(z): ...
mean the same as
def y(x, z): ...
Actually, it shouldn't. The idea was, that
def x.y(z): ...
(explicitly) introduces an unbound method. That's not introducing a new
conect to python, it's just making
On 3 Feb 2006 08:58:56 -0800, [EMAIL PROTECTED] wrote:
...
Unfortunately, none of this suggests that it's reasonable to have
def x.y(z): ...
mean the same as
def y(x, z): ...
Actually, it shouldn't. The idea was, that
def x.y(z): ...
(explicitly) introduces an unbound method. That's
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
That usage (self is second parameter to B.test) is bound
to cause trouble in general, but in this case doesn't have
any effect I can see. The function call test would be
resolved from its first parameter, instance of A, and that
Magnus Lycka [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Today, Python has a syntactic shortcut. If 'a' is an
instance of class 'A', a.f(x,y,z) is a shortcut for
A.f(a,x,y,z). If you don't use the shortcut, there is
no magic at all, just the unusual
On Fri, 3 Feb 2006 15:27:51 -0500, Terry Reedy [EMAIL PROTECTED] wrote:
Magnus Lycka [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Today, Python has a syntactic shortcut. If 'a' is an
instance of class 'A', a.f(x,y,z) is a shortcut for
A.f(a,x,y,z). If you
Still see no problem. Of course, it goes without saying that
Python 2.4 doesn't work this way, but given that it's theoretically
possible for f(a) to be resolved similarly to a.f, then I really
do not see what you're seeing here. The kwargs parameter appears
irrelevant from where I'm
Steven D'Aprano [EMAIL PROTECTED] wrote:
...
would be. Token? Too specific. Maybe it would have been better to just
have just said ...but now foo.bar has
Agreed.
model I have is y is a label in some namespace x, and you have to (in
some sense) look up where y should go regardless of
[EMAIL PROTECTED] wrote:
...
your idea. Could you summarize how exactly f(x,y=z) should be
resolved, i.e. where it should look for f?
Lexically: local scope, outer functions outwards, globals, builtins.
Alex
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy [EMAIL PROTECTED] wrote:
...
As was once pointed out to me some years ago, when I wrote something
similar, a.f() is not just a shortcut for A.f(a) [a.__class__.f(a)]. The
latter only looks for f in the class A namespace while the former also
looks in superclass namespaces.
Quoth [EMAIL PROTECTED]:
| Still see no problem. Of course, it goes without saying that
| Python 2.4 doesn't work this way, but given that it's theoretically
| possible for f(a) to be resolved similarly to a.f, then I really
| do not see what you're seeing here. The kwargs parameter appears
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
class Foo:
def bar(self, a,b):
return a+b
Foo().bar(1,2) = 3
The main reason (at least for me) is that there's simply too
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
class Foo:
def bar(self, a,b):
return a+b
Foo().bar(1,2) =
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
How about this decorator-based approach (still need to pick *some* name for
self, I picked
write(sys.stdin, split(read(open(file, 'r')))[0])
So, if I got you right, the interpreter would have to interpret this
line like this:
1. Evaluate the first parameter of the first function (sys.stdin)
2. Look up the attribute write in this object
3. evaluate the first parameter of the split
Definitely looks interesting. I'd like it more if it was more explicit,
but still, it does look nice.
I guess you could make it recursion-safe if you saved/restored the
global __ variable before/after calling the actual function, and
probably there's a way to make it thread-safe, too. But how
[EMAIL PROTECTED] wrote:
Having read previous discussions on python-dev I think I'm not the only
Python programmer who doesn't particularly like python's self
parameter:
class Foo:
def bar(self, a,b):
return a+b
Foo().bar(1,2) = 3
The main reason (at least
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
write(sys.stdin, split(read(open(file, 'r')))[0])
So, if I got you right, the interpreter would have to interpret this
line like this:
1. Evaluate the first parameter of the first function (sys.stdin)
2. Look up the attribute write
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Definitely looks interesting. I'd like it more if it was more explicit,
but still, it does look nice.
I guess you could make it recursion-safe if you saved/restored the
global __ variable before/after calling the actual function, and
On Thu, 02 Feb 2006 19:27:55 -0600
DH [EMAIL PROTECTED] wrote:
But I think most people who don't like the extraneous
'self' in python just consider it a minor inconvenience
and don't even notice it after using python for a while.
After messing around with Javascript (many magical
variables
48 matches
Mail list logo
