[pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

src/qibolab/channel.py

@@ -3,35 +3,37 @@
 
 @dataclass
 class NamedChannel:
-    """Channel that has a name. This is part of the end-user API, i.e. is in the top layer.
-    
+    """Channel that has a name. This is part of the end-user API, i.e. is in
+    the top layer.
+
     The idea is the following:
-        1. End users do not know what are the types of channels in a platform, they just know names. 
+        1. End users do not know what are the types of channels in a platform, they just know names.
            They use only NamedChannels to describe pulse sequences. They can create NamedChannels using the get_channel function below.
         2. User makes some assumptions about the types of channels. E.g. they assume that the channel NamedChannel("qubit_0/drive")
            is an IQ channel, hence they play IQ pulses on it, and they provide IQChannelConfig for it.
         3. Upon receival of the execution request qibolab validates that the requested execution can be done, i.e.
            channels with those names exist and user's assumptions are correct.
         4. qibolab proceeds with execution.
-    For the last two steps qibolab needs to replace generic NamedChannels with concrete channels (e.g. ZurichIQChannel, QbloxDCChannel, etc.), and 
+    For the last two steps qibolab needs to replace generic NamedChannels with concrete channels (e.g. ZurichIQChannel, QbloxDCChannel, etc.), and
     those should be available in the Platform description.
-    
+
     TODO: I am not sure if having this class brings any benefit to this plan compared to the case where we just use naked str names, but I will figure
     this out later during implementation.
-    
+
     TODO: One might argue that it is reasonable to provide the end user the types of channels as well, and then do all the validation while constructing the pulse
     sequence. I thought about this and failed to find real benefit, it just seems to complicate the code and the user-facing API for no real benefit.
     Please comment if you have anything to say regarding this.
     """
 
     name: str
-    
+
     def __str__(self) -> str:
         return self.name
 
 
 def get_channel(element: str, line: str) -> NamedChannel:
-    """Named channel for given element (qubit|qubit|coupler|etc.), for given line (drive|flux|readout|etc.)
+    """Named channel for given element (qubit|qubit|coupler|etc.), for given
+    line (drive|flux|readout|etc.)
 
     This method can be used by users to get the channel that they are interested in, and then use this in their pulse sequence description.
 

src/qibolab/channel_config.py

@@ -1,5 +1,6 @@
 from dataclasses import dataclass
 from enum import Enum
+
 """Definitions for common options for various types of channels. This is part of the end-user API, i.e. is in the top layer.
 """
 
@@ -35,4 +36,3 @@ class AcquisitionChannelConfig:
     integration_weights_i: list[float]
     integration_weights_q: list[float]
     classification_kernel: float  # FIXME
-

src/qibolab/instruments/abstract_channels.py

@@ -11,7 +11,6 @@
 
 
 class IQChannel(ABC):
-
     @abstractmethod
     def foo(self, args, kwargs):
         ...
@@ -22,7 +21,6 @@ def bar(self, args):
 
 
 class DCChannel(ABC):
-
     @abstractmethod
     def baz(self, kwargs):
-        ...
+        ...

src/qibolab/instruments/zi/channels.py

@@ -2,17 +2,16 @@
 from qibolab.channel_config import IQChannelConfig
 from qibolab.instruments.abstract_channels import IQChannel
 
-"""The glue part of the platform shall manually define all channels according to wiring, 
+"""The glue part of the platform shall manually define all channels according to wiring,
 then for each user request appropriate channels will be collected for handling the execution.
 """
 
 
 class ZIIQChannel(IQChannel, NamedChannel):
-    """IQChannel using a from Zurich instruments
-    """
+    """IQChannel using a from Zurich instruments."""
 
     config: IQChannelConfig
-    
+
     # FIXME: add all the necessary stuff needed to define a ZI IQ channel
 
     def foo(self, args, kwargs):
@@ -21,4 +20,5 @@ def foo(self, args, kwargs):
     def bar(self, args):
         ...
 
-# TODO: Similarly, other ZI channels can be implemented
+
+# TODO: Similarly, other ZI channels can be implemented