问题
I'm trying to create a base class with a number of abstract python properties, in python 3.7.
I tried it one way (see 'start' below) using the @property, @abstractmethod, @property.setter annotations. This worked but it doesn't raise an exception if the subclass doesn't implement a setter. That's the point of using @abstract to me, so that's no good.
So I tried doing it another way (see 'end' below) using two @abstractmethod methods and a 'property()', which is not abstract itself but uses those methods. This approach generates an error when instantiating the subclass:
# {TypeError}Can't instantiate abstract class FirstStep with abstract methods end
I'm clearly implementing the abstract methods, so I don't understand what it means. The 'end' property is not marked @abstract, but if I comment it out, it does run (but I don't get my property). I also added that test non-abstract method 'test_elapsed_time' to demonstrate I have the class structure and abstraction right (it works).
Any chance I'm doing something dumb, or is there some special behavior around property() that's causing this?
class ParentTask(Task):
def get_first_step(self):
# {TypeError}Can't instantiate abstract class FirstStep with abstract methods end
return FirstStep(self)
class Step(ABC):
# __metaclass__ = ABCMeta
def __init__(self, task):
self.task = task
# First approach. Works, but no warnings if don't implement setter in subclass
@property
@abstractmethod
def start(self):
pass
@start.setter
@abstractmethod
def start(self, value):
pass
# Second approach. "This method for 'end' may look slight messier, but raises errors if not implemented.
@abstractmethod
def get_end(self):
pass
@abstractmethod
def set_end(self, value):
pass
end = property(get_end, set_end)
def test_elapsed_time(self):
return self.get_end() - self.start
class FirstStep(Step):
@property
def start(self):
return self.task.start_dt
# No warnings if this is commented out.
@start.setter
def start(self, value):
self.task.start_dt = value
def get_end(self):
return self.task.end_dt
def set_end(self, value):
self.task.end_dt = value
回答1:
I suspect this is a bug in the interaction of abstract methods and properties.
In your base class, the following things happen, in order:
- You define an abstract method named
start
. - You create a new property that uses the abstract method from 1) as its getter. The name
start
now refers to this property, with the only reference to the original name now held bySelf.start.fget
. - Python saves a temporary reference to
start.setter
, because the namestart
is about to be bound to yet another object. - You create a second abstract method named
start
- The reference from 3) is given the abstract method from 4) to define a new property to replace the once currently bound to the name
start
. This property has as its getter the method from 1 and as its setter the method from 4). Nowstart
refers to this property;start.fget
refers to the method from 1);start.fset
refers to the method from 4).
At this point, you have a property, whose component functions are abstract methods. The property itself was not decorated as abstract, but the definition of property.__isabstractmethod__
marks it as such because all its component methods are abstract. More importantly, you have the following entries in Step.__abstractmethods__
:
start
, theproperty
end
, theproperty
set_end
, the setter forend
gen_end
, the getter forend
Note that the component functions for the start
property are missing, because __abstractmethods__
stores names of, not references to, things that need to be overriden. Using property
and the resulting property's setter
method as decorators repeatedly replace what the name start
refers to.
Now, in your child class, you define a new property named start
, shadowing the inherited property, which has no setter and a concrete method as its getter. At this point, it doesn't matter if you provide a setter for this property or not, because as far as the abc
machinery is concerned, you have provided everything it asked for:
- A concrete method for the name
start
- Concrete methods for the names
get_end
andset_end
- Implicitly a concrete definition for the name
end
, because all of the underlying functions for the propertyend
have been provided concrete definitions.
回答2:
@chepner answered and explained it well. Based on that, I came up with a way around it that is... well... you decide. Sneaky at best. But it achieves my 3 main goals:
- Raises exceptions for unimplemented setters in subclasses
- Supports the python property semantics (vs. functions etc)
- Avoids boilerplate re-declaring every property in every subclass which still might not have solved #1 anyway.
Just declare the abstract get/set functions in the base class (not the property). Then add a @classmethod initializer to the base class that creates the actual properties using those abstract methods, but at that point, they'll be concrete methods on the subclass.
It's a one liner after the subclass declaration to init the properties. Nothing enforces that call being made, so it's not ironclad. Not a big savings in this example, but I'll have many properties. The end results doesn't look as dirty as I thought it would. Would like to hear comments or warnings of things I'm overlooking.
from abc import abstractmethod, ABC
class ParentTask(object):
def __init__(self):
self.first_step = FirstStep(self)
self.second_step = SecondStep(self)
print(self.first_step.end)
print(self.second_step.end)
class Step(ABC):
def __init__(self, task):
self.task = task
@classmethod
def init_properties(cls):
cls.end = property(cls.get_end, cls.set_end)
@abstractmethod
def get_end(self):
pass
@abstractmethod
def set_end(self, value):
pass
class FirstStep(Step):
def get_end(self):
return 1
def set_end(self, value):
self.task.end = value
class SecondStep(Step):
def get_end(self):
return 2
def set_end(self, value):
self.task.end = value
FirstStep.init_properties()
SecondStep.init_properties()
ParentTask()
来源:https://stackoverflow.com/questions/65224767/python-abstract-property-cant-instantiate-abstract-class-with-abstract-me