Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #80402
| Date | 2014-11-08 11:49 -0800 |
|---|---|
| From | Ethan Furman <ethan@stoneleaf.us> |
| Subject | Re: [Python-Dev] Dinamically set __call__ method |
| References | (3 earlier) <mailman.15467.1415128339.18130.python-list@python.org> <c25aa612-bff2-4982-8fb9-5b17a866bead@googlegroups.com> <87a943qyvn.fsf@handshake.de> <545CC204.2010301@stoneleaf.us> <8761eq424e.fsf@handshake.de> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.15584.1415476169.18130.python-list@python.org> (permalink) |
On 11/07/2014 10:50 PM, dieter wrote: > Ethan Furman <ethan@stoneleaf.us> 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 >>>>> 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 "__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? Once the descriptor is resolved, you get the final > instance method - with the correct signature. Hmmm... well, it wouldn't be correct on a class lookup, but, yeah, it would be correct for an instance lookup -- and maybe that's good enough for the OP. -- ~Ethan~
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-04 11:12 -0800
Re: [Python-Dev] Dinamically set __call__ method John Ladasky <john_ladasky@sbcglobal.net> - 2014-11-06 12:21 -0800
Re: [Python-Dev] Dinamically set __call__ method dieter <dieter@handshake.de> - 2014-11-07 07:59 +0100
Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-07 04:58 -0800
Re: [Python-Dev] Dinamically set __call__ method dieter <dieter@handshake.de> - 2014-11-08 07:50 +0100
Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-08 11:49 -0800
Re: [Python-Dev] Dinamically set __call__ method Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-09 11:31 +1300
Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-08 19:27 -0800
Re: [Python-Dev] Dinamically set __call__ method Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-10 00:38 +1300
Re: [Python-Dev] Dinamically set __call__ method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-10 00:14 +1100
Re: [Python-Dev] Dinamically set __call__ method Ethan Furman <ethan@stoneleaf.us> - 2014-11-09 12:16 -0800
Re: [Python-Dev] Dinamically set __call__ method Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-11 00:43 -0700
Re: [Python-Dev] Dinamically set __call__ method Fabio Zadrozny <fabiofz@gmail.com> - 2014-11-12 13:33 -0200
Re: [Python-Dev] Dinamically set __call__ method Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-13 17:20 +1300
Re: [Python-Dev] Dinamically set __call__ method Fabio Zadrozny <fabiofz@gmail.com> - 2014-11-13 11:38 -0200
Re: [Python-Dev] Dinamically set __call__ method Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 11:58 -0700
csiph-web