Mr.Rech wrote:
> and so on. The problem I'm worried about is that an unaware user may
> create an instance of "A" supposing that it has any real use, while it
> is only a sort of prototype. However, I can't see (from my limited
> point of view) any other way to rearrange things and still get a
> s
On Fri, Dec 02, 2005 at 10:43:56AM +0100, bruno at modulix wrote:
> Inyeol Lee wrote:
> (snip)
>
> class A(object):
> ... def __init__(self, foo):
> ... if self.__class__ is A:
> ... raise TypeError("A is base class.")
>
>
> s/TypeError/NotI
I see your point. Looking again at my metaclass implementation and
comparing it with your abstract class + inheritance approach it turns
out that the latter is definetively more straightforward, easier to
maintain and all in all more pythonic.
Sorry, but being an OOP newbie put me in the position
Mr.Rech wrote:
> Thanks for your suggestions. They are very usefull and indeed bypass my
> problem. However, I've found a (perhaps) more elegant way to get the
> same result using metaclasses.
(snip code)
>
> I know metaclasses are a complete different beast, anyway I find this
> approach more
Mr.Rech wrote:
> Thanks for your suggestions. They are very usefull and indeed bypass my
> problem. However, I've found a (perhaps) more elegant way to get the
> same result using metaclasses. My idea is to define my classes as
> follows:
>
class meta_A(type):
> def __new__(cls, cl
Thanks for your suggestions. They are very usefull and indeed bypass my
problem. However, I've found a (perhaps) more elegant way to get the
same result using metaclasses. My idea is to define my classes as
follows:
>>> class meta_A(type):
def __new__(cls, classname, bases, classdict):
Inyeol Lee wrote:
(snip)
class A(object):
... def __init__(self, foo):
... if self.__class__ is A:
... raise TypeError("A is base class.")
s/TypeError/NotImplementedError/
s/base class/abstract class/
--
bruno desthuilliers
python -c "pri
Mr.Rech wrote:
> Suppose I have a bunch of classes that represent slightly (but
> conceptually) different object. The instances of each class must behave
> in very similar manner, so that I've created a common class ancestor
> (let say A) that define a lot of special method (such as __getattr__,
>
"Mr.Rech" <[EMAIL PROTECTED]> writes:
> Suppose I have a bunch of classes that represent slightly (but
> conceptually) different object. The instances of each class must behave
> in very similar manner, so that I've created a common class ancestor
> (let say A) that define a lot of special method (
On Thu, Dec 01, 2005 at 03:51:05PM -0800, Mr.Rech wrote:
[...]
> Suppose I have a bunch of classes that represent slightly (but
> conceptually) different object. The instances of each class must behave
> in very similar manner, so that I've created a common class ancestor
> (let say A) that define
Hi all,
I've been using Python for 3 years, but I've rarely used its OOP
features (I'm a physicist, sorry). Now, after having read a lot about
Python OOP capabilities, I'm trying to get advantage of this (for me)
new paradigm. As a result I've a lot of somewhat philosophical
questions. I will start
11 matches
Mail list logo
