[Guido]
> > Here's a patch that gets rid of unbound methods, as
> > discussed here before. A function's __get__ method
> > now returns the function unchanged when called without
> > an instance, instead of returning an unbound method object.
[Greg]
> I thought the main reason for existence of unbo
Guido van Rossum wrote:
Here's a patch that gets rid of unbound methods, as
discussed here before. A function's __get__ method
now returns the function unchanged when called without
an instance, instead of returning an unbound method object.
I thought the main reason for existence of unbound
method
> > and is more consistent with the general convention, that running
> > A = B
> > causes
> > A == B
> > to be true. Currently, Class.func = staticmethod(func), and Class.func
> > = func, don't behave by this rule. If the suggestions are accepted,
> > both will.
>
> Well, given that attribute assi
> Removing unbound methods also breaks the 'py' lib quite a bit. The 'py.test'
> framework handles function and bound/unbound method objects all over the
> place, and uses introspection on them, as they are the objects defining the
> tests to run.
OK, I'm convinced. Taking away im_class is going
> It's about staticmethods. I was writing a class, and its
> pretty-printing method got a function for converting a value to a
> string as an argument. I wanted to supply a default function. I
> thought that it should be in the namespace of the class, since its
> main use lies there. So I made it a
Hello,
I would like to add here another small thing which I encountered this
week, and seems to follow the same logic as does Guido's proposal.
It's about staticmethods. I was writing a class, and its
pretty-printing method got a function for converting a value to a
string as an argument. I wante
Hi,
Removing unbound methods also breaks the 'py' lib quite a bit. The 'py.test'
framework handles function and bound/unbound method objects all over the
place, and uses introspection on them, as they are the objects defining the
tests to run.
It's nothing that can't be repaired, and at places
Guido van Rossum wrote:
[me]
I'm not sure I understand how basemethod is supposed to work; I can't
find docs for it using Google (only three hits for the query mxTools
basemethod). How does it depend on im_class?
[Marc-Andre]
It uses im_class to find the class defining the (unbound) method:
def ba
Guido van Rossum wrote:
> [Timothy Delaney]
>> If im_func were set to the class where the function was defined, I
>> could definitely avoid the second part of the trawling (not sure
>> about the first yet, since I need to get at the function object).
>
> Instead of waiting for unbound methods to
[me]
> > I'm not sure I understand how basemethod is supposed to work; I can't
> > find docs for it using Google (only three hits for the query mxTools
> > basemethod). How does it depend on im_class?
[Marc-Andre]
> It uses im_class to find the class defining the (unbound) method:
>
> def basemet
[Timothy Delaney]
> If im_func were set to the class where the function was defined, I could
> definitely avoid the second part of the trawling (not sure about the
> first yet, since I need to get at the function object).
Instead of waiting for unbound methods to change their functionality,
just c
Guido van Rossum wrote:
[Guido]
Apart from the tests that were testing the behavior of im_class, I
found only a single piece of code in the standard library that used
im_class of an unbound method object (the clever test in the pyclbr
test). Uses of im_self and im_func were more widespread. Given t
M.-A. Lemburg wrote:
Nick Coghlan wrote:
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the "an unbound method is almost like
a bare function, only not quite as useful"
Guido van Rossum wrote:
> Keeping im_class would be tricky -- the information isn't easily
> available when the function is defined, and adding it would require
> changing unrelated code that the patch so far didn't have to get near.
> Also, it would not be compatible -- the unbound method sets im
[Guido]
> > Apart from the tests that were testing the behavior of im_class, I
> > found only a single piece of code in the standard library that used
> > im_class of an unbound method object (the clever test in the pyclbr
> > test). Uses of im_self and im_func were more widespread. Given the
> > l
On Jan 17, 2005, at 18:33, Glyph Lefkowitz wrote:
It's not the strongest use-case in the world, but is the impetus to
remove unbound method objects from Python that much stronger? I like
the fact that it's simpler, but it's a small amount of extra
simplicity,
it doesn't seem to enable any new use
On Mon, 2005-01-17 at 17:58, M.-A. Lemburg wrote:
> If you want to make methods look more like functions,
> the method object should become a subclass of the function
> object (function + added im_* attributes).
I have no personal use cases, but it does make me vaguely uncomfortable
to lose im_cl
On Mon, 2005-01-17 at 23:58 +0100, M.-A. Lemburg wrote:
> If you want to make methods look more like functions,
> the method object should become a subclass of the function
> object (function + added im_* attributes).
I think this suggestion would fix my serialization problem as well...
but does
On Mon, 2005-01-17 at 07:43 -0800, Guido van Rossum wrote:
> Note that you can't pickle unbound methods anyway unless you write
> specific suppport code to do that; it's not supported by pickle
> itself.
It's supported by Twisted. Alternatively, replace "pickle" with "python
object serializer of
Guido van Rossum wrote:
Apart from the tests that were testing the behavior of im_class, I
found only a single piece of code in the standard library that used
im_class of an unbound method object (the clever test in the pyclbr
test). Uses of im_self and im_func were more widespread. Given the
level
> Will it still be possible to create an unbound method with
> new.instancemethod? (I know the patch doesn't change this, I mean, is it
> planned to remove the facility from the instancemethod type?)
I was hoping to be able to get rid of this as soon as the built-in
exceptions code no longer depe
[Guido]
> > def test_im_class():
> > class C:
> > def foo(self): pass
> > - verify(C.foo.im_class is C)
[Glyph]
> ^ Without this, as JP Calderone pointed out earlier, you can't serialize
> unbound methods. I wouldn't mind that so much, but you can't tell that
> they're any d
At 10:12 PM 1/16/05 -0800, Guido van Rossum wrote:
I couldn't remove support for unbound methods
completely, since they were used by the built-in
exceptions. (We can get rid of that use once we convert
to new-style exceptions.)
Will it still be possible to create an unbound method with
new.instanc
Nick Coghlan wrote:
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the "an unbound method is almost like a
bare function, only not quite as useful" distinction. It woul
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the "an unbound method is almost like a bare
function, only not quite as useful" distinction. It would allow things like
On Sun, 2005-01-16 at 22:12 -0800, Guido van Rossum wrote:
> What do people think? (My main motivation for this, as stated before,
> is that it adds complexity without much benefit.)
> ***
> *** 331,339
> def test_im_class():
> class C:
> def foo(self): pass
> -
https://sourceforge.net/tracker/index.php?func=detail&aid=1103689&group_id=5470&atid=305470
Here's a patch that gets rid of unbound methods, as
discussed here before. A function's __get__ method
now returns the function unchanged when called without
an instance, instead of returning an unbound met
27 matches
Mail list logo