lp:~aaron-whitehouse/duplicity/08-unadorned-strings
As set out in the Python 3 blueprint: https:/
one of the most time consuming, and least easy to automate, parts of supporting both Python 2 and 3 is string literals. This is because simple strings (e.g. a = "Hello") will be treated as bytes (e.g. encoded ASCII) in Python 2 and Unicode in Python 3. As we are trying to support both Python 2 and Python 3 for at least a transition period, we may end up with odd behaviour wherever we have an unadorned string.
The versions of Python 2 and 3 we are targeting means that we can "adorn" strings with letters to indicate what type of string (u for Unicode, b for Bytes and r for Raw/regexes).
An important preliminary step to Python 2/3 support is therefore for us to add these adornments to each and every string literal in the code base.
To ensure that we can find these and do not accidentally introduce more unadorned strings, this merge request adds a function to our test_code that automatically checks all .py files for unadorned strings and gives an error if any are found.
The actual work to adorn all of these strings will be substantial, so that is not all done in this merge request. Instead, this takes the approach we have for many of our other code style checks, where it currently contains a very long list of excluded files (which are not checked) and we can remove these exceptions as we adorn the strings in each file.
To assist people in finding and correcting all of the unadorned strings in a particular file, the new file testing/
./find_
and it will return a nicely-formatted list of all unadorned strings in the file that need to be corrected.
As the codebase is currently Python 2 only, marking strings as Bytes (b" ") essentially preserves current behaviour, but it is highly desirable to convert as many of these as possible to Unicode strings (u" "), as these will be much easier to work with as we transition to Python 3 and it will improve non-ASCII support. This will likely require changes to other parts of the code that interact with the string. The broad recommended approach for text is to decode at the boundaries (e.g. when reading from or writing to files) and use Unicode throughout internally. Many built-ins and libraries natively support Unicode, so in many cases very little needs to change to the code.
Many helper variables/functions have already been created in duplicity so that you can use Unicode wherever possible. For paths, for example, you can use Path.uname instead of Path.name.
- Get this branch:
- bzr branch lp:~aaron-whitehouse/duplicity/08-unadorned-strings
Branch merges
- duplicity-team: Pending requested
-
Diff: 340 lines (+253/-39)2 files modifiedtesting/find_unadorned_strings.py (+73/-0)
testing/test_code.py (+180/-39)
Related source package recipes
Related bugs
Related blueprints
Branch information
Recent revisions
- 1307. By Aaron Whitehouse
-
* Added new script to find unadorned strings (testing/
find_unadorned_ strings. py python_file) which prints all unadorned strings in a .py file.
* Added a new test to test_code.py that checks across all files for unadorned strings and gives an error if any are found (most files are in an ignore list at this stage, but this will allow us to incrementally remove the exceptions as we adorn the strings in each file). - 1306. By Aaron Whitehouse
-
* Adorn string literals in test_code.py with u/b
* Add test for unadorned string literals (currently only single file) - 1305. By Aaron Whitehouse
-
* Tox changes to accommodate new pycodestyle version warnings. Ignored W504 for now and marked as a TODO. Marked W503 as a permanent ignore, as it is prefered to the (mutually exclusive) W504 under PEP8.
* Marked various regex strings as raw strings to avoid the new W605 "invalid escape sequence". - 1304. By Kenneth Loafman
-
* Fixed bug #x1717935 with suggestion from strainu
- Use urllib.quote_plus() to properly quote pathnames passed via URL - 1303. By Kenneth Loafman
-
* Fixed bug #1768954 with patch from Max Hallden
- Add AZURE_ENDPOINT_SUFFIX environ variable to allow setting to non-U.S. servers - 1302. By Kenneth Loafman
-
* Merged in lp:~dawgfoto/duplicity/fixup1252
* only check decryptable remote manifests
- fixup of revision 1252 which introduces a non-fatal error message (see #1729796)
- for backups the GPG private key and/or it's password are typically not available
- also avoid interactive password queries through e.g. gpg agent - 1301. By Launchpad Translations on behalf of duplicity-team
-
Launchpad automatic translations update.
- 1300. By Launchpad Translations on behalf of duplicity-team
-
Launchpad automatic translations update.
- 1298. By Kenneth Loafman
-
* Merged in lp:~dawgfoto/duplicity/fixup1251
- Avoid redundant replication of already present backup sets.
- Fixed by adding back BackupSet.__eq__ which was accidentally(?) removed in 1251.
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp:~duplicity-team/duplicity/0.8-series
