./utils/cmpcodesize/cmpcodesize/main.py:20:71: E231 missing whitespace after ','
./utils/round-trip-syntax-test:20:20: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
./utils/round-trip-syntax-test:21:16: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
I can't find any uses of round-trip-syntax-test, so I don't know if
this fix is correct.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Previously, to specify the directories containing objects whose sizes
should be compared, environment variables had to be used. With this
change, arguments (-o/--old-build-dir, -n/--new-build-dir) can be passed
to the cmpcodesize script directly. If those arguments aren't
specified, the environment variables are sued as before.
The formula for percentage change in _any_ metric, without exception, is:
(new_value - old_value) / old_value
Some people flip the sign of their result, presumably because they
associate "positive" with "good" or want to render a graph where
"upward" bars are "good". Making this mistake consistently leads to
tremendous confusion.
This is particularly horrible when people confuse time and speed,
which are inverse metrics. Flipping the sign in order to present the
inverse metric is commonly done, but is mathematically incorrect and
is often extremely misleading. That's why it's so important to use a
standard (mathematically correct) convention for reporting a change in
percentage of any metric.
So, if I triple the size of the code, I'll now see +200%, not -200% which is
mathematically impossible and shear nonsense.
Added title column.
Make short parameter consistent.
Made output option -c work.
Fixed csv output for -l flag.
Shortened too long lines.
Fix linting errors.
Remove comment.
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
The repo contains roughly 80 Python scripts. "snake_case" naming is used for
local variables in all those scripts. This is the form recommended by the PEP 8
naming recommendations (Python Software Foundation) and typically associated
with idiomatic Python code.
However, in nine of the 80 scripts there were at least one instance of
"camelCase" naming prior to this commit.
This commit improves consistency in the Python code base by making sure that
these nine remaining files follow the variable naming convention used for
Python code in the project.
References:
* PEP 8: https://www.python.org/dev/peps/pep-0008/
* pep8-naming: https://pypi.python.org/pypi/pep8-naming
Fixes:
* multiple statements on one line (colon) (E701)
* missing whitespace around arithmetic operator (E226)
* missing whitespace around operator (E225)
* closing bracket does not match visual indentation (E124)
* blank line contains whitespace (W293)
* continuation line missing indentation or outdented (E122)
* continuation line over-indented for hanging indent (E126)
* missing expected blank line (E301)
* trailing whitespace (W291)
* unexpected spaces around keyword / parameter equals (E251)
* whitespace after '(', '[' or '{' (E201)
* whitespace before ')', ']' or '}' (E202)
* whitespace before ',' or ':' (E203)
Fixes:
* Unused import
* Redundant backslash
* Use of discouraged if not x in y
* Use of deprecated form of raising exceptions
Follow-up to PR #655 as requested by @gribozavr
In Python 3, 'print' was changed from a statement to a function. Using
the __future__ module allows scripts to use print function whether
running with Python 2.6+ or Python 3.x. This commit changes as many
instances of print as I could find to use the print function and the
__future__ module.
Add unit tests to cmpcodesize. As a basic starting point for unit
tests, add some tests for edge cases in listFunctionSizes.
Users may now run the unit tests for cmpcodesize by running
`python utils/cmpcodesize/setup.py test`.
By adding a setup.py file, users may install cmpcodesize to their PATH,
by running `python utils/cmpcodesize/setup.py install`.
Should the Swift project choose to do so, this package may also be uploaded
to the Python Package Index (https://pypi.python.org/pypi). Doing so would
allow anyone with an Internet connection to install cmpcodesize by
running `pip install cmpcodesize`.
Setuptools also provides a convenient way to run unit tests (yet to be
added as of this commit).
Split up cmpcodesize script into a package, with a main.py file that
acts as an entry point to the program. The functions that use otool to
actually determine binary size have been moved into compare.py.
Note that to execute cmpcodesize, you may now run either:
1. `utils/cmpcodesize/cmpcodesize.py`
2. `python utils/cmpcodesize/cmpcodesize/main.py`
