from io import BytesIO
import cairo
import IPython.display
svgio = BytesIO()
with cairo.SVGSurface(svgio, 200, 200) as surface:
# These lines are copied verbatim from the
# pycairo page: https://pycairo.readthedocs.io
context = cairo.Context(surface)
x, y, x1, y1 = 0.1, 0.5, 0.4, 0.9
x2, y2, x3, y3 = 0.6, 0.1, 0.9, 0.5
context.scale(200, 200)
context.set_line_width(0.04)
context.move_to(x, y)
context.curve_to(x1, y1, x2, y2, x3, y3)
context.stroke()
context.set_source_rgba(1, 0.2, 0.2, 0.6)
context.set_line_width(0.02)
context.move_to(x, y)
context.line_to(x1, y1)
context.move_to(x2, y2)
context.line_to(x3, y3)
context.stroke()
# end of pycairo copy
IPython.display.SVG(data=svgio.getvalue())
The old standard tool for line-counting is cloc. It has way too many options, many of which don’t work quite the way I would have expected, but it gets the job done, with some bash support. My resulting monster is below.
It over-counts JavaScript code because there are lots of places that JavaScript gets checked into git that isn’t code we wrote. I don’t know what to do about that. Oh well.
BTW, on the subject of line counting: once, helping someone with a program, I saw they were using semicolons to end their Python statements. I said they didn’t need them, and they replied, “Yes I do, because my manager’s line-counting software requires them.” !!!
Be careful out there...
#!/bin/bash
#
# Count lines of code in a tree of git repos.
# Needs cloc (https://github.com/AlDanial/cloc)
REPORTDIR=/tmp/cloc-reports
mkdir -p $REPORTDIR
rm -rf $REPORTDIR/*
cat <<EOF > $REPORTDIR/exclude-files.txt
package-lock.json
EOF
cat <<EOF > $REPORTDIR/more-langs.txt
reStructured Text
filter remove_matches xyzzy
extension rst
3rd_gen_scale 1.0
SVG Graphics
filter remove_html_comments
extension svg
3rd_gen_scale 1.0
EOF
find . -name .git -type d -prune | while read d; do
dd=$(dirname "$d")
if [[ $dd == ./src/third-party/* ]]; then
# Ignore repos in the "third-party" tree.
continue;
fi
echo "==== $dd =============================================="
cd $dd
git remote -v
REPORTHEAD=$REPORTDIR/${dd##*/}
cloc \
--report-file=$REPORTHEAD.txt \
--read-lang-def=$REPORTDIR/more-langs.txt \
--ignored=$REPORTHEAD.ignored \
--vcs=git \
--not-match-d='.*\.egg-info' \
--exclude-dir=node_modules,vendor,locale \
--exclude-ext=png,jpg,gif,ttf,eot,woff,mo,xcf \
--exclude-list-file=$REPORTDIR/exclude-files.txt \
.
cd -
done
cloc \
--sum-reports \
--read-lang-def=$REPORTDIR/more-langs.txt \
$REPORTDIR/*.txt
But the question stuck with me, and I eventually gave her these bits:
We’re constantly being exposed to other people’s public personas. They share their victories on Facebook. They do talks at conferences explaining their successes. They are loud and visible when they are feeling good.
But we know all about our own internal feelings, all the time, the good and the bad. It’s really easy to think that our world is full of bad feelings, and other people’s worlds are not. But that’s because we compare the full spectrum of our experience to the carefully curated presentation of others.
Don’t do that. Everyone has feelings of insecurity, and failures, and bad feelings. They just don’t show them to you. Don’t compare your insides to their outsides.
...and keep that separate from other people’s ideas that they will try to project onto you. Society has ideas about what people should do, or how they should behave. Your career, or your family, or your personal life: people will try to fit all of these things into some comfortable preconception. Don’t let them. You decide.
This sounds kind of business-y, but just means: tend your reputation well. Your actions have an effect on people. People will get to know you, and form opinions about you. It would be nice if they didn’t, but they do, so be aware of that process, and be mindful in your interactions. You will leave opinion-footprints everywhere you go. You want them to be good opinions. Decide what you want people to think of when they think of you, and aim for that.
OK, this was my original glib answer, but it’s true: if you have a way to save for retirement, especially if someone will match your money, do it. You may feel now like you can’t afford it, but that feeling won’t go away in the future. Start now.
This wasn’t my advice, but I liked it, on both a literal and metaphorical level.
Have a happy and mindful 2019!
]]>Python has a limit on how large its stack can grow, 1000 frames by default. If you recur more than that, a RecursionError will be raised. My recursive summing function seemed simple enough. Here are the relevant methods:
class Leaf:
def __init__(self):
self.val = 0 # will have a value.
def value(self):
return self.val
class Node:
def __init__(self):
self.children = [] # will have nodes added to it.
def value(self):
return sum(c.value() for c in self.children)
My code made a tree about 600 levels deep, meaning the recursive builder function had used 600 stack frames, and Python had no problem with that. Why would value() then overflow the stack?
The answer is that each call to value() uses two stack frames. The line that calls sum() is using a generator comprehension to iterate over the children. In Python 3, all comprehensions (and in Python 2 all except list comprehensions) are actually compiled as nested functions. Executing the generator comprehension calls that hidden nested function, using up an extra stack frame.
It’s roughly as if the code was like this:
def value(self):
def _comprehension():
for c in self.children:
yield c.value()
return sum(_comprehension())
Here we can see the two function calls that use the two frames: _comprehension() and then value().
Comprehensions do this so that the variables set in the comprehension don’t leak out into the surrounding code. It works great, but it costs us a stack frame per invocation.
That explains the difference between the builder and the summer: the summer is using two stack frames for each level of the tree. I’m glad I could fix this, but sad that the code is not as nice as using a comprehension:
class Node:
...
def value(self):
total = 0
for c in self.children:
total += c.value()
return total
Oh well.
Update: Jonathan Slenders suggested using a recursive generator to flatten the sequence of nodes, then summing the flat sequence:
class Leaf:
...
def values(self):
yield self.val
class Node:
...
def values(self):
for c in self.children:
yield from c.values()
def value(self):
return sum(self.values())
This is clever, and solves the problem. My real code had a mixture of two different nodes, one using sum() the other using max(), so it wouldn’t have worked for me. But it’s nice for when it does.
]]>If you haven’t seen Advent of Code, give it a look. A new puzzle each day in December until Christmas. This is the fourth year running, and you can go back and look at the past years (and days).
My presentation landing page has links to the slides and the code.
The presentation took a particular Advent of Code puzzle (December 14, 2016) and explained out a few different solutions, with a small detour into unit testing.
The code shows a few different ways to deal with the problem:
During the talk, an audience member suggested that itertools.tee could be useful, which I hadn’t considered. So I tried that out also, though it wasn’t as nice as I had hoped, and maybe is holding on to too much state.
Sorry I didn’t write out the text of the talk itself...
]]>I am in this situation. Reviewing those proposals is a pain, because there are large paragraphs of text, and spreadsheets are a terrible way to read them. I did the typical software engineer thing: I spent an hour writing a tool to make reading them easier.
The result is csv_review.py. It’s a terminal program that reads a CSV file (the exported proposals). It displays a row at a time on the screen, wrapping text as needed. It has commands for moving around the rows. It collects comments into a second CSV file. That’s it.
There are probably already better ways to do this. Everyone knows that to get answers from the internet, you don’t ask questions, instead you present wrong answers. More people will correct you than will help you. So this tool is my wrong answer to how to review CFP proposals. Correct me!
]]>The challenge with this release was something that started as a seemingly simple fix. Coverage.py tries to emulate how Python runs programs, including how the first element of sys.path is set. A few people run coverage with sys.path fully configured, and coverage’s setting of sys.path[0] was breaking their stuff.
The proposal was simple: delete the one line of code that set sys.path[0]. I tried that, and it seemed to work. Fixed!
Not so fast: the Windows builds failed. This started a multi-week adventure of debugging and refactoring. The Windows builds were failing not because of Windows itself, but because on Windows, I don’t use pytest-xdist, which parallelizes tests into worker processes. With xdist, the tests were all passing. Without xdist, a few sys.path-related tests were failing.
It turns out that xdist manipulates sys.path itself, which was masking the fact that I had removed an important step from coverage.py. First thing to do was to adjust my test code so that even with xdist, my tests didn’t get xdist’s path changes.
Then I had to re-think how to adjust sys.path. That required refactoring how I ran the user’s Python code, so that I could apply the path changes a little earlier than I used to. That made me look at how I was testing that layer of code with mocks, and I changed it from explicit dependency injection to implicit mock patching.
A few more little fixes were needed here and there along the way. All told, the “one line” fix ended up being 14 files changed, 587 insertions, 427 deletions.
]]>We had a test that was kind of like this:
def test_thing():
data = "I am the data"
self.assertNotEqual(
modify_another_way(change_the_thing(data)),
data
)
But someone refactored the test oh-so-slightly, like this:
def test_thing():
data = "I am the data"
modified = modify_another_way(change_the_thing(data)),
self.assertNotEqual(
modified,
data
)
Now the test isn’t testing what it should be testing, and will pass even if change_the_thing and modify_another_way both return their argument unchanged. (I’ll explain why below.)
Negative tests (asserting that two things are unequal) is really tricky, because there are infinite things unequal to your value. Your assertion could pass because you accidentally have a different one of those unequal values than you thought.
Better would be to know what unequal value you are producing, and test that you have produced that value, with an equality assertion. Then if something unexpectedly shifts out from under you, you will find out.
Why the test was broken: the refactorer left the trailing comma on the “modified =” line, so “modified” is a 1-element tuple. The comparison is now between a tuple and a string, which are always unequal, even if the first element of the tuple is the same as the string.
]]>I had some time today to dig into it, and now I understand better. The docs are misleading and/or incomplete. The module is not designed for maximum utility. Let me explain.
Here’s what the docs tell you: PYTHONWARNINGS (or the -W command-line option) is a comma-separated list of filters. Each filter is a 5-tuple of fields separated by colons. The third and fourth fields are of interest here, they are category and module.
Let’s start with module: it’s the module that caused the warning. The docs say it is a regular expression. This is false! Internally, this string is used as part of a regex match operation, but first it is escaped, so if you include an asterisk in your setting, you will be trying to match module names that have a literal asterisk in them, which is impossible.
OK, so the module string is a literal string, not a regex, but the escaped string is being used as part of re.match, so it should be possible to suppress warnings from an entire package (like backports.*) just by specifying “backports”, right? Nope! After being escaped, a $ is added to the end, so your literal string must be an exact match on the entire module name. Sigh.
Just to add to the confusion, the docs have long included this example, which isn’t even a sensible regex, never mind that regexes aren’t usable here:
error:::mymodule[.*] # Convert warnings to errors in "mymodule"
# and any subpackages of "mymodule"
These concerns about the regex behavior are the topic of bpo 34624, BTW.
On to category: this is actually the class of warning exception being used, so you can say (for example) DeprecationWarning here. In my case, I wanted to suppress the deprecation warnings that pytest raises. Pytest helpfully uses a base class, pytest.PytestDeprecationWarning, so I used that as the category. But this causes an error message at startup:
Invalid -W option ignored: invalid module name: ‘pytest’
Huh? pytest is an importable module! Nope: these category names are imported early in the startup sequence, before your real sys.path is built, so you cannot name third-party modules here...!
There are probably other things about warnings that confuse people. These are the ones I uncovered today after a long rage-fueled debugging session. An important developer skill is an irrational belief that things can be understood, and be made to make sense. Another is knowing when to give up and just accept the confusion. This morning I fully embraced the first.
In my case, I was trying to suppress warnings reported while running tests with pytest. Pytest has its own setting for warnings filters, and it uses its own copy of the warnings.py code for reading them, so that the regexes are not escaped! This is very useful, but could also add to the mystery, since the pytest docs don’t mention the difference.
And since pytest interprets its settings after sys.path has been configured, I can use third-party warning categories there. So this works perfectly:
[pytest]
filterwarnings =
ignore:::backports
ignore::pytest.PytestDeprecationWarning
It’s very satisfying to have some mysteries solved.
]]>To try it out:
[run]
dynamic_context = test_function
The database can be accessed in any SQLite-compatible way you like. Note that the schema is not (yet) part of the public API. That is, it may not be guaranteed to stay the same. This is one of the things yet to be decided. For now though, the database has these tables:
It’s not the most convenient, but the information is all there. If you used branch coverage, then the important data is in the “arc” table, and “line” is empty. If you didn’t use branch coverage, then “line” has data and “arc” is empty. For example, using the sqlite3 command-line tool, here’s a query to see which tests ran a particular line:
sqlite> select
...> distinct context.context from arc, file, context
...> where arc.file_id = file.id
...> and arc.context_id = context.id
...> and file.path like '%/xmlreport.py'
...> and arc.tono = 122;
context
------------------------------------------------------------
XmlPackageStructureTest.test_package_names
OmitIncludeTestsMixin.test_omit
OmitIncludeTestsMixin.test_include
OmitIncludeTestsMixin.test_omit_2
XmlReportTest.test_filename_format_showing_everything
XmlReportTest.test_no_source
OmitIncludeTestsMixin.test_include_as_string
OmitIncludeTestsMixin.test_omit_and_include
XmlReportTest.test_empty_file_is_100_not_0
OmitIncludeTestsMixin.test_omit_as_string
XmlReportTest.test_nonascii_directory
OmitIncludeTestsMixin.test_nothing_specified
XmlReportTest.test_curdir_source
XmlReportTest.test_deep_source
XmlPackageStructureTest.test_package_depth
XmlPackageStructureTest.test_source_prefix
XmlGoldTest.test_a_xml_2
XmlGoldTest.test_a_xml_1
XmlReportTest.test_filename_format_including_module
XmlReportTest.test_reporting_on_nothing
XmlReportTest.test_filename_format_including_filename
ReportingReturnValueTest.test_xml
OmitIncludeTestsMixin.test_include_2
BTW, there are also “static contexts” if you are interested in keeping coverage data from different test runs separate: see Measurement Contexts in the docs for details.
Some things to note and think about:
Please try this out, and let me know how it goes. Thanks.
]]>