On 04/06/13 12:43, 探晴 wrote:
Your email appears to be blank, except for a large chunk of HTML code. Did you
have something specific to say other than the subject line?
As for unbound methods, Guido's time machine strikes again. They're already
gone in Python 3.
py> class X:
... def sp
Tim Peters wrote:
I expect that's because he stopped working on Zope code, so actually
thinks it's odd again to see a gazillion methods like:
class Registerer(my_base):
def register(*args, **kws):
my_base.register(*args, **kws)
I second that! My PyGUI code is *full* of __init__
methods
Josiah Carlson wrote:
While it seems that super() is the 'modern paradigm' for this,
I have been using base.method(self, ...) for years now, and have been
quite happy with it.
I too would be very disappointed if base.method(self, ...)
became somehow deprecated. Cooperative super calls are a
differe
Hi Phillip,
On Wed, Jan 05, 2005 at 01:03:42PM -0500, Phillip J. Eby wrote:
> >Is there any other use case for 'C.x' not returning the same as
> >'appropriate_super_class_of_C.__dict__["x"]' ?
>
> Er, classmethod would be one; a rather important one at that.
Oups. Right, sorry.
Armin
> Um, isn't all this stuff going to be more complicated and spread out over
> more of the code than just leaving unbound methods in place?
Well, in an early version of Python it was as simple as I'd like ot to
be again: the instancemethod type was only used for bound methods
(hence the name) and C
At 12:29 PM 1/5/05 -0500, Barry Warsaw wrote:
On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote:
> I think it would be reasonable to assign im_class only to functions
> defined in class scope. The only serialization that would break in that
> case is if your example had a 'del f' at the end.
+1.
At 04:30 PM 1/5/05 +, Armin Rigo wrote:
Hi Guido,
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> Let's get rid of unbound methods.
Is there any other use case for 'C.x' not returning the same as
'appropriate_super_class_of_C.__dict__["x"]' ?
Er, classmethod would be one; a
Armin Rigo wrote:
Hi Jim,
On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote:
Actually, unbound builtin methods are a different type than bound
builtin methods:
Of course, but conceptually they are similar. You would still
encounter the concept if you got an unbound builtin method.
There
> duck typing?
That's the Australian pronunciation of "duct taping".
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-arc
On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote:
> I think it would be reasonable to assign im_class only to functions
> defined in class scope. The only serialization that would break in that
> case is if your example had a 'del f' at the end.
+1. If you're doing something funkier, then you
On Wed, 2005-01-05 at 10:37, Glyph Lefkowitz wrote:
> One approach I have taken in order to avoid copiously over-documenting
> every super() using class is to decouple different phases of
> initialization by making __init__ as simple as possible (setting a few
> attributes, resisting the temptatio
Alex Martelli wrote:
def f(*a): pass class C(object): pass class D(object): pass C.f = D.f
= f
If now we want C.f.im_class to differ from D.f.im_class then we need
f to get copied implicitly when it's assigned to C.f (or, of course,
when C.f is accessed... but THAT might be substantial overhead).
Hi Guido,
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> Let's get rid of unbound methods.
Is there any other use case for 'C.x' not returning the same as
'appropriate_super_class_of_C.__dict__["x"]' ? I guess it's too late now but
it would have been nice if user-defined __g
Hi Jim,
On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote:
> >Actually, unbound builtin methods are a different type than bound
> >builtin methods:
>
> Of course, but conceptually they are similar. You would still
> encounter the concept if you got an unbound builtin method.
There are
On Wed, 2005-01-05 at 12:11 +0100, Alex Martelli wrote:
> Hmmm, seems to me we'd need copies of the function object for this
> purpose:
For the stated use-case of serialization, only one copy would be
necessary, and besides - even *I* don't use idioms as weird as the one
you are suggesting very
On Tue, 2005-01-04 at 22:12 -0500, Bob Ippolito wrote:
> If you have a class hierarchy where this is a problem, it's probably
> pretty fragile to begin with, and you should think about making it
> simpler.
I agree with James's rant almost entirely, but I like super() anyway. I
think it is an in
On 2005 Jan 05, at 04:42, Barry Warsaw wrote:
On Tue, 2005-01-04 at 18:01, Jack Jansen wrote:
But I'm more worried about losing the other information in an unbound
method, specifically im_class. I would guess that info is useful to
class browsers and such, or are there other ways to get at that?
Th
Tim Peters <[EMAIL PROTECTED]> wrote:
>
> [Tim Peters]
> >> ... Unbound methods are used most often (IME) to call a
> >> base-class method from a subclass, like
> >> my_base.the_method(self, ...).
> >> It's especially easy to forget to write `self, ` there, and the
> >> exception msg then is qu
On Tue, 2005-01-04 at 18:01, Jack Jansen wrote:
> But I'm more worried about losing the other information in an unbound
> method, specifically im_class. I would guess that info is useful to
> class browsers and such, or are there other ways to get at that?
That would be my worry too. OTOH, we
On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote:
Tim Peters <[EMAIL PROTECTED]> wrote:
Guido wrote:
Let's get rid of unbound methods. When class C defines a method
[snip]
Really? Unbound methods are used most often (IME) to call a
base-class method from a subclass, like my_base.the_method(self, .
[Tim Peters]
>> ... Unbound methods are used most often (IME) to call a
>> base-class method from a subclass, like
>> my_base.the_method(self, ...).
>> It's especially easy to forget to write `self, ` there, and the
>> exception msg then is quite focused because of that extra bit of
>> type check
Tim Peters <[EMAIL PROTECTED]> wrote:
> Guido wrote:
> > Let's get rid of unbound methods. When class C defines a method
[snip]
> Really? Unbound methods are used most often (IME) to call a
> base-class method from a subclass, like my_base.the_method(self, ...).
> It's especially easy to forget
On Jan 4, 2005, at 6:01 PM, Jack Jansen wrote:
On 4-jan-05, at 19:28, Guido van Rossum wrote:
The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code)
It caught bugs for me a couple
On 4-jan-05, at 19:28, Guido van Rossum wrote:
The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code)
It caught bugs for me a couple of times. If I remember correctly I was
callin
At 11:40 AM 1/4/05 -0800, Guido van Rossum wrote:
[Jim]
> We'll still need unbound builtin methods, so the concept won't
> go away. In fact, the change would mean that the behavior between
> builtin methods and python methods would become more inconsistent.
Actually, unbound builtin methods are a d
On Tue, 4 Jan 2005 12:18:15 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>[me]
> > > Actually, unbound builtin methods are a different type than bound
> > > builtin methods:
>
> [Jim]
> > Of course, but conceptually they are similar. You would still
> > encounter the concept if you got an u
[me]
> > Actually, unbound builtin methods are a different type than bound
> > builtin methods:
[Jim]
> Of course, but conceptually they are similar. You would still
> encounter the concept if you got an unbound builtin method.
Well, these are all just implementation details. They really are all
On Tue, 04 Jan 2005 20:02:06 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote:
>On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >In my blog I wrote:
> >
> > Let's get rid of unbound methods. When class C defines a method f, C.f
> > should just return the function object
On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>In my blog I wrote:
>
> Let's get rid of unbound methods. When class C defines a method f, C.f
> should just return the function object, not an unbound method that
> behaves almost, but not quite, the same as that func
Guido van Rossum wrote:
[Jim]
We'll still need unbound builtin methods, so the concept won't
go away. In fact, the change would mean that the behavior between
builtin methods and python methods would become more inconsistent.
Actually, unbound builtin methods are a different type than bound
builti
[Guido van Rossum]
> > Let's get rid of unbound methods.
+1
[Jim Fulton]
> duck typing?
Requiring a specific interface instead of a specific type.
[Guido]
> > Does anyone think this is a bad idea?
[Jim]
> It *feels* very disruptive to me, but I'm probably wrong.
> We'll still need unbound
[Jim]
> We'll still need unbound builtin methods, so the concept won't
> go away. In fact, the change would mean that the behavior between
> builtin methods and python methods would become more inconsistent.
Actually, unbound builtin methods are a different type than bound
builtin methods:
>>> ty
Phillip J. Eby wrote:
At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote:
Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea?
Code that currently does 'aClass.aMet
[Guido]
> In my blog I wrote:
>
> Let's get rid of unbound methods. When class C defines a method
> f, C.f should just return the function object, not an unbound
> method that behaves almost, but not quite, the same as that
> function object. The extra type checking on the first argument that
> un
At 01:36 PM 1/4/05 -0500, Jim Fulton wrote:
duck typing?
AKA latent typing or, "if it walks like a duck and quacks like a duck, it
must be a duck." Or, more pythonically:
if hasattr(ob,"quack") and hasattr(ob,"duckwalk"):
# it's a duck
This is as distinct from both 'if isinstance(ob,D
At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote:
Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea?
Code that currently does 'aClass.aMethod.im_func' in order t
On Tue, Jan 04, 2005, Jim Fulton wrote:
> Guido van Rossum wrote:
>>
>> and the overloading of
>>unbound and bound methods on the same object type is confusing. Also,
>>the type checking offered is wrong, because it checks for subclassing
>>rather than for duck typing.
>
> duck typing?
"If it loo
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> In my blog I wrote:
>
> Let's get rid of unbound methods. When class C defines a method f, C.f
> should just return the function object, not an unbound method that
> behaves almost, but not quite, the same as that function object.
On Jan 4, 2005, at 1:28 PM, Guido van Rossum wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argumen
Guido van Rossum wrote:
In my blog I wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that u
40 matches
Mail list logo
