How to contribute
Submitting changes
Due to confidentiality issues, we are not able for now to publish any source- controlled repository (even if we do have a Mercurial repository for the project). However, this does not prevent motivated users from contributing to the project by sending patches applied to the last published version of the library. To compensate the absence of source repository, we try to update the library as often as we can in order to keep the public source archive version as close as possible to the internal development version.
Coding guidelines
In general, we try to follow the standard Python coding guidelines, which cover all the important coding aspects (docstrings, comments, naming conventions, import statements, ...) as described here:
The easiest way to check that your code is following those guidelines is to run pylint (a note greater than 8/10 seems to be a reasonnable goal).
PyQt v4.4 compatibility issues
The project has to be compatible with PyQt >= v4.4 which means that the following recommendations should be followed:
- avoid using super: when writing classes deriving from a QObject child class (i.e. almost any single class imported from QtGui or QtCore), the super builtin-function should not be used outside the constructor method (call the parent class method directly instead)
- before using any function or method from PyQt4, please check that the feature you are about to use was already implemented in PyQt4 v4.4 (more precisely in the Qt version used in PyQt4 v4.4) – if not, a workaround should be implemented to avoid breaking compatibility
- do not use the PyQt-specific QFileDialog static methods (not present in Qt) which were introduced in PyQt v4.6: getOpenFileNameAndFilter, getOpenFileNamesAndFilter and getSaveFileNameAndFilter (guidata provides wrappers around QFileDialog static methods handling the selected filter which were taken from the spyderlib library (from module spyderlib.qt.compat): they are available in guidata.qt.compat)
PyQt / PySide compatibility
In the near future, the project will be officially compatible with both PyQt and PySide.
In its current implementation, it has to be compatible with PyQt API #1 (old PyQt versions) and API #2 (PySide-compatible API, PyQt >= v4.6), which means that the following recommendations should be followed:
- QVariant objects must not be used (API #2 compatibility)
- QString and QStringList objects must not be used (API #2 compatibility)
- When connecting built-in C++ signals which were originally made to pass strings (or string lists), the arguments should always be assumed to be QString (or QStringList) objects (API #1 compatibility) and so be converted systematically to the Python equivalent object, i.e. unicode (or list).
Python 3 compatibility
Regarding Python 3 compatibility, we chose to handle it by maintaining a single source branch being compatible with both Python 2.6-2.7 and Python 3.
Here is what we have done.
Fixing trivial things with 2to3
The first step is to run the 2to3 script (see Python documentation) to convert print statements to print function calls – note that your source directory (named directory_name) has to be version controlled (no backup is done thanks to the -n option flag). python 2to3.py -w -n -f print directory_name
Open each modified source file and add the following line at the beginning: from __future__ import print_function
Then run again 2to3 with all other Python 2/3 compatible fixers: python 2to3.py -w -n -f apply -f dict -f except -f exitfunc -f filter -f has_key -f map -f ne -f raise -f ws_comma -f xrange -f xreadlines -f zip directory_name
After these two steps, your code should be compatible with Python 2.6, 2.7 and 3.x, but only with respect to the simplest changes that occured between Python 2 and Python 3. However, this a step forward to Python 3 compatibility without breaking Python 2.6+ compatibility.
Fixing unicode issues
In Python 3, unicode and str strings have been replaced by str and bytes strings:
- str is the text string type, supporting unicode characters natively
- bytes is the binary string type.
As a consequence, Python 2 code involving strings may cause compatibility issues with Python 3. For example:
- file I/O may return bytes instead of str in Python 3 (depending on the open mode): this can be solved by calling the decode method on the bytes object (this will work on both Python 2 str and Python 3 `bytes objects)
- in Python 3.0-3.2, the u’unicode text’ or u”unicode text” syntax is not allowed and will raise a SyntaxError: this can be solved by inserting the from __future__ import unicode_literals at the beginning of the script and by removing all the u string prefixes
- in Python 3 isinstance(text, basestring) can be replaced by is_text_string(text) (function of the guidata.py3compat module)
- in Python 3 isinstance(text, unicode) can be replaced by is_unicode(text) (function of the guidata.py3compat module)
- in Python 3 unicode(text) can be replaced by to_text_string(text) (function of the guidata.py3compat module)