- Masking out SBCommandReturnObject::Printf() from the Python layer because SWIG and varargs do not get along well.
It is replaced by a Print("str") call which is equivalent to Printf("%s","str")
- Providing file-like behavior for SBStream with appropriate extension write() and flush() calls, plus documenting that these are only meant and only exist for Python
Documenting the file-like behavior on our website
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177877 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/www/python-reference.html b/www/python-reference.html
index 86edbc5..daf0b98 100755
--- a/www/python-reference.html
+++ b/www/python-reference.html
@@ -368,10 +368,9 @@
<b>lldb.SBCommandReturnObject</b>
</td>
<td class="content">
- A return object where you can indicate the success or failure of your command. You can also
- provide information for the command result by printing data into it. You can also just print
- data as you normally would in a python script and the output will show up; this is useful for
- logging, but the real output for your command should go in the result object.
+ A return object which encapsulates success/failure information for the command and output text
+ that needs to be printed as a result of the command. The plain Python "print" command also works but
+ text won't go in the result by default (it is useful as a temporary logging facility).
</td>
</tr>
<tr>
@@ -387,6 +386,9 @@
</td>
</tr>
</table>
+ <p>As a convenience, you can treat the result object as a Python file object, and say
+ print >>result, "my command does lots of cool stuff". SBCommandReturnObject and SBStream
+ both support this file-like behavior by providing write() and flush() calls at the Python layer.</p>
<p>One other handy convenience when defining lldb command-line commands is the command
<b>command script import</b> which will import a module specified by file path - so you
don't have to change your PYTHONPATH for temporary scripts. It also has another convenience