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
Some changes I have submitted for the Sweep class have been reverted (without much comments), I have also reverted the related changes in tests (6eb24f2, d09b55e, dbea311). And now python (rightfully) complains because the default value Properties() for the property field of the dataclass Sweep is mutable.
This dance (and lots of anterior commits) could probably be avoided by first explicitly defining the intent of this string, either in comments or doc strings.
Here are a few questions that a newcomer like me would like to see answered in the code.
Why a separate Properties class? How are its fields different from the other ones in the Sweep class?
Is it possible to use private fields in the usual way? Namely:
Such declarations make evident that other classes should not modify self.start or self.span (which are functions) and self._start (which is private).
I suggest to remove the @property syntactic sugar, which trades some confusion for a few keystrokes. The code does not contain much comments, it may be useful to search all calls to sweep.set_start. Also, the fact that implementations in the Sweep class do use hidden accessors is surprising, they are intended for public interfaces.
What is the intent of self.lock? In some places, it seems that it should be a private field of the Sweep class, used in setters like above, in order to ensure that any change of the field value is protected. But...
DeviceSettings.py sets sweep.points without locking.
SweepSettings.py locks while calling self.app.vna.setTXPower(...), which does not seem to affect self.app.sweep.
Comparison of Sweep classes should probably use a documented function instead of redefining the python equality, so that it is easy to find where it is called from. For example, this portion of SweepWorker.py
with self.app.sweep.lock:
sweep = self.app.sweep.copy()
if sweep != self.sweep: # parameters changed
self.sweep = sweep
is hard to understand even with a comment.
May it be simplified like this ? (the answer probably depends on the intent of the lock)
if self.app.sweep != self.sweep: # parameters changed
self.sweep = self.app.sweep.copy()
Thanks
The text was updated successfully, but these errors were encountered:
* style, Sweep.py: remove a double negation
* style, NanoVNASaver.py: simplify sweepSource computation
* Sweep.py: add getters and setters for private fields
Beware that this commit removes a lock from
SweepSettings.update_tex_power, and adds one to
DeviceSettings.updatecustomPoint.
Both changse may be incorrect, depending on the role of the lock
(issue #657).
Follows: 6eb24f2d09b55edbea311
Since d09b55e, the Properties.name class attribute is overriden by
each assignment to the properties.name instance attribute.
This is most probably unwanted.
This commit
* removes @DataClass, which is confusing as some attributes are
managed because of the lock.
Because of this, it has to restore __repr__ and __eq__.
* provides getters and setters for private attributes, and
protects each update by a thread lock
* adds a regression test for the bug fixed by d09b55e (immutable
properties).
Hello.
Some changes I have submitted for the Sweep class have been reverted (without much comments), I have also reverted the related changes in tests (6eb24f2, d09b55e, dbea311). And now python (rightfully) complains because the default value Properties() for the property field of the dataclass Sweep is mutable.
This dance (and lots of anterior commits) could probably be avoided by first explicitly defining the intent of this string, either in comments or doc strings.
Here are a few questions that a newcomer like me would like to see answered in the code.
Why a separate Properties class? How are its fields different from the other ones in the Sweep class?
Is it possible to use private fields in the usual way? Namely:
Such declarations make evident that other classes should not modify self.start or self.span (which are functions) and self._start (which is private).
I suggest to remove the
@property
syntactic sugar, which trades some confusion for a few keystrokes. The code does not contain much comments, it may be useful to search all calls tosweep.set_start
. Also, the fact that implementations in the Sweep class do use hidden accessors is surprising, they are intended for public interfaces.What is the intent of self.lock? In some places, it seems that it should be a private field of the Sweep class, used in setters like above, in order to ensure that any change of the field value is protected. But...
DeviceSettings.py
setssweep.points
without locking.SweepSettings.py
locks while callingself.app.vna.setTXPower(...)
, which does not seem to affectself.app.sweep
.Comparison of Sweep classes should probably use a documented function instead of redefining the python equality, so that it is easy to find where it is called from. For example, this portion of
SweepWorker.py
is hard to understand even with a comment.
May it be simplified like this ? (the answer probably depends on the intent of the lock)
Thanks
The text was updated successfully, but these errors were encountered: