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
[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 unbound
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
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
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
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 assignment can be
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
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:
[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
[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
[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
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
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 would
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
[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 different
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
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
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 my
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 it
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
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
[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
level of
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
https://sourceforge.net/tracker/index.php?func=detailaid=1103689group_id=5470atid=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
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
-
25 matches
Mail list logo
