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
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
"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 i
<[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 mo
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
>
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.
>
>
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 "open(fi
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.
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.
"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
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 appea
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 namespace
<[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
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 reg
> 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 si
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(
"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 un
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, a
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 unbou
> ...
> 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
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?
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, look
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 excep
[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
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 d
[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 metho
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-f
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 ():
> retur
On Fri, 03 Feb 2006 04:14:33 -0800, n.estner wrote:
[snip]
>> Since namespaces are critical to Python, your test code is a problem that
>> just cannot happen in Python. It is a non-issue. Python will not get
>> confused between the two definitions of test.
>
> I've been answering to Donn Cave's
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 tak
> 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 "", line 1, in ?
> NameError: name 'test' is not defined
>
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
>>
> 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
> 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, a
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 metho
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 referen
> 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
[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 syntacti
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
variab
<[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 functio
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 attribu
[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
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 wo
>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
<[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
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().
46 matches
Mail list logo
