Re: [pypy-dev] getting rid of multimethods?
There is a niceness about how the multimethods group everything in one place. Assuming we ever want to run more than one object space at the same time, or more than one representation of a given type, how would we structure things so that we don't just have 'a handful of stuff over here, and then some more from over there' ... ? Laura
Hello, On Thu, Jun 17, 2004 at 08:10:41AM +0200, Laura Creighton wrote:
There is a niceness about how the multimethods group everything in one place.
Yes, their declarativeness is nice. I don't think we should remove them, but maybe we should move them away from run-time. It would be possible to use the multimethod declarations only to generate Python sources with the descriptors (i.e. the __add__&co methods). The type switches would be generated too. This is basically what Holger suggested for descroperation.py already. I still think that it is overkill for descroperation.py, but for multimethods it would be helpful as a check, or if you prefer reading the generated Python source instead of the multimethod.py magic. A bientot, Armin
Armin Rigo wrote:
In a way, turning multi-methods into a meta-class like concept that instantiates __add__ things on type creation time? Sounds like a good compromize. ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
[Armin Rigo Wed, Jun 23, 2004 at 05:01:45PM +0100]
Might be helpful.
Well, in my tree i moved some of the multimethod-declarations (getitem/setitem) for the dictobject into some dict-specific descriptors. I could reuse the existing methods without any modification. It's faster and easier to understand. But i see your point that in other cases the declarativeness of multimethods is nice. But I do think that their existence complicates the understanding of PyPy (at least for me :-). cheers, holger
Hello, On Thu, Jun 17, 2004 at 08:10:41AM +0200, Laura Creighton wrote:
There is a niceness about how the multimethods group everything in one place.
Yes, their declarativeness is nice. I don't think we should remove them, but maybe we should move them away from run-time. It would be possible to use the multimethod declarations only to generate Python sources with the descriptors (i.e. the __add__&co methods). The type switches would be generated too. This is basically what Holger suggested for descroperation.py already. I still think that it is overkill for descroperation.py, but for multimethods it would be helpful as a check, or if you prefer reading the generated Python source instead of the multimethod.py magic. A bientot, Armin
Armin Rigo wrote:
In a way, turning multi-methods into a meta-class like concept that instantiates __add__ things on type creation time? Sounds like a good compromize. ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
[Armin Rigo Wed, Jun 23, 2004 at 05:01:45PM +0100]
Might be helpful.
Well, in my tree i moved some of the multimethod-declarations (getitem/setitem) for the dictobject into some dict-specific descriptors. I could reuse the existing methods without any modification. It's faster and easier to understand. But i see your point that in other cases the declarativeness of multimethods is nice. But I do think that their existence complicates the understanding of PyPy (at least for me :-). cheers, holger
participants (4)
-
Armin Rigo -
Christian Tismer -
holger krekel -
Laura Creighton