You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😃
The text was updated successfully, but these errors were encountered:
I noticed that there are still some circular import errors between
trace
andobservation
, the strange thing being that iftrace
is being imported beforeobservation
then nothing happens but importingobservation
on its own causes a circular import.My understanding is that this is because:
observation
importsObservation
fromobservation.py
which imports fromtrace
, which runs the imports fromtrace.py
which importsObservation
. Soobservation
has a circular import built in.trace
imports fromtrace.py
which importsObservation
, which runs the imports forobservation.py
which importsState
andAction
but notTrace
, so no direct circular import is caused.trace
beforeobservation
fixes the circular import astrace.py
(and the secondObservation
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 asTraceList
, so maybeObservationLists
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 😃The text was updated successfully, but these errors were encountered: