meatballhat
commented
2 weeks ago There's nothing strictly preventing adding an __init__ 👍🏼 But you should definitely be aware of the limitations. Cog depends on loading the specified predictor in such a way that if it appears to be a class, it will be instantiated without any arguments:
which would mean that this __init__ is OK ✅:
from cog import BasePredictor
class MyPredictor(BasePredictor):
def __init__(self):
self._state = {}
self._counter = 0
def predict(self, a: int) -> str:
...
but this __init__ is NOT OK ❌ because there's no way for Cog to know what a reasonable value is for counter:
from cog import BasePredictor
class MyPredictor(BasePredictor):
def __init__(self, counter: int):
self._state = {}
self._counter = counter
def predict(self, a: int) -> str:
...If you really want to be able to have __init__ arguments, you may want to consider building your predictor at module load time, e.g.:
from cog import BasePredictor
class MyPredictor(BasePredictor):
def __init__(self, counter: int):
self._state = {}
self._counter = counter
def predict(self, a: int) -> str:
...
predictor_instance = MyPredictor(counter=2)# cog.yaml
build:
python_version: '3.13'
predict: 'predict.py:predictor_instance'
Hi there,
my
setup()method is getting big and for readability's sake I'd like to split it into init actions (eg creation of attrs, sentry monitoring etc.) and setup actions (eg model downloading and loading into memory), respectively in dunder init and setup methods.I could find nothing preventing it, besides as the superclass
BasePredictordoes not have a dunder init as of the current latest cog version, there is no super init to handle. I tested it on a minimal example and it worked. I also noted I can access the logs emitted from the dunder init in Replicate's setup logs which is handy. Last, it has the added benefit to make linters happier (eg see this rule)Any argument against it ?
cc @mattt @bfirsh @andreasjansson