Group items tagged

Unicode and new style string formatting Python 2.6 and Python 3 gain a new style of string formatting, which is apparently based on the string formatting in C#. I wasn't a big fan of the string formatting in C# and so wasn't very excited about it moving into Python, but as is to be expected it has grown a bit on me.

As always, the best solution is to not mix Unicode and byte-strings but to keep all strings in Unicode and only perform the encode when actually needed.

So why does this behaviour matter? Well it particularly matters for framework authors formatting messages based on 'user' input. This is the case with unittest, which creates error messages when tests fail. The error messages internally in unittest are byte-strings and they are often mixed with user supplied messages using string formatting. We use old-style (% based) formatting, so if the user supplies byte-strings then the resulting messages will be byte-strings. If the user supplies Unicode strings then the resulting messages will be in Unicode. Because all the internal unittest messages are ascii only we can guarantee than an implicit decode to Unicode will succeed - so the user can choose the output type by varying the type of the messages they provide.

common ways to use doctest: To check that a module’s docstrings are up-to-date by verifying that all interactive examples still work as documented. To perform regression testing by verifying that interactive examples from a test file or a test object work as expected. To write tutorial documentation for a package, liberally illustrated with input-output examples. Depending on whether the examples or the expository text are emphasized, this has the flavor of “literate testing” or “executable documentation”.

Running the module as a script causes the examples in the docstrings to get executed and verified

The file content is treated as if it were a single giant docstring; the file doesn’t need to contain a Python program! For example, perhaps example.txt contains this

which is just ugly. .format doesn't have those issues. Also in the second example you gave, the .format example is much cleaner looking.

From PyQt4.6, PyQt has two APIs, API#1 (the original), and API#2 (new). API#2 is more Pythonic and eliminates QString and QVariant, and is a bit nicer to use. API#1 remains best for those using PyQt to prototype C++/Qt applications. API#1 is the default for PyQt4.x with Python 2.x, and for PyQt4.0-4.5 with Python 3.x. API#2 is the default for PyQt4.6+ with Python 3.x, and for PySide.

most of the changes affect uses of QDataStream, QSettings, and QTextStream, and of course any use of QString methods (since in API#2, QString is gone, so we use str).

To convert any particular example to PySide the steps are as follows: Replace python3 in the first line with python. Add the following statements before the first import: from __future__ import division from __future__ import print_function from future_builtins import * Replace PyQt4 with PySide throughout (e.g., in the imports) If using Python 2.6 replace {} in format strings with {0}, {1}, etc., as appropriate. Add [0] at the end of every QFileDialog.*() function call. (In PyQt these return a—possibly empty—filename; in PySide they return a filename–filter 2-tuple, but all the examples only need the filename.) Replace QT_VERSION_STR with qVersion(). Replace PYQT_VERSION_STR with PySide.__version__; you will also need to add import PySide in the imports after the future imports. Replace @pyqtSignature with @Slot. Replace def isAlive(qobj): ... with def isAlive(qobj): return True. (There is currently no PySide equivalent.) Replace chr with unichr.

Parameters are passed by value

some data types are mutable, but others aren't

If you pass a mutable object into a method, the method gets a reference to that same object and you can mutate it to your heart's delight, but if you rebind the reference in the method, the outer scope will know nothing about it, and after you're done, the outer reference will still point at the original object.