In a recent post Amit talked about temporary files and gave a number of scenarios where they can be quite handy. In testing, I occasionally need temporary files and prefer to use mkstemp however, the clean up of the file was bothersome and I found that I often needed to write something into the files before the test.

from dhp.test import tempfile_containing

contents = 'I will not buy this record, it is scratched.'
with tempfile_containing(contents) as fname:
do_something(fname)


Thus tempfile_containing was my solution. It uses mkstemp, writes contents to the file and is implemented as a context manager so it returns a path and file name that is cleaned up when it goes out of scope. (Note: NamedTemporary and others, return a file-like object tempfile_containing returns a path/filename of an existing file) After the file is written to it is closed so no inadvertent lock contentions occur on some OSs. If it sounds like something that would make writing tests faster for you, check it out at:

* documentation
* Source
* pip install dhp

Comments as defined by Python in 2.7.x and 3.4.x

A comment starts with a hash character (#) that is not part of a string literal, and ends at the end of the physical line. A comment signifies the end of the logical line unless the implicit line joining rules are invoked. Comments are ignored by the syntax; they are not tokens.

Seems pretty straight forward to me. Parser finds a comment token, and ignores everything to the new-line token. (Except for when implicit line joining rules are invoked.) So why was I struck with a hmmm, when I opened up a Python Console and entered a comment then pressed Enter?

>>> # this is a comment, guess what happens next?
...


If you look closely, the next line is prefixed with an ellipsis (…) and not a new prompt (>>>). Well there must be a reason, but this feels “unexpected.” So I pull up a 2.7 console and try it again.

>>> # this is a comment, guess what happens next?
...


So it looks to be intentional, although it doesn’t seem to feel correct. Ok, let’s give pypy a try and see what happens there.

>>>> # this is a comment, guess what happens next?
>>>>


Ok, now I am confused. CPython treats it as an unclosed statement of some kind, although you would think it would be closed because a new-line token should have been encountered thus closing off the comment. However, when pypy gave a different and less surprising result, I put a hand to my chin and said, “Hmmm.”

Ok interweb – does anyone know what is going one here?

1) Why the unexpected ellipsis in CPython ?
2) Why does pypy not return an ellipsis ?
3) Are they both correct and are just slightly different implementations of the same reference? Or is one more correct than the other?

While I’m scratching my head, you can ponder this:

>>> # comment
... 2 + 2
4
>>>


A search for information on string interpolation in Python will inevitably lead you to comments and links to old documentation that the string modulo operator is going to be deprecated and removed. However, that is just outright FUD. I need not make a case for the modulo operator, I’ll just let the code do the talking.

from timeit import timeit

def test_modulo():
'Don\'t %s, I\'m the %s.' % ('worry', 'Doctor')

def test_format_explicit():
'Don\'t {0}, I\'m the {1}.'.format('worry', 'Doctor')

def test_format_implicit():
'Don\'t {}, I\'m the {}.'.format('worry', 'Doctor')

timeit(stmt=test_modulo, number=1000000)
timeit(stmt=test_format_explicit, number=1000000)
timeit(stmt=test_format_implicit, number=1000000)


Running the code on python 3.4.3 I get the following results:

>>> timeit(stmt=test_modulo, number=1000000)
0.668234416982159
>>> timeit(stmt=test_format_explicit, number=1000000)
0.9450872899033129
>>> timeit(stmt=test_format_implicit, number=1000000)
0.8761067320592701


Note that test_format_explicit is the form most commonly found on the web. However, the implicit version is a much closer equivalent to test_modulo. In this case, there is an apparent price for being explicit.

Until .format is on par, speed-wise, with % there is no chance of it being deprecated. I support .format‘s existance, in some battle grounds it is superior. You shouldn’t bring regex‘s to the fight when .starstwith, .find, .endswith or in can handle the challenge cleanly. The same is True for .format and %.

An as PEP 461 demonstrates, the string modulo operator is not going quietly into the night.

This post was inspired by curiosity after reading this 2013 article.

I personally don’t like Python’s type annotations, the completely mask out what was a human friendly function signature. For something that was being proposed and skunk-worked in to stub files, according to Guido’s keynote at PyCon, it is spreading inside of source files, at an alarming rate, through out Python’s upper echelon.

Just this weekend Type Annotations infested a blog post on Why print is now a function in Python 3. Luckily Brett, took out the hedge trimmers and cleared away the mess. It is a interesting blog post now that you can see what he is talking about. Now I see that they’ve spread to PEP8.

The usefulness of Static Type Checking against Dynamic code is questionable at best. The damage that can and may be done to readable function signatures is frightening on scale similar to the Kudzu infestation and decimation of indigenous plants in the US. I encourage you to help fight this invasive and damaging trend by keeping your Type Annotations where they belong, in stub files.

Why doesn’t PEP8 encourage the use of stub files over obfuscating your code? A considerable number of people don’t like lint droppings ( # pylint:disable=… ) in their code and it goes in a comment, this trash is being put right in the function’s signature.

What is the practical upside to Static Type Checking? Guido talked about it in big terms and hand waving, in his keynote and people use glowing buzz words, but, seriously with examples, what can it actually do that writing testable code and tests can’t? The upside is as hard to see as a type annotated signature.