forked from OSchip/llvm-project
c7a56af307
When using the `script` Python repl, SB objects are printed in a way that gives the user no information. The simplest example is: ``` (lldb) script lldb.debugger <lldb.SBDebugger; proxy of <Swig Object of type 'lldb::SBDebugger *' at 0x1097a5de0> > ``` This output comes from the Python repl printing the `repr()` of an object. None of the SB classes implement `__repr__`, and all print like the above. However, many (most?, all?) SB classes implement `__str__`. Because they implement `__str__`, a more detailed output can be had by `print`ing the object, for example: ``` (lldb) script print(lldb.debugger) Debugger (instance: "debugger_1", id: 1) ``` For convenience, this change switches all SB classes that implement to `__str__` to instead implement `__repr__`. **The result is that `str()` and `repr()` will produce the same output**. This is because `str` calls `__repr__` for classes that have no `__str__` method. The benefit being that when writing a `script` invocation, you don't need to remember to wrap in `print()`. If that isn't enough motivation, consider the case where your Python expression results in a list of SB objects, in that case you'd have to `map` or use a list comprehension like `[str(x) for x in <expr>]` in order to see the details of the objects in the list. For reference, the docs for `repr` say: > repr(object) > Return a string containing a printable representation of an object. For > many types, this function makes an attempt to return a string that would > yield an object with the same value when passed to eval(); otherwise, the > representation is a string enclosed in angle brackets that contains the > name of the type of the object together with additional information often > including the name and address of the object. A class can control what this > function returns for its instances by defining a __repr__() method. and the docs for `__repr__` say: > object.__repr__(self) > Called by the repr() built-in function to compute the “official” string > representation of an object. If at all possible, this should look like a > valid Python expression that could be used to recreate an object with the > same value (given an appropriate environment). If this is not possible, a > string of the form <...some useful description...> should be returned. The > return value must be a string object. If a class defines __repr__() but not > __str__(), then __repr__() is also used when an “informal” string > representation of instances of that class is required. > > This is typically used for debugging, so it is important that the > representation is information-rich and unambiguous. Even if it were convenient to construct Python expressions for SB classes so that they could be `eval`'d, however for typical lldb usage, I can't think of a motivating reason to do so. As it stands, the only action the docs say to do, that this change doesn't do, is wrap the `repr` string in `<>` angle brackets. An alternative implementation is to change lldb's python repl to apply `str()` to the top level result. While this would work well in the case of a single SB object, it doesn't work for a list of SB objects, since `str([x])` uses `repr` to convert each list element to a string. Differential Revision: https://reviews.llvm.org/D127458 |
||
|---|---|---|
| .. | ||
| Inputs | ||
| LocalLLDBInit.test | ||
| TestCommands.test | ||
| TestConvenienceVariables.test | ||
| TestCore.test | ||
| TestError.test | ||
| TestFile.test | ||
| TestHelp.test | ||
| TestNoUseColor.test | ||
| TestPageZeroRead.test | ||
| TestPositionalArgs.test | ||
| TestProcessAttach.test | ||
| TestQuiet.test | ||
| TestRepl.test | ||
| TestSingleQuote.test | ||
| TestTarget.test | ||
| TestUseColor.test | ||