To signal the file encoding to Emacs, one can add a line with
-*- coding: your-favority-encoding -*-
Python also understands such a line, infact it also understands the
line if it says "encoding" instead of "coding".
However, it is only "coding" that has an effect in Emacs. Furthermore,
since "encoding" is not recognized, Emacs will prompt the user with a
scary looking message when the file is opened:
The local variable list in __init__.py contains values that may not
be safe.
Using the correct variable name fixes this.
(The file contain only ASCII characters at the moment, so the line
could alternatively be removed completely.)
Change-Id: Ie6b4f41043bf97bb59e3de403e4794c302d81783
A couple of assertTrue in the test_swiftclient.py
unit tests should be assertEqual. Also, the expected
values now need to be bytes literals.
Change-Id: I7cc1bd60d9ba82d1a28fbae2e1243d3c799451bd
* E111 indentation is not a multiple of four
* E128 continuation line under-indented for visual indent
* E265 block comment should start with '# '
* E713 test for membership should be 'not in'
Tested with pep8 version 1.5.6 (2014-04-14).
Change-Id: I7f85c143d463c501a0df20724362ad5c0f2d4dde
This patch fixes three issues that were found running
functional tests with Python 3:
1. python-requests sets 'application/x-www-form-urlencoded' as
content-type if the input is not a string object and no
content-type is given.
2. Encoding of the headers is now only done if required. This
prevents comparisons between unencoded headers and encoded
prefixes and avoids unnecessary forloop-iterations.
One unittest was extended to ensure it works for unencoded
and encoded headers with or without the prefix.
3. Functional tests recently switched to using byte data for
testing, thus the comparison needs to be a byte object as well.
Change-Id: I035f8b4b9c9ccdc79820b907770a48f86d0343b4
There is no testtools.main() at all (this was a
unittest.main() before). Let's remove this unused
and non-working code.
The following code can be used if someone needs
to start tests manually:
python -m unittest <test_file.py>
Change-Id: Id5162ac73825584df6c23dbe68786ff3355fc6ae
Looks like test_shell.py got left behind when
the unit tests were relocated under tests/unit.
As a consequence they weren't included in tox
runs.
Change-Id: I93435e6141c5e3ad4a9403626f226d7c760cbd7c
Since we added the tests.functional the py3 tests wasn't running
properly fixing it with some voodoo testr magic.
Change-Id: Id301adb32ba739f05591c4c352e0cf7d87576755
The command descriptions did not include a "." at the end but the
argument description does. Add "." everywhere.
Also capitalize and add "." for parameter of capabilities.
Change-Id: I2355e0d0c38170d669c8e568361faf4b68203d16
Note that this should not land until we figure out why `tox -e py33` doesn't
actually run any tests.
Change-Id: Id4e080cfbfca45b3bf7ed81b03a31414495a1348
Don't encode standard headers keys but just the x-*-meta- ones. That
fixes py3 to not have them casted as bytes and not properly passed to
the requests kwargs.
Other trivial py3 fixes along the way.
Change-Id: I91b95f32fb2aec9b20892a5bb95fd1bc65d002f3
Coverage for swiftclient.client is 71% with these tests.
Unit tests have been moved into another subdirectory
to separate them from functional tests.
Change-Id: Ib8c4d78f7169cee893f82906f6388a5b06c45602
If we don't we are getting an error like this under py3:
TypeError: unsupported operand type(s) for /: 'float' and 'MagicMock'
Change-Id: If5a6947757297354e6b81fc45f011cc2921d609f
They currently fail because on Python3 arbitrary objects cannot be compared, in
this case, MagicMock and int. In Python2 these comparisons silently pass.
Change-Id: I468c2137702a454365886099e827d329cb1d7209
Some spots in this file were already referencing six.StringIO, but
some were still using StringIO.StringIO, which does not work on
py3. This patch just makes them all use six.StringIO and removes the
now-unused (and wrong, on py3) import.
Change-Id: I3c7311c3983f4eb409eedb6f85ede6ffe4059e63
We were testing the test but we were not testing that we have actually
properly uploaded the object with the right content-len
(and it was broken under py3)
Change-Id: Ifa91c30532090cac9f8e18ff18eaf5e6c98737d1
* On Python 3, the printer doesn't encode Unicode to utf8 anymore, since
print() expects a Unicode string.
* Update unit tests for Python 3 since repr() doesn't escape non-ASCII
characters in Unicode strings anymore:
http://legacy.python.org/dev/peps/pep-3138/
Change-Id: I89471019d691a46651312d6a49964b719192148a