On 05/11/14 06:15, Roberto Martínez wrote:
The thing with this is tricky. I need the change in the instance,
> not in the class, because I have multiple instances and all of
> them must have different implementations of __call__.
Why not just use functions with closure if that's what you need?
On Thu, Nov 13, 2014 at 2:20 AM, Gregory Ewing
wrote:
> Fabio Zadrozny wrote:
>
>> can someone from python-dev give some background of why that's the way it
>> is?
>>
>
> It's because, with new-style classes, a class is also an
> instance (of class "type" or a subclass thereof). So
> without that
Fabio Zadrozny wrote:
can someone from python-dev give some background of why
that's the way it is?
It's because, with new-style classes, a class is also an
instance (of class "type" or a subclass thereof). So
without that rule, it would be ambiguous whether a dunder
method applied to instances
On Wed, Nov 12, 2014 at 8:33 AM, Fabio Zadrozny wrote:
> As a reference, I recently found a blog post related to that:
> http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ (the Slots
> part comments on that).
>
> It does seem a bit counter-intuitive that this happens the way it does
On Tue, Nov 11, 2014 at 5:43 AM, Ian Kelly wrote:
> On Sat, Nov 8, 2014 at 3:31 PM, Gregory Ewing
> wrote:
> > (BTW, I'm actually surprised that this technique makes c callable.
> > There must be more going on that just "look up __call__ in the class
> > object", because evaluating C.__call__ ju
On Sat, Nov 8, 2014 at 3:31 PM, Gregory Ewing
wrote:
> (BTW, I'm actually surprised that this technique makes c callable.
> There must be more going on that just "look up __call__ in the class
> object", because evaluating C.__call__ just returns the descriptor
> and doesn't invoking the descripto
On 11/09/2014 03:38 AM, Gregory Ewing wrote:
Ethan Furman wrote:
And the thing going on is the normal python behavior (in __getattribute__, I
believe) of examining the returned
attribute to see if it is a descriptor, and if so invoking it.
Only if you look it up through the instance, though.
Gregory Ewing wrote:
> Ethan Furman wrote:
>> And the thing going on is the normal python behavior (in
>> __getattribute__, I believe) of examining the returned attribute to see
>> if it is a descriptor, and if so invoking it.
>
> Only if you look it up through the instance, though.
> Normally, i
Ethan Furman wrote:
And the thing going on is the normal python behavior (in
__getattribute__, I believe) of examining the returned attribute to see
if it is a descriptor, and if so invoking it.
Only if you look it up through the instance, though.
Normally, if you look up an attribute on a cla
On 11/08/2014 02:31 PM, Gregory Ewing wrote:
Seems to depend on how you get hold of the object you're
inspecting the signature of. I did an experiment:
class C(object):
@property
def __call__(self):
return self.call
def f(x, y):
print("Called f with %s, %s" % (x, y))
Ethan Furman wrote:
On 11/06/2014 10:59 PM, dieter wrote:
A possibility to get the original approach implemented looks like:
make "__call__" a descriptor on the class which looks up the real
method on the instance.
This still wouldn't get the signatrue correct, though.
Why not? O
On 11/07/2014 10:50 PM, dieter wrote:
Ethan Furman writes:
On 11/06/2014 10:59 PM, dieter wrote:
John Ladasky writes:
On Tuesday, November 4, 2014 11:12:31 AM UTC-8, Ethan Furman wrote:
If you really absolutely positively have to have the signature be correct for
each instance, you may to
Ethan Furman writes:
> On 11/06/2014 10:59 PM, dieter wrote:
>> John Ladasky writes:
>>> On Tuesday, November 4, 2014 11:12:31 AM UTC-8, Ethan Furman wrote:
>>>
If you really absolutely positively have to have the signature be correct
for each instance, you may to either look at a
On 11/06/2014 10:59 PM, dieter wrote:
John Ladasky writes:
On Tuesday, November 4, 2014 11:12:31 AM UTC-8, Ethan Furman wrote:
If you really absolutely positively have to have the signature be correct for
each instance, you may to either look at a
function creating factory, a class creating f
John Ladasky writes:
> On Tuesday, November 4, 2014 11:12:31 AM UTC-8, Ethan Furman wrote:
>
>> If you really absolutely positively have to have the signature be correct
>> for each instance, you may to either look at a
>> function creating factory, a class creating factory, or a meta-class.
>
Roberto Martínez wrote:
> Yikes, I didn't realize the difference in inheritance.
>
> The thing with this is tricky. I need the change in the instance, not in
> the class, because I have multiple instances and all of them must have
> different implementations of __call__.
>
> The workaround of ca
On Tuesday, November 4, 2014 11:12:31 AM UTC-8, Ethan Furman wrote:
> If you really absolutely positively have to have the signature be correct for
> each instance, you may to either look at a
> function creating factory, a class creating factory, or a meta-class.
+1. Overriding __call__() wit
On 11/04/2014 08:52 AM, Roberto Martínez wrote:
I am trying to replace dinamically the __call__ method of an object
using setattr.
Example:
$ cat testcall.py
class A:
def __init__(self):
setattr(self, '__call__', self.newcall)
def __call__(self):
print("OLD")
d
On 11/04/2014 11:23 AM, Nathaniel Smith wrote:
(Or alternatively I guess you could go all in: Iä! Iä! Metaclasses Fhtagn!)
Metaclasses aren't that bad! I've written one.
And the dizzy spells are getting better!
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Nov 4, 2014 at 7:15 PM, Roberto Martínez
wrote:
>
>
> On Tue, Nov 4, 2014 at 8:06 PM, Skip Montanaro
> wrote:
>>
>>
>> On Tue, Nov 4, 2014 at 1:01 PM, Roberto Martínez
>> wrote:
>>>
>>> The workaround of calling a different method inside __call__ is not valid
>>> for my case because I wa
On Tue, Nov 4, 2014 at 8:06 PM, Skip Montanaro
wrote:
>
> On Tue, Nov 4, 2014 at 1:01 PM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
>> The workaround of calling a different method inside __call__ is not valid
>> for my case because I want to change the *signature* of the function
On 11/04/2014 11:01 AM, Roberto Martínez wrote:
(Ethan, sorry for posting to python-dev, I thought that it was an
implementation detail of CPython 3.X)
No worries. It's good practice to post here first, just in case. ;)
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 11/04/2014 11:01 AM, Roberto Martínez wrote:
Yikes, I didn't realize the difference in inheritance.
The thing with this is tricky. I need the change in the instance, not in the
class, because I have multiple instances
and all of them must have different implementations of __call__.
The work
On Tue, Nov 4, 2014 at 1:01 PM, Roberto Martínez wrote:
> The workaround of calling a different method inside __call__ is not valid
> for my case because I want to change the *signature* of the function also
> -for introspection reasons.
You could define __call__ like so:
def __call__(self, *a
Yikes, I didn't realize the difference in inheritance.
The thing with this is tricky. I need the change in the instance, not in
the class, because I have multiple instances and all of them must have
different implementations of __call__.
The workaround of calling a different method inside __call_
This list is for the development _of_ Python, not development _with_ Python.
Try asking on Python List.
(forwarding...)
On 11/04/2014 08:52 AM, Roberto Martínez wrote:
I am trying to replace dinamically the __call__ method of an object using
setattr.
Example:
$ cat testcall.py
class A:
26 matches
Mail list logo
