Archive for March, 2012

More on PEP8

Well I certainly got some robust comments on my previous PEP8 post. A few people chimed on my side, so to speak. Someone else found it “discouraging” when faced with “non-compliant code”. But it was Luke who obviously felt most strongly about the matter, and it’s his points that I’m really addressing here.

First of all, it seems that you’ve got me coming and going: on the one hand, I’m unreasonable to expect people to adopt my project’s style when contributing to it; but on the other I’m unreasonable if I expect to program the same way in every environment. Let me say again what I said in the previous post: if I contribute to, say, core Python, then I *do* expect to have to change my style to match the project guidelines. Likewise, if I contribute to Pyro — a fairly well-known Python project — then I use camelCase method names, because that’s what its maintainer uses. I don’t find that so very difficult and I doubt it anyone else does either. (Of course my “anyone else does” here is as anecdotal as the generalisations in Luke’s comments and can be treated the same way).

Luke’s basic point seems to be that all Python code *should* look the same, regardless of any other consideration, and that to do otherwise is not to be a team player, to indicate that you don’t care, and to leave open the suspicion that your code is of as poor quality as… well, your PEP8-ness. And I find that position far beyond what I consider reasonable. If that leaves me turning people away at the door then please write and tell me. Perhaps I’m being a single-minded curmudgeon on this issue, but I am honestly bemused at the idea that *all* Python code should follow what is, basically, one person’s preferences.

In short, I would be genuinely interested to hear from other people if they think that publishing Python code which follows a consistent style but which is not PEP8-compliant is that much of an issue. For them, for would-be contributors, or for the image of Python.

PEP8? Or not?

From time to time someone comments on some code example I’ve produced (or, indeed, one of my published modules) and makes the point that the code is not PEP8-compliant. The most common complaints are that I use spaces before function-call brackets — spam (”foo”) rather than spam(”foo”) — and that I use 2-space indents rather than 4.

Since I’ve written pretty much the same answer whenever this has been raised, I thought I might as well write it here and then point people towards it.

PEP 8 is the Python project’s code style guideline. I quote from the opening paragraph: “This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.”. It is not a guideline for every piece of Python code ever written by anyone. On the odd occasion that I contribute code to the Python core I naturally ensure that my code complies with PEPs 7 & 8 for C & Python code respectively.

I’ve been using the format described above for well over 25 years of coding on different platforms & languages. Along with other aspects, it constitutes my personal “house style”. If anyone wished to contribute to any of my projects I would ask them to follow the same guidelines (or at least, not to complain when I reformatted their code to match my own).

FWIW I find the spam(”foo”) style cramped; no doubt some people find my spam (”foo”) style too loose. So be it. I’m genuinely astonished when people advocate 8-space indents (and I’d be a bit startled by 1-space indents). I find 4 spaces push the relevant code too far away too easily so I use 2 spaces. Barring manifest absurdities, such things are largely subjective.

So now you know: if you see code examples of mine, or are perusing my source code, be prepared for (gasp) non-PEP8 compliance!

winshell 0.6.1

In a fit of energy over the weekend, I added some basic Recycle Bin functionality to the winshell module. (And thanks to Steve Reiss for the suggestion and for ideas about convenience functions). As of version 0.6.1 you can now:

  • Iterate over items in the recycle bin
  • Determine what versions of a file there are in the recycle bin
  • Undelete the latest or a specific version of a file
  • Empty all recycle bins

You could already delete to the Recycle Bin (via delete_file). Now you can undelete as well!

winshell 0.5.4

Ahem. I promise I did test it, but then testing on developers’ machines is notoriously untrustworthy. In short, I failed to include the versioning module in the winshell sdist. Several fumbled attempts and struggles with PyPI later, I bring you: winshell 0.5.4 whose sole purpose is to fix this problem.

Many thanks to Steve Reiss who took the trouble to let me know it was failing to install

winshell 0.5.1

Just a quickie to say that I’ve had a small flurry of work on my tiny winshell module. A combination of doc updates, cookbook examples, and some more general-purpose shortcut handling. It’s up to v0.5.1 on PyPI, github, and readthedocs.