> It doesn't. As Alex has already explained, the above is equivallent to:
>
> def h(): pass
>
> class A:
> l = []
> f = h
>
> a = A()
> print a.l is A.l
> print a.f is A.f
So what - the difference is between bound and unbound method, which is what
were talking here about after all - so in t
Op 2005-02-08, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>> No python is not consistent and your continuous repetion doesn't
>> make it so. To illustrate, here the following code:
>>
>> class A:
>> l = []
>> def f(): pass
>>
>> a = A()
>> print a.l is A.l
>> print a.f is A.f
>>
>> which
> No python is not consistent and your continuous repetion doesn't
> make it so. To illustrate, here the following code:
>
> class A:
> l = []
> def f(): pass
>
> a = A()
> print a.l is A.l
> print a.f is A.f
>
> which produces:
>
> True
> False
Thats only inconsistent from your POV becaus
jfj <[EMAIL PROTECTED]> wrote:
> I just realized that I'm trolling.
I'm glad you're retracting your earlier assertion that "There is no
trolling involved here". Everybody can err, but to admit and apologize
takes character: may I offer my warmest handshake.
Back when I was a Python newbie (and
Op 2005-02-07, Alex Martelli schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>> Yes it is inconsistent with the rest of python. That you found
>> a subset in which it is consistent doesn't change that.
>>
>> And what if you do:
>>
>> c = C()
>> c.f = g
>>
>>
>> The
I just realized that I'm trolling.
We all sometimes get into a trollwar despite our intensions
(even FL). So, I would like to apologize on behalf
of all those who participated in it. I'm sorry you had to witness
that.
jfj
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard wrote:
For your benefit, and the benefit of others who make this same mistake,
I'll rewrite your original post in a manner that won't seem so
self-important and confrontational[1].
``People who code too much tend to get authoritative'', in general.
I am an arrogant noob -- just li
"jfj" <[EMAIL PROTECTED]> wrote:
>> u = DoSomethingWithCallback(A().callback)
> ^
> Oops!!!
> I think it would be more obvious to somebody who doesn't know
> the python internals, to say:
> # take the callback from A and install it to DSWC
> u=DoSomethin
jfj wrote:
I think the problem is that you know python so well that you are used
to the way things are and everything seems natural the way it is.
For a newbie, the behaviour I mentioned seems indeed a bit inconsistent.
"Inconsistent" not as in mathematics but as in "wow! I'd thought this
should wo
Alex Martelli wrote:
>
I think the problem is that you know python so well that you are used
to the way things are and everything seems natural the way it is.
For a newbie, the behaviour I mentioned seems indeed a bit inconsistent.
"Inconsistent" not as in mathematics but as in "wow! I'd thought th
John Lenton <[EMAIL PROTECTED]> wrote:
> I think __new__ being an
> exception to this is a (minor) wart, in fact it feels like premature
> optimization (how many __new__s do you write, that you can't stick a
> @staticmethod in front of them?
I personally think it's quite reasonable for Python's i
Antoon Pardon <[EMAIL PROTECTED]> wrote:
> Yes it is inconsistent with the rest of python. That you found
> a subset in which it is consistent doesn't change that.
>
> And what if you do:
>
> c = C()
> c.f = g
>
>
> The fact that a function in a class performs a lot of magic if
> it is cal
Op 2005-02-07, John Lenton schreef <[EMAIL PROTECTED]>:
>
>
> --cvVnyQ+4j833TQvp
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Feb 07, 2005 at 02:53:49PM +, Antoon Pardon wrote:
>> The fact that a function in
On Mon, Feb 07, 2005 at 02:53:49PM +, Antoon Pardon wrote:
> The fact that a function in a class performs a lot of magic if
> it is called through an instance, that isn't performed otherwise,
> makes python inconsistent here. You may like the arrangement
> (and it isn't such a big deal IMO) but
Op 2005-02-07, Alex Martelli schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>> Op 2005-02-06, Alex Martelli schreef <[EMAIL PROTECTED]>:
>> >
>> >> Isn't that inconsistent?
>> >
>> > That Python has many callable types, not all of which are descriptors?
>> > I don't see
On Mon, Feb 07, 2005 at 03:24:11PM +0100, Alex Martelli wrote:
> def always produces a
> function object and binds it to the name coming after keyword 'def'.
> Any such function object, no matter how produced and how bound hither
> and thither, always
Antoon Pardon <[EMAIL PROTECTED]> wrote:
> Op 2005-02-06, Alex Martelli schreef <[EMAIL PROTECTED]>:
> >
> >> Isn't that inconsistent?
> >
> > That Python has many callable types, not all of which are descriptors?
> > I don't see any inconsistency there. Sure, a more generalized currying
> > (a
Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
...
> > If there a good reason that the __get__ of a boundmethod does not
> > create a new boundmethod wrapper over the first boundmethod?
>
> I already gave you the good reason:
Hmmm, not sure the code below is ``a good reason'' to avoid changing th
Hello Diez.
I sent a reply to the previous message requesting an example of
what would break, but unfortunatelly it didn't make it in python-list.
Here it is for the record [
Diez B. Roggisch wrote:
If things worked as you wanted it to, that would mean that passing bound
method as argument to a cla
Op 2005-02-06, Alex Martelli schreef <[EMAIL PROTECTED]>:
>
>> Isn't that inconsistent?
>
> That Python has many callable types, not all of which are descriptors?
> I don't see any inconsistency there. Sure, a more generalized currying
> (argument-prebinding) capability would be more powerful, b
> HOWEVER, what I ask is WHY don't we set the tp_descr_get of
> the boundmethod object to be the same as the func_descr_get???
> Or WHY do they *have* to differ in this specific part?
>
> I quickly looked at the source of python and it seems that a
> one-liner would be enough to enable this. So it
On 2005 Feb 07, at 22:15, jfj wrote:
Alex Martelli wrote:
jfj <[EMAIL PROTECTED]> wrote:
Then, without looking at the previous code, one can say that "x" is a
function which takes one argument.
One can say whatever one wishes, but saying it does not make it true.
One can say that x is a green frog,
Alex Martelli wrote:
jfj <[EMAIL PROTECTED]> wrote:
Then, without looking at the previous code, one can say that "x" is a
function which takes one argument.
One can say whatever one wishes, but saying it does not make it true.
One can say that x is a green frog, but that's false: x is a
boundmetho
Alex Martelli wrote:
I still wouldn't see any "inconsistency" even if two different ways of
proceeding gave the same result in a certain case. That would be like
saying that having x-(-y) give the same result as x+y (when x and y are
numbers) is ``inconsistent''... the word ``inconsistent'' just d
jfj <[EMAIL PROTECTED]> wrote:
> >>Isn't that inconsistent?
> >
> > That Python has many callable types, not all of which are descriptors?
> > I don't see any inconsistency there. Sure, a more generalized currying
> > (argument-prebinding) capability would be more powerful, but not more
> > cons
jfj <[EMAIL PROTECTED]> wrote:
> If I say:
>
> x=b.foo
> x(1)
>
> Then, without looking at the previous code, one can say that "x" is a
> function which takes one argument.
One can say whatever one wishes, but saying it does not make it true.
One can say that x is a green frog, but that's fals
Diez B. Roggisch wrote:
If things worked as you wanted it to, that would mean that passing a bound
method as argument to a class and storing it there to an instance variable
that would "eat up" the arguments - surely not the desired behaviour.
Could you please give an example of this ?
If you mean:
> I expected that when we add this "x" to a class's dictionary and
> then we request it from an instance of that class, it will be
> converted to an bound-method and receive its --one-- argument
> from the referring instance.
Here you are wrong: your b.foo is a bound method - it already _has_ its
Alex Martelli wrote:
jfj <[EMAIL PROTECTED]> wrote:
Isn't that inconsistent?
That Python has many callable types, not all of which are descriptors?
I don't see any inconsistency there. Sure, a more generalized currying
(argument-prebinding) capability would be more powerful, but not more
consiste
Dan Perl wrote:
"jfj" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
However this is not possible for another instance method:
class A:
pass
class B:
def foo(x,y)
print x,y
b=B()
A.foo = b.foo
a=A()
# error!!!
a.foo()
##
Python complains that 'foo() takes
jfj <[EMAIL PROTECTED]> wrote:
> I don't understand.
> We can take a function and attach it to an object, and then call it
> as an instance method as long as it has at least one argument:
>
> #
> class A:
>pass
>
> def foo(x):
>print x
>
> A.foo = foo
> a=A()
> a.foo()
> ###
"jfj" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I don't understand.
> We can take a function and attach it to an object, and then call it
> as an instance method as long as it has at least one argument:
>
> #
> class A:
> pass
>
> def foo(x):
> print x
>
> A.foo
Hi Gerald,
When you define an instance method, the first parameter (in the
definition) represents the instance. By convention, you would name it
"self":
#
class B:
def foo(self, x):
print "we have two parameters: " + str(self) + " and " + x
#
then
I don't understand.
We can take a function and attach it to an object, and then call it
as an instance method as long as it has at least one argument:
#
class A:
pass
def foo(x):
print x
A.foo = foo
a=A()
a.foo()
#
However this is not possible for another instance method
34 matches
Mail list logo
