I noticed that there are still some circular import errors between trace and observation, the strange thing being that if trace is being imported before observation then nothing happens but importing observation on its own causes a circular import.
My understanding is that this is because:
observation imports Observation from observation.py which imports from trace, which runs the imports from trace.py which imports Observation. So observation has a circular import built in.
trace imports from trace.py which imports Observation, which runs the imports for observation.py which imports State and Action but not Trace, so no direct circular import is caused.
- Importing
trace before observation fixes the circular import as trace.py (and the second Observation by proxy) won't need to be imported again.
Now the issue around circular imports was addressed in #143 and #145, so not sure if this is by design or if this use case was missed (naturally anything trace-like was always imported before anything observation-like as they would be used first). At the very least the user should get a more helpful message so they're not left scratching their head at an internal import error should they happen to import anything from observations first.
Additionally (and perhaps this should be a separate issue) but while we're on the topic of observations vs. traces, observations.print(view="details") crashes as the data structure isn't totally set up the same as TraceList, so maybe ObservationLists just shouldn't inherit print functionality?
@e-cal I think you designed most of the ObservationLists/TraceList functionality so maybe I'm just missing something, would like to know your thoughts on these 😃
I noticed that there are still some circular import errors between
traceandobservation, the strange thing being that iftraceis being imported beforeobservationthen nothing happens but importingobservationon its own causes a circular import.My understanding is that this is because:
observationimportsObservationfromobservation.pywhich imports fromtrace, which runs the imports fromtrace.pywhich importsObservation. Soobservationhas a circular import built in.traceimports fromtrace.pywhich importsObservation, which runs the imports forobservation.pywhich importsStateandActionbut notTrace, so no direct circular import is caused.tracebeforeobservationfixes the circular import astrace.py(and the secondObservationby proxy) won't need to be imported again.Now the issue around circular imports was addressed in #143 and #145, so not sure if this is by design or if this use case was missed (naturally anything trace-like was always imported before anything observation-like as they would be used first). At the very least the user should get a more helpful message so they're not left scratching their head at an internal import error should they happen to import anything from
observationsfirst.Additionally (and perhaps this should be a separate issue) but while we're on the topic of observations vs. traces,
observations.print(view="details")crashes as the data structure isn't totally set up the same asTraceList, so maybeObservationListsjust shouldn't inherit print functionality?@e-cal I think you designed most of the
ObservationLists/TraceListfunctionality so maybe I'm just missing something, would like to know your thoughts on these 😃