On Monday, 26 March 2018 11:32:51 UTC+5:30, dieter wrote:
> Fürther inspection utilities: "dir", "vars" and the "inspect" module.
> Read the documentation to find out what they do.
Thanks, Dieter, That is really helpful!
--
https://mail.python.org/mailman/listinfo/python-list
Arshpreet Singh writes:
> ...
> As debugging the code I got at line 10. I am sending a request to particular
> API and returning a request_object . further deep down it generates the
> "response_object" as from my requirements that should be JSON object but I am
> only getting Python-Object in
nse.
I am also able to call __call__ method something like this:
def hierarchy_attach(env, parent):
svc = IMS(env)
svc(parent)
--
https://mail.python.org/mailman/listinfo/python-list
sion -- I'm not actually using a Singleton,
but it's an easy situation to think about.
I'd like to ask a couple follow up questions here:
By using...
@classmethod
def normal_constructor(cls, *args, **kwargs):
return type.__call__(cls, *args, **kwargs) # Aside: Yes, the `cls`
do
f normal_constructor(cls, *args, **kwargs):
> return type.__call__(*args, **kwargs)
Untested, but I think that should be:
return type.__call__(cls, *args, **kwargs)
> @classmethod
> def normal_constructor(cls, *args, **kwargs):
> return super(???).__call__(*args, **kw
on't often deal with multiple class
constructors, so I'm a bit new to that territory and I'm trying to delve
into the details of how python classes are constructed (namely, whether
`type.__call__` does more than just call `cls.__new__` and `self.__init__`).
Thanks for the help too.
Thanks for the reply. And I think I wasn't clear enough. I was wondering
what the metaclass `type`'s `type.__call__` does explicitly. I'm reasonably
comfortable writing metaclasses when I need them, and I understand how
`.__call__` works for non-metaclass objects.
In my first ema
this metaclass from being used.
To do that, I think I just make a @classmethod constructor function.
However, I can imagine a few different ways of writing this:
@classmethod
def normal_constructor(cls, *args, **kwargs):
return type.__call__(*args, **kwargs)
@classmethod
def normal_constru
On 2017-10-19 10:11, ast wrote:
> Surprisingly, __call__ from the class is called, not the
> one defined in the object. Why ?
That's just how dunder methods like __call__ work.
See https://docs.python.org/3/reference/datamodel.html#special-method-names
To quote the docs:
> For
t;self.a = 2
>> self.f = lambda : print("f from object")
>> self.__call__ = lambda : print("__call__ from object")
>> def __call__(self):
>>print("__call__ from class Test")
>> def f(self):
>>
On Thu, Oct 19, 2017 at 7:11 PM, ast wrote:
> Hello, please have a look at following code snippet
> (python 3.4.4)
>
> class Test:
>
>a = 1
>
>def __init__(self):
>self.a = 2
>self.f = lambda : print("f from object")
> se
Hello, please have a look at following code snippet
(python 3.4.4)
class Test:
a = 1
def __init__(self):
self.a = 2
self.f = lambda : print("f from object")
self.__call__ = lambda : print("__call__ from object")
def __call__(self):
es?
I've never actually done it, but there've been times when I've
considered setting __call__ to be a class, rather than an actual
function. (Though the time I wanted it, I was wanting to set __call__
on a module, and I ended up not bothering with the hassle that that
entails.) Python c
= func.func_globals
elif inspect.isbuiltin(func):
func_globals = sys.modules[func.__module__].__dict__
elif inspect.ismethoddescriptor(func):
raise TypeError("Can't get globals of a method descriptor")
What if func is actually an instance of a class with a __call__ method? S
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 wh
re -- not sure how much could break because of that
>> though
>>
>
> Something fairly fundamental that would break is classs
> instantiation! You instantiate a class by calling it, so if
> a(x) were implemented as a.__call__(x), and class C had
> a __call__ method, then C(
te a class by calling it, so if
a(x) were implemented as a.__call__(x), and class C had
a __call__ method, then C() would invoke that method
instead of instantiating C.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
pens the way it does
> though, so, can someone from python-dev give some background of why that's
> the way it is? i.e.: instead of the approach which would seem simpler which
> would do getattr(a, '__call__') instead of
> type(a).__dict__['__call__'].__get__(a,
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
> > obje
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
&g
ng on that just "look up __call__ in the class
object", because evaluating C.__call__ just returns the descriptor
and doesn't invoking the descriptor mechanism.)
which seems to clash with what you just said.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
nstance, though.
> Normally, if you look up an attribute on a class,
> the descriptor protocol doesn't get triggered.
Since this whole thread is about giving instances their own individual
__call__ methods, I don't think that doing the look-up on the class is part
of the requiremen
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, %
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, th
to either look at a
function creating factory, a class creating factory, or a meta-class.
+1. Overriding __call__() within the class definition, over and over again,
with different function, looks awkward to me.
A possibility to get the original approach implemented looks like:
make
> for each instance, you may to either look at a
>>>> function creating factory, a class creating factory, or a meta-class.
>>>
>>> +1. Overriding __call__() within the class definition, over and over
>>> again, with different function, looks awkward to
factory, or a meta-class.
+1. Overriding __call__() within the class definition, over and over again,
with different function, looks awkward to me.
A possibility to get the original approach implemented looks like:
make "__call__" a descriptor on the class which looks up the real
factory, or a meta-class.
>
> +1. Overriding __call__() within the class definition, over and over again,
> with different function, looks awkward to me.
A possibility to get the original approach implemented looks like:
make "__call__" a descriptor on the class which
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__.
&g
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
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):
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
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 t
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__.
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 __ca
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 i
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
/Empirical_distribution_function)
using vectorized numpy methods.
Here is the **correct** solution to problem:
class ecdf:
def __init__(self, observations):
self.observations = np.asarray(observations)
def __call__(self, x):
return np.mean(self.observations <= x)
On 10/07/2013 04:27 AM, Steven D'Aprano wrote:
On Sun, 06 Oct 2013 20:17:33 +0200, Marco Buttu wrote:
>
> >>> class FooMeta(type):
>... def __call__(metacls, name, bases, namespace):
>... print("FooMeta.__call__()")
...
> From what I undes
On Sun, 06 Oct 2013 20:17:33 +0200, Marco Buttu wrote:
> Hi all, I have a question about class creation and the __call__ method.
> I have the following metaclass:
>
> >>> class FooMeta(type):
> ... def __call__(metacls, name, bases, namespace):
> ...prin
Marco Buttu wrote:
> Hi all, I have a question about class creation and the __call__ method.
> I have the following metaclass:
>
> >>> class FooMeta(type):
> ... def __call__(metacls, name, bases, namespace):
> ... print("FooMeta.__call__()")
&
Hi all, I have a question about class creation and the __call__ method.
I have the following metaclass:
>>> class FooMeta(type):
... def __call__(metacls, name, bases, namespace):
... print("FooMeta.__call__()")
From what I undestood, at the end of the clas
On Tue, Nov 20, 2012 at 10:29 AM, Marco wrote:
> Because when I call an instance the __call__ method is called, and because
> the classes are instances of type, I thought when I call a Foo class this
> imply the call type.__call__(Foo), and so this one manages the Foo.__new__
> and
when I call an instance the __call__ method is called, and
because the classes are instances of type, I thought when I call a Foo
class this imply the call type.__call__(Foo), and so this one manages
the Foo.__new__ and Foo.__init__ calls:
>>> class Foo:
... def __
On 10/18/2012 10:30 PM, Peng Yu wrote:
Hi,
reference.pdf from python document has the following description. It
is not accessible from help() in the command line. Is there an
alternative so that I can quickly access these class attributes or
method names from the command line?
object.__call__
Hi,
reference.pdf from python document has the following description. It
is not accessible from help() in the command line. Is there an
alternative so that I can quickly access these class attributes or
method names from the command line?
object.__call__(self [, args... ])
Called when the
What I was thinking was something along the lines of a loop-back
reference in the wrapper itself. So for instance:
Foo.__call__ = wrapper(Foo)
The wrapper would be created with a __call__ method of itself:
self.__call__ = self
That would not require a dictionary, it's just a special case
On 4/1/2011 11:07 AM, Corey Richardson wrote:
All callables (things you can foo(bar)) are really just objects that
implement the __call__ method, as far as I understand.
> Well then, that would appear to make methods themselves callable,
Method are just function objects that are cl
On Sat, Apr 2, 2011 at 2:07 AM, Corey Richardson wrote:
> All callables (things you can foo(bar)) are really just objects that
> implement the __call__ method, as far as I understand. Well then, that
> would appear to make methods themselves callable, so let's do a little
&g
All callables (things you can foo(bar)) are really just objects that
implement the __call__ method, as far as I understand. Well then, that
would appear to make methods themselves callable, so let's do a little
playing around...
lavos@lavos ~ $ python
Python 2.6.6 (r266:84292, Sep 15 2010,
t;, "copyright", "credits" or "license" for more information.
>>>> import Muffle_ZeroDivision
>>>> calc = Muffle_ZeroDivision.MuffledCalculator()
>>>> calc = ('10/2')
>>>> cal
ion
calc = Muffle_ZeroDivision.MuffledCalculator()
calc = ('10/2')
calc = Muffle_ZeroDivision.MuffledCalculator()
calc('10/2')
Traceback (most recent call last):
File "", line 1, in
AttributeError: MuffledCalculator instance has no __call__ method
---
lc = Muffle_ZeroDivision.MuffledCalculator()
>>> calc = ('10/2')
>>> calc = Muffle_ZeroDivision.MuffledCalculator()
>>> calc('10/2')
Traceback (most recent call last):
File "", line 1, in
AttributeError: MuffledCalculator instance has no __call__ method
--
hat
you want, then this is probably the simplest approach:
Start by adding delegation to the Compute class:
class Compute(object):
def __init__(self, something):
self.something = something
def __call__(self, *args, **kwargs):
return self.function(*args, **kwargs)
Then you can init
andling.
> >> > I have 'B' and 'C' which specialise upon 'A'
>
> >> > What I'd like to achieve is something similar to:
>
> >> > @inject(B):
> >> > def some_function(a, b):
> >> >
On Sat, Mar 13, 2010 at 8:19 AM, Jon Clements wrote:
> The name 'some_function' is completely redundant -- don't need it,
> don't actually care about the function afterwards, as long as it
> becomes a __call__ of a 'B' *instance*.
>
Special methods ar
pon 'A'
>>
>> > What I'd like to achieve is something similar to:
>>
>> > @inject(B):
>> > def some_function(a, b):
>> > pass # something useful
>>
>> > The name 'some_function' is completely redundant -- don't need
; @inject(B):
> > def some_function(a, b):
> > pass # something useful
>
> > The name 'some_function' is completely redundant -- don't need it,
> > don't actually care about the function afterwards, as long as it
> > becomes a __call__ of a
a, b):
> > > pass # something useful
>
> > So, just typing at the keyboard here, you mean something like:
>
> > class InjectClass(object):
> > def __init__(self, func, *args, **kw):
> > self.func = func
> > self.args = args
>
e name 'some_function' is completely redundant -- don't need it,
> don't actually care about the function afterwards, as long as it
> becomes a __call__ of a 'B' *instance*.
>
> I've basically got a huge list of functions, which need to be the
> cal
ard here, you mean something like:
>
> class InjectClass(object):
> def __init__(self, func, *args, **kw):
> self.func = func
> self.args = args
> self.kw = kw
> def __call__(self):
> self.func(*self.args, **self.kw)
>
> Or exactl
__(self, func, *args, **kw):
self.func = func
self.args = args
self.kw = kw
def __call__(self):
self.func(*self.args, **self.kw)
Or exactly what are you looking for?
Pat
--
http://mail.python.org/mailman/listinfo/python-list
'C' which specialise upon 'A'
What I'd like to achieve is something similar to:
@inject(B):
def some_function(a, b):
pass # something useful
The name 'some_function' is completely redundant -- don't need it,
don't actually care about the function a
On Thu, 11 Mar 2010 07:56:59 -0500, Neal Becker wrote:
> The example I showed was just a toy problem. The real problem is I
> expect to call a function many times, and I want to avoid the overhead
> of the 'if blah' everytime.
Unless the __call__ methods are very small,
On Thu, 11 Mar 2010 08:20:14 -0800, Steve Howell wrote:
>> (2) special methods like __call__ are only called on the class, not the
>> instance, so you can't give each instance its own method.
>>
>>
> Are you sure about that? This program prints 1, 2, 1, 2.
T
Steve Howell wrote:
> On Mar 10, 7:18 pm, Steven D'Aprano
> wrote:
>> (2) special methods like __call__ are only called on the class, not the
>> instance, so you can't give each instance its own method.
> Are you sure about that? This program prints 1, 2, 1, 2.
On Mar 10, 7:18 pm, Steven D'Aprano
wrote:
> On Wed, 10 Mar 2010 08:12:14 -0500, Neal Becker wrote:
> > Want to switch __call__ behavior. Why doesn't this work? What is the
> > correct way to write this?
>
> > class X (object):
> > def
Andre Engels wrote:
On Thu, Mar 11, 2010 at 2:30 PM, Steve Holden wrote:
The example I showed was just a toy problem. The real problem is
I expect to call a function many times, and I want to avoid the overhead of
the 'if blah' everytime.
This is a premature optimization. First, make it wor
On Thu, Mar 11, 2010 at 2:30 PM, Steve Holden wrote:
>> The example I showed was just a toy problem. The real problem is
>> I expect to call a function many times, and I want to avoid the overhead of
>> the 'if blah' everytime.
>>
> This is a premature optimization. First, make it work. Then (if
Neal Becker wrote:
> Steven D'Aprano wrote:
>
>> On Wed, 10 Mar 2010 08:12:14 -0500, Neal Becker wrote:
>>
>>> Want to switch __call__ behavior. Why doesn't this work? What is the
>>> correct way to write this?
>>>
>>> class
Steven D'Aprano wrote:
> On Wed, 10 Mar 2010 08:12:14 -0500, Neal Becker wrote:
>
>> Want to switch __call__ behavior. Why doesn't this work? What is the
>> correct way to write this?
>>
>> class X (object):
>> def __init__(self, i):
>>
On Wed, 10 Mar 2010 08:12:14 -0500, Neal Becker wrote:
> Want to switch __call__ behavior. Why doesn't this work? What is the
> correct way to write this?
>
> class X (object):
> def __init__(self, i):
> if i == 0:
> def __call__ (self):
Robert Kern wrote:
> On 2010-03-10 12:23 PM, Neal Becker wrote:
>> Duncan Booth wrote:
>> ...
>>>
>>> P.S. I don't know what you did in your post but your Followup-To header
>>> is pointing to a group on gmane which makes extra work for me replying.
>>> Please don't do that.
>>
>> I'm sorry about
On 2010-03-10 12:23 PM, Neal Becker wrote:
Duncan Booth wrote:
...
P.S. I don't know what you did in your post but your Followup-To header is
pointing to a group on gmane which makes extra work for me replying.
Please don't do that.
I'm sorry about that, there is some bad interaction between
On 2010-03-10 13:42 PM, Neal Becker wrote:
Duncan Booth wrote:
Neal Becker wrote:
Duncan Booth wrote:
...
P.S. I don't know what you did in your post but your Followup-To
header is pointing to a group on gmane which makes extra work for me
replying. Please don't do that.
I'm sorry about
Duncan Booth wrote:
> Neal Becker wrote:
>
>> Duncan Booth wrote:
>> ...
>>>
>>> P.S. I don't know what you did in your post but your Followup-To
>>> header is pointing to a group on gmane which makes extra work for me
>>> replying. Please don't do that.
>>
>> I'm sorry about that, there is so
Neal Becker wrote:
> Duncan Booth wrote:
> ...
>>
>> P.S. I don't know what you did in your post but your Followup-To
>> header is pointing to a group on gmane which makes extra work for me
>> replying. Please don't do that.
>
> I'm sorry about that, there is some bad interaction between gmane'
Duncan Booth wrote:
...
>
> P.S. I don't know what you did in your post but your Followup-To header is
> pointing to a group on gmane which makes extra work for me replying.
> Please don't do that.
I'm sorry about that, there is some bad interaction between gmane's nntp-
smtp gateway and python's
our its usually best to use different classes.
You can keep all the common behaviour in a base class and just override the
__call__ method for the different behaviour. Then use a factory function to
decide which class to instantiate or else override __new__ and make the
decision there. e.g.
Neal Becker wrote:
> Simon Brunning wrote:
>
>> On 10 March 2010 13:12, Neal Becker wrote:
>>> Want to switch __call__ behavior. Why doesn't this work? What is the
>>> correct way to write this?
>>>
>>> class X (object):
>>>
Simon Brunning wrote:
> On 10 March 2010 13:12, Neal Becker wrote:
>> Want to switch __call__ behavior. Why doesn't this work? What is the
>> correct way to write this?
>>
>> class X (object):
>> def __init__(self, i):
>> if i == 0:
>> def __
Neal Becker wrote:
Want to switch __call__ behavior. Why doesn't this work? What is the
correct way to write this?
class X (object):
def __init__(self, i):
if i == 0:
def __call__ (self):
return 0
else:
def __call_
On 10 March 2010 13:12, Neal Becker wrote:
> Want to switch __call__ behavior. Why doesn't this work? What is the
> correct way to write this?
>
> class X (object):
> def __init__(self, i):
> if i == 0:
> def __call__ (self):
>
Want to switch __call__ behavior. Why doesn't this work? What is the
correct way to write this?
class X (object):
def __init__(self, i):
if i == 0:
def __call__ (self):
return 0
else:
def __call_ (self):
return
ck (most recent call last):
File "/usr/lib/python2.6/SocketServer.py", line 320, in
finish_request
self.RequestHandlerClass(request, client_address, self)
AttributeError: Negotiator instance has no __call__ method
class ServerNegotiat
tServer.py", line 320, in
finish_request
self.RequestHandlerClass(request, client_address, self)
AttributeError: Negotiator instance has no __call__ method
here's the handler and my server:
#server side negotiator
from message import message
from share
On Jan 16, 10:13 pm, Christian Heimes wrote:
> Any callable in Python 3.0 has a "__call__" attribute.
Aha! Thanks! Andrew
--
http://mail.python.org/mailman/listinfo/python-list
andrew cooke schrieb:
> I think I'm missing something obvious here, so apologies in advance.
>
> I'd like to be able to test whether something is a function or
> implements __call__. Now obviously I can do that as two separate
> tests, but I though this was what ABCs we
I think I'm missing something obvious here, so apologies in advance.
I'd like to be able to test whether something is a function or
implements __call__. Now obviously I can do that as two separate
tests, but I though this was what ABCs were for. However, for the
life of me I cannot
Terry Reedy udel.edu> writes:
> > The bug went something like this:
> >
> > obj = some.default_class
> > ...
> > if some_other_rare_condition_met:
> > ... several lines ...
> > obj = some.other_class()
>
> Should that have been some.other_class (without the ()s?).
Ei
Skip Montanaro a écrit :
>>> In this case there was a bug. Depending on inputs, sometimes obj
>>> initialized to a class, sometimes an instance of that class. (I fixed
>>> that too while I was at it.) The problem was that the use of __call__
>>> obscu
[EMAIL PROTECTED] wrote:
> In this particular case it was clearly unnecessary and just obfuscated
> the code. I'm wondering, are there some general cases where __call__
> methods of a user-defined class are simply indispensable?
I don't know that you couldn't live withou
Skip Montanaro a écrit :
>>> In this case there was a bug. Depending on inputs, sometimes obj
>>> initialized to a class, sometimes an instance of that class. (I fixed
>>> that too while I was at it.) The problem was that the use of __call__
>>> obscu
> > In this case there was a bug. Depending on inputs, sometimes obj
> > initialized to a class, sometimes an instance of that class. (I fixed
> > that too while I was at it.) The problem was that the use of __call__
> > obscured the underlying bug by making the insta
On Aug 2, 2:30 pm, [EMAIL PROTECTED] wrote:
> I'm wondering, are there some general cases where __call__ methods of
> a user-defined class are simply indispensable?
Indispensable's a strong word, but one thing that entails calling
syntax, and can't (reasonably) be don
On Aug 2, 4:27 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > In this particular case it was clearly unnecessary and just obfuscated the
> > code. I'm wondering, are there some general cases where __call__ methods of
> >
James Stroud wrote:
> import functools
> class enclosable(object):
> def __init__(self, func):
> self.func = func
> def __call__(self, *args, **kwargs):
> return functools.partial(self.func, *args, **kwargs)
>
> For example:
>
> @enclosable
> def
1 - 100 of 193 matches
Mail list logo
