[EMAIL PROTECTED] wrote:
> Thanks Peter. Yeah I had thought of that earlier, but wasn't sure if
> this is a standard design pattern for what I'm trying to achieve. It
> seems ugly to me to use 2 classes when you are essentially describing a
> single type.
To me both Exposed and ExposedType lo
Peter Otten wrote:
> [EMAIL PROTECTED] wrote:
>
> You define one base type with a custom metaclass and inherit from that. Your
> example then becomes:
>
> import sys
>
> class ExposedType( type ):
> def __init__( cls, *args, **kw ):
> # Track marked exposed methods
> cls.s_expos
no need for all that,i wrote a basic Ajax framework for cherrypy that
features a Ajax.Net feature,exposing functions to JavaScript via
attributes(or in python via decorators),here is a decorator that run
one time(i.e. before running the actual code) and get the name of the
class
[code]
def AddFunct
[EMAIL PROTECTED] wrote:
> Thanks for all the help guys ... in almost every way using a metaclass
> seems to be the right solution for what I'm trying to do here. I say
> almost because there is one thing that is still confusing me: what is
> the most elegant way to provide base-class implementat
Thanks for all the help guys ... in almost every way using a metaclass
seems to be the right solution for what I'm trying to do here. I say
almost because there is one thing that is still confusing me: what is
the most elegant way to provide base-class implementations of methods
that are expected
[EMAIL PROTECTED] wrote:
> Bruno Desthuilliers wrote:
>
>>[EMAIL PROTECTED] wrote:
>>
>>>I'm developing a library at the moment that involves many classes, some
>>>of which have "exposed" capabilities. I'm trying to design a nice
>>>interface for both exposing those capabilities, and inspecting
>
Maric Michaud wrote:
> Le jeudi 05 octobre 2006 17:18, [EMAIL PROTECTED] a écrit :
>> I guess my solution is slightly less elegant because
>> it requires this ugly explicit init call outside the classes that it
>> actually deals with, however it is more efficient because the dir()
>> pass happens o
[EMAIL PROTECTED] wrote:
> Bruno Desthuilliers wrote:
(snip)
>> class Exposing(object):
>> @classmethod
>> def get_exposed_methods(cls):
>> try:
>> exposeds = cls._exposed_methods
>> except AttributeError:
>> exposeds = []
>> for name in dir(cls):
>> obj = geta
Le jeudi 05 octobre 2006 17:18, [EMAIL PROTECTED] a écrit :
> I guess my solution is slightly less elegant because
> it requires this ugly explicit init call outside the classes that it
> actually deals with, however it is more efficient because the dir()
> pass happens once on module load, instead
Bruno Desthuilliers wrote:
> [EMAIL PROTECTED] wrote:
> > I'm developing a library at the moment that involves many classes, some
> > of which have "exposed" capabilities. I'm trying to design a nice
> > interface for both exposing those capabilities, and inspecting
> > instances to find out what
[EMAIL PROTECTED] wrote:
> I'm developing a library at the moment that involves many classes, some
> of which have "exposed" capabilities. I'm trying to design a nice
> interface for both exposing those capabilities, and inspecting
> instances to find out what capabilities they have.
>
> At the m
I'm developing a library at the moment that involves many classes, some
of which have "exposed" capabilities. I'm trying to design a nice
interface for both exposing those capabilities, and inspecting
instances to find out what capabilities they have.
At the moment, I'm leaning towards a supercla
12 matches
Mail list logo
