Guido van Rossum wrote:
> Thanks for the patch! Now I'm hoping someone will look into those
> remaining six test failures.
The tooth fairy has left a present for you, Guido. Georg has fixed 5 of
the remaining bugs and I got test_unittest working this morning.
Christian
___
Guido van Rossum wrote:
>
> Also, there was discussion of this before:
> http://mail.python.org/pipermail/python-dev/2005-January/050625.html
> -- why didn't we decide to do it then?
Skimming that thread, the issues seem to be:
- worse error messages from explicit base class calls if you forge
André Malo wrote:
> * Greg Ewing wrote:
>
> > But you could just as well wrap
> > it in a function that takes self and discards it,
>
> I always thought, that this is exactly what staticmethod does.
Not quite -- staticmethod prevents a self from getting
passed in the first place, so there's no
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Also, there was discussion of this before:
| http://mail.python.org/pipermail/python-dev/2005-January/050625.html
| -- why didn't we decide to do it then?
1. Nobody ran with it.
2. There was mild concern with breaki
At 09:56 AM 11/24/2007 -0800, Guido van Rossum wrote:
>Also, there was discussion of this before:
>http://mail.python.org/pipermail/python-dev/2005-January/050625.html
>-- why didn't we decide to do it then?
http://mail.python.org/pipermail/python-dev/2005-January/051236.html
There were also a fe
* Greg Ewing wrote:
> Phillip J. Eby wrote:
> > class MoneyField(Field):
> > # does need staticmethod because two_decimal_places
> > # doesn't take a self
> > converter = staticmethod(two_decimal_places)
>
> Okay, I see what you mean now. But you could just as well wrap
> it in a funct
On Nov 23, 2007 11:10 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >
> > Index: Objects/funcobject.c
> > ===
> > --- Objects/funcobject.c(revision 59154)
> > +++ Objects/funcobject.c(worki
Christian Heimes wrote:
> Without support from the descriptor it's not possible to distinguish a
> function from an unbound method any more. I like to add im_class to the
> function object. I don't see negative side effects, do you?
OK, forget that. Pretend I've never said it. I shouldn't submit i
Guido van Rossum wrote:
>
> Index: Objects/funcobject.c
> ===
> --- Objects/funcobject.c(revision 59154)
> +++ Objects/funcobject.c(working copy)
> @@ -643,8 +643,10 @@
> static PyObject *
> func_descr_get(PyObject *
On Nov 22, 2007 11:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > It looks like we're in agreement to drop unbound methods and have a
> > reasonable set or arguments around it (e.g. keep staticmethod, no
> > changes to methods of builtin types, etc.). Do we need a
> It looks like we're in agreement to drop unbound methods
+1 It is a bit cleaner to simply return the unmodified function.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Phillip J. Eby wrote:
> class MoneyField(Field):
> # does need staticmethod because two_decimal_places
> # doesn't take a self
> converter = staticmethod(two_decimal_places)
Okay, I see what you mean now. But you could just as well wrap
it in a function that takes self and discards it
At 07:57 PM 11/23/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>>If you are configuring it per-class and accessing it per-instance,
>>and reusing an existing function, you have to make it a staticmethod.
>
>I don't understand that. Can you provide an example?
def two_decimal_places(text)
At 08:19 PM 11/22/2007 -0800, Guido van Rossum wrote:
>It looks like we're in agreement to drop unbound methods and have a
>reasonable set or arguments around it (e.g. keep staticmethod, no
>changes to methods of builtin types, etc.). Do we need a PEP? It's
>essentially a 2-line change in funcobjec
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|Do we need a PEP?
In my view, no. And I am a fan of PEPs. I personally saw unbound method
wrapping as more of a CPython implementation detail than an essential part
of the language definition. This in spite of i
Guido van Rossum wrote:
> It looks like we're in agreement to drop unbound methods and have a
> reasonable set or arguments around it (e.g. keep staticmethod, no
> changes to methods of builtin types, etc.). Do we need a PEP? It's
> essentially a 2-line change in funcobject.c (func_descr_get()) --
Phillip J. Eby wrote:
> If you are configuring it per-class and
> accessing it per-instance, and reusing an existing function, you have to
> make it a staticmethod.
I don't understand that. Can you provide an example?
> > some subclasser later finds that he wants access to
> > 'self'?
>
> Then
It looks like we're in agreement to drop unbound methods and have a
reasonable set or arguments around it (e.g. keep staticmethod, no
changes to methods of builtin types, etc.). Do we need a PEP? It's
essentially a 2-line change in funcobject.c (func_descr_get()) -- plus
fixing up half a dozen or s
At 01:14 PM 11/23/2007 +1300, Greg Ewing wrote:
>Guido van Rossum wrote:
> > Not quite. You can evolve an API from an instancemethod into a
> > staticmethod without changing the call sites.
>
>But is there ever any need to do that, rather than leave
>it as an instance method?
Yes. :) See below.
Guido van Rossum wrote:
> Not quite. You can evolve an API from an instancemethod into a
> staticmethod without changing the call sites.
But is there ever any need to do that, rather than leave
it as an instance method?
Personally it would never have occurred to me to do that.
If you want to be a
Guido van Rossum wrote:
> Given that the error is of limited value and that otherwise the
> unbound method behaves exactly the same as the original function
> object, I'd like to see if there are strenuous objections against
> dropping unbound method objects altogether (or at least not using them
>
At 03:48 PM 11/22/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > The lookup sequence should probably be something like:
> >
> >1. type(ob) is cls
> >2. issubclass(type(ob), cls)
>
>But can't issubclass be overridden as well?
Yes, which is why I spelled it that way, and mentioned
On Nov 21, 2007 4:58 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> If I understand correctly, this would negate the need for staticmethod()
> when accessing the function via the class (and not instances) since the
> main effect of that is to prevent the wrapping. (And since I consider
> instance.so
Guido van Rossum wrote:
> Given that the error is of limited value and that otherwise the
> unbound method behaves exactly the same as the original function
> object, I'd like to see if there are strenuous objections against
> dropping unbound method objects altogether (or at least not using them
>
Phillip J. Eby wrote:
> The lookup sequence should probably be something like:
>
>1. type(ob) is cls
>2. issubclass(type(ob), cls)
But can't issubclass be overridden as well?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
If I understand correctly, this would negate the need for staticmethod()
when accessing the function via the class (and not instances) since the
main effect of that is to prevent the wrapping. (And since I consider
instance.somestaticmeth() as even less idiomatic Python that
class.somestaticme
At 01:41 AM 11/22/2007 +0100, Amaury Forgeot d'Arc wrote:
>Could we check for "real" inheritance first, and call
>__instancecheck__ only when the previous is false? It would speed-up
>the common cases.
+1.
>Or is there really a use case for a derived class to appear as NOT
>being a subclass of it
Guido van Rossum wrote:
> I'm asking a Py3k question on python-dev because I'd like to have
> opinions from people who haven't thought about Py3k much yet. Consider
> the following example:
>
> class C:
> def foo(self): pass
>
> C.foo(42)
>
> This currently fails with this error message:
I'm asking a Py3k question on python-dev because I'd like to have
opinions from people who haven't thought about Py3k much yet. Consider
the following example:
class C:
def foo(self): pass
C.foo(42)
This currently fails with this error message:
TypeError: unbound method foo() must b
29 matches
Mail list logo
