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
>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 wo
> 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
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
> 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
> 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
> 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
>
> ...
> 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
> 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
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.
11 matches
Mail list logo
