MCPcopy
hub / github.com/mitmproxy/mitmproxy / Log

Class Log

mitmproxy/proxy/commands.py:129–159  ·  view source on GitHub ↗

Log a message. Layers could technically call `logging.log` directly, but the use of a command allows us to write more expressive playbook tests. Put differently, by using commands we can assert that a specific log message is a direct consequence of a particular I/O event. This

Source from the content-addressed store, hash-verified

127
128
129class Log(Command):
130 """
131 Log a message.
132
133 Layers could technically call `logging.log` directly, but the use of a command allows us to
134 write more expressive playbook tests. Put differently, by using commands we can assert that
135 a specific log message is a direct consequence of a particular I/O event.
136 This could also be implemented with some more playbook magic in the future,
137 but for now we keep the current approach as the fully sans-io one.
138 """
139
140 message: str
141 level: int
142
143 def __init__(
144 self,
145 message: str,
146 level: int = logging.INFO,
147 ):
148 if isinstance(level, str): # pragma: no cover
149 warnings.warn(
150 "commands.Log() now expects an integer log level, not a string.",
151 DeprecationWarning,
152 stacklevel=2,
153 )
154 level = getattr(logging, level.upper())
155 self.message = message
156 self.level = level
157
158 def __repr__(self):
159 return f"Log({self.message!r}, {logging.getLevelName(self.level).lower()})"

Callers 15

_handle_eventMethod · 0.90
test_pingFunction · 0.90
test_unknown_extFunction · 0.90
test_socks5_errFunction · 0.90
test_socks5_auth_failFunction · 0.90

Calls

no outgoing calls

Tested by 15

_handle_eventMethod · 0.72
test_pingFunction · 0.72
test_unknown_extFunction · 0.72
test_socks5_errFunction · 0.72
test_socks5_auth_failFunction · 0.72