Python style guidelines

[beliavsky]

Is there a more recent set of Python style guidelines than PEP 8,
"Style Guide for Python Code", by van Rossum and Warsaw, at
http://www.python.org/peps/pep-0008.html , which is dated July 5,
2001?

[Skip Montanaro]

beliavsky> Is there a more recent set of Python style guidelines than
beliavsky> PEP 8, "Style Guide for Python Code", by van Rossum and
beliavsky> Warsaw, at http://www.python.org/peps/pep-0008.html , which
beliavsky> is dated July 5, 2001?

Is there something missing you think should be there? There's no particular
reason a PEP needs to be continually updated. In particular, notions of
good Python style haven't changed a lot over the past ten years.

Skip

[Josef Meile]

> Is there something missing you think should be there? There's no particular

reason a PEP needs to be continually updated. In particular, notions of
good Python style haven't changed a lot over the past ten years.

Skip

I agree, those are good guidelines, but I don't agree with:

- Don't compare boolean values to True or False using == (bool
types are new in Python 2.3):

No: if greeting == True:
Yes: if greeting:

What would happened if you do:

a='test'
if a.find('foo'): .... print "foo was found"
....
foo was found

I think you should never do a direct boolean comparison. Instead
one should use a more elaborate boolean expresion like:
a='test'
if a.find('foo') >= 0:

.... print "foo was found"
....
You will have problems specially if you come from languages where
values minor than zero are considered to be false. I think the
previous sintax is ambiguous.

Regards,
Josef

[Peter Otten]

Josef Meile wrote:

Is there something missing you think should be there? There's no
particular
reason a PEP needs to be continually updated. In particular, notions of
good Python style haven't changed a lot over the past ten years.

Skip

I agree, those are good guidelines, but I don't agree with:

- Don't compare boolean values to True or False using == (bool
types are new in Python 2.3):

No: if greeting == True:
Yes: if greeting:

What would happened if you do:

>>> a='test'
>>> if a.find('foo'): ... print "foo was found"
...
foo was found

I think you should never do a direct boolean comparison. Instead
one should use a more elaborate boolean expresion like:
>>> a='test'
>>> if a.find('foo') >= 0:

... print "foo was found"
...
You will have problems specially if you come from languages where
values minor than zero are considered to be false. I think the
previous sintax is ambiguous.

I think your find() example has nothing to do with

if boolVal == True:

versus

if boolVal:

though it might be a pitfall for people coming from languages with 1-based
indices. If you discard the index it returns anyway, you could use the
clearer

if "foo" in a:

instead.

As to the original issue, I disagree with you and prefer the recommended
style. I find it natural even for non-booleans:

greeting = "Hi"
if greeting:
print greeting

If you expect a boolean value and fear that you may erroneously encounter
something else, the value == True test will not be sufficient anyway,
because treating, say, "Hi" as False may be an error, too. It's

if greeting == True:
...
elif greeting == False:
pass
else:
raise AssertionError, "greeting must be True or False"

versus

assert greeting in (True, False), "greeting must be True or False"
if greeting:
...

then, and again the last wins at in my eyes.

Peter

[Heather Coppersmith]

On Thu, 11 Mar 2004 10:48:35 +0100,
Josef Meile <jm****@hotmail.com> wrote:

Is there something missing you think should be there? There's no particular
reason a PEP needs to be continually updated. In particular, notions of
good Python style haven't changed a lot over the past ten years.
Skip I agree, those are good guidelines, but I don't agree with:

- Don't compare boolean values to True or False using == (bool
types are new in Python 2.3): No: if greeting == True:
Yes: if greeting: What would happened if you do:

a='test'
if a.find('foo'): ... print "foo was found"
...
foo was found

a.find does not return a boolean, so that particular style guideline
does not apply.

if a.find( 'foo' ) == True:

.... print 'foo was found'

probably isn't what you want either. ;-)

Regards,
Heather

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

[beliavsky]

Skip Montanaro <sk**@pobox.com> wrote in message news:<ma**************************************@pyt hon.org>...

beliavsky> Is there a more recent set of Python style guidelines than
beliavsky> PEP 8, "Style Guide for Python Code", by van Rossum and
beliavsky> Warsaw, at http://www.python.org/peps/pep-0008.html , which
beliavsky> is dated July 5, 2001?

Is there something missing you think should be there? There's no particular
reason a PEP needs to be continually updated. In particular, notions of
good Python style haven't changed a lot over the past ten years.

Skip

I am not qualified to say what should be in Python style guidelines. I
have now read the PEP 8 style guidelines and see that Python versions
up to 2.3 are covered. I think the Post-History date of July 5, 2001
is incorrect and should be updated.

[Michael Hudson]

be*******@aol.com writes:

Skip Montanaro <sk**@pobox.com> wrote in message news:<ma**************************************@pyt hon.org>...

beliavsky> Is there a more recent set of Python style guidelines than
beliavsky> PEP 8, "Style Guide for Python Code", by van Rossum and
beliavsky> Warsaw, at http://www.python.org/peps/pep-0008.html , which
beliavsky> is dated July 5, 2001?

Is there something missing you think should be there? There's no particular
reason a PEP needs to be continually updated. In particular, notions of
good Python style haven't changed a lot over the past ten years.

Skip

I am not qualified to say what should be in Python style guidelines. I
have now read the PEP 8 style guidelines and see that Python versions
up to 2.3 are covered. I think the Post-History date of July 5, 2001
is incorrect and should be updated.

How so? It hasn't been posted to comp.lang.python since then, and
that's what the Post-History: records.

Cheers,
mwh

--
If I had wanted your website to make noise I would have licked
my finger and rubbed it across the monitor.
-- signature of "istartedi" on slashdot.org

[Josef Meile]

>>>>>a='test'

>if a.find('foo'):

... print "foo was found"
...
foo was found

a.find does not return a boolean, so that particular style guideline
does not apply.

I know, but I found this on the Zope source, which
means that there is people thinking that the False
on python includes negative values.

[Peter Hansen]

Josef Meile wrote:

>> a='test'
>> if a.find('foo'):
... print "foo was found"
...
foo was found

a.find does not return a boolean, so that particular style guideline
does not apply.

I know, but I found this on the Zope source, which
means that there is people thinking that the False
on python includes negative values.

I believe it's more likely they just forgot what find() did return, as
they were writing the code. I've done the same, thinking it was a
boolean, not thinking that it returned a negative but that negatives
were considered false.

-Peter

[Aahz]

In article <40********@pfaff2.ethz.ch>,
Josef Meile <jm****@hotmail.com> wrote:

I agree, those are good guidelines, but I don't agree with:

- Don't compare boolean values to True or False using == (bool
types are new in Python 2.3):

No: if greeting == True:
Yes: if greeting:

What would happened if you do:

a='test'
if a.find('foo'):... print "foo was found"
...
foo was found

'foo' in 'test'

False
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich, comp.lang.python

[Donn Cave]

In article <EO%3c.2675$G3.20988@localhost>,
Peter Hansen <pe***@engcorp.com> wrote:

[... re "if a.find(v):"]

I believe it's more likely they just forgot what find() did return, as
they were writing the code. I've done the same, thinking it was a
boolean, not thinking that it returned a negative but that negatives
were considered false.

I'm sure that's common. In principle, seems to me that in
many if not most cases the "index" function expresses the
result better - for example,

try:
t = a.index(e)
except ValueError:
return a
else:
return a[:t]

But for some reason, the average programmer seems to greatly
prefer non-valid error returns over exceptions, even though
they're naturally idiosyncratic and prone to this kind of
error. I sure don't recall seeing "index" very often, anyway.

Donn Cave, do**@u.washington.edu

[John Roth]

"Peter Hansen" <pe***@engcorp.com> wrote in message
news:EO%3c.2675$G3.20988@localhost...

Josef Meile wrote:

>>> a='test'
>>> if a.find('foo'):
... print "foo was found"
...
foo was found

a.find does not return a boolean, so that particular style guideline
does not apply.
I know, but I found this on the Zope source, which
means that there is people thinking that the False
on python includes negative values.

I believe it's more likely they just forgot what find() did return, as
they were writing the code. I've done the same, thinking it was a
boolean, not thinking that it returned a negative but that negatives
were considered false.

I suspect that's a rather common error. I'd much prefer
that both find and index return an object that acted like
a number but returned the logically correct response when
queried as a boolean: true for zero and false for -1. Also,
the "not found" object should throw an exception if it's
used as an index or slice.

John Roth
-Peter

[Will Berry]

Style guidelines and coding standards are the devil! I would enjoy
nothing more than reading an ACM paper entitled "Coding Standards
Considered Harmful". I've never seen a single real-life case where the
coding standard was anything other than the personal preferences of the
guy in charge. No consensus, no objectivity, just consistently
unreadable code.

I think nothing is more evil about coding standards than indentation.
My code (not only in Python but in C/C++ and PHP as well) for whatever
reason always ends up having about 6 levels of indentation in some places.

If the "standard" indentation is anything more than 2 spaces:
for each little loop or conditional:
you have to indent more and more until:
long lines of code (such as calls or complex \
mathematical expressions) have to span more \
lines than they would if only the indentation \
were shorter
else:
you could simply wrap longer lines and complex \
mathematical formulas without indentation on the remaining \
lines but that just makes your code look like garbage
A close second is my undying hatred for same-line opening braces in C.
When's the last time you saw Pascal code like:
PROCEDURE This_language_sucks(); BEGIN
...
END;

So I hate coding standards eternally, and the ISO 9000 certifiers that
push them. They only result in the majority of developers hating to
write code. My opinion is that if engineers cannot be trusted to their
own coding styles, you should have caught that in the interview process
and not hired them. Open source projects have probably the best
argument for coding standards for that reason. Or, for large projects
and open source projects, have an auto-styler run on all checked-in
code. That would at least do away with the spaces-or-tabs problem.

--
Will Berry
Co-founder, Second Brain website hosting
http://www.secondbrainhosting.com/

[Greg Ewing (using news.cis.dfn.de)]

John Roth wrote:

I suspect that's a rather common error. I'd much prefer
that both find and index return an object that acted like
a number but returned the logically correct response when
queried as a boolean: true for zero and false for -1.

Good heavens, no! That would be a *massively* dangerous
object to have floating around in one's program...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Richie Hindle]

[Will]

I think nothing is more evil about coding standards than indentation.

The first time I hacked the sources to Python itself I was astonished to
find that the coding standard for the C code specifies 8-space indents and
a line limit of 80 characters. How could anyone write code in such a
restricted format? Then I looked at the code and realised what a
wonderful effect those rules have. The code is simple, clearly written,
well organised and easy to read and understand. And I believe the code I
contributed is higher quality as a result of those restrictions. Had I
followed my own (loose) standard of 4-character indents and 100-character
lines, the code would have been harder to read - it would have had deeper
nesting and more complicated expressions.

--
Richie Hindle
ri****@entrian.com

[Mel Wilson]

In article <c2*************@ID-169208.news.uni-berlin.de>,
"Greg Ewing (using news.cis.dfn.de)" <wm*******@sneakemail.com> wrote:

John Roth wrote:

I suspect that's a rather common error. I'd much prefer
that both find and index return an object that acted like
a number but returned the logically correct response when
queried as a boolean: true for zero and false for -1.

Good heavens, no! That would be a *massively* dangerous
object to have floating around in one's program...

*Most* of them wouldn't float very far.. I presume that
when you did arithmetic on one of them, the magic wouldn't
metastatize to the result. So when one did escape from the
find/index context it would be the last thing anybody
expected.

Regards. Mel.
ob. c.l.p. fear, surprise

[Jorgen Grahn]

On Thu, 11 Mar 2004 17:39:31 -0500, Will Berry <wb****@wberry.org.x> wrote:

Style guidelines and coding standards are the devil! I would enjoy
nothing more than reading an ACM paper entitled "Coding Standards
Considered Harmful". I've never seen a single real-life case where the
Not an ACM paper, but ...

http://www.algonet.se/~jgrahn/anticodingrules.pdf

Disclaimer: it's an unfinished draft, and it was written in anger
during a period when I was ruled by a really stupid standard.
argument for coding standards for that reason. Or, for large projects
and open source projects, have an auto-styler run on all checked-in
code. That would at least do away with the spaces-or-tabs problem.

Argh! An auto-styler is the only thing I would hate more than a coding
standard... Coding style is style. People have style, programs do not.

/Jorgen

PS. I just read that PEP for the first time, and it's one of the most
reasonable style guides I've seen (meaning I already did most of that ;-).

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[MetalOne]

I do not like style guidelines either. If one method can be factually
proven better than another method, then it would make sense to
encourage the better method. However, when this can't be done, then
the guideline is simply based upon taste or gut instinct or personal
preference. These all vary from person to person and who is to say
what is correct.

During my schooling I was taught to always place statements on their
own line.
x = 0
y = 0
z = 0

I accepted this completely without thinking about it much.
20 years later I have finally come to realize that if (x,y,z)
represents a point that
x = y = z = 0 or
(x,y,z) = (0,0,0)
is not always so bad. It conserves lines of code, and being able to
see more lines of code at one time is beneficial.

Some guidelines recommend functions with only a single return point.
I don't understand why this insanity got started. At one point it was
recognized that multiple entry points into a function was confusing,
but why did it have to get extrapolated to multiple exit points. Upon
entry to a function, I sometimes like to verify that everything is ok
before proceeding and if it is not just get out. Parameters can
validated, resources acquired, or whatever.

At my work we currently have a guideline to always use brackets in
"if" statements.
if
{
single statement
}
else
{
single statement
}

Simply on the basis that somebody might forget the braces when adding
another statement to the block. Has this ever actually happened?
What about actually testing the code? It is not too onerous of a
guideline, but it does increase lines of code, which affects the
ability to easily see more code, which affects overall readability in
some cases.

Even the usual guideline of placing statements on separate lines I
think is sometimes a mistake.
if cond: statement
elif cond: statement
else: statement

does not always seem too bad to me where you always just have a single
statement.

Somebody once convinced me that I should always use descriptive
unabreviated variable names. At first this advice seemed a little
strange to me. Most code that I had ever encountered abreviated
variable names. Vowels tend to be left out. I think it might be a
FORTRAN hold over where variables had to be 6 characters or less or
was it 8. After a while, I realized people do things like
cnt, instead of count. sz instead of size. tmr instead of timer. I
finally agree that long unabbreviated names are better. Years later,
I realize that expressions can be hard to read with long variable
names. It occurs to me that mathematics always use one character
variables like x,y,z or the greek symbols. Expressions are just
easier to read. You can simply comment what 'x' means. So variable
length is not always so simple to decide upon.

And so it goes. I guess I am a believer in TIMTOWTDI.

The other thing about guidelines is that once somebody publishes a
book with guidelines, lookout. Your employer may soon have you
following them all whether you agree with them or not. Rational Rose
and UML are great examples of this, but that is another story.

[Heather Coppersmith]

On 12 Mar 2004 23:08:19 -0800,
jc*@iteris.com (MetalOne) wrote:

I do not like style guidelines either. If one method can be
factually proven better than another method, then it would make
sense to encourage the better method. However, when this can't
be done, then the guideline is simply based upon taste or gut
instinct or personal preference. These all vary from person to
person and who is to say what is correct.
Agreed.
During my schooling I was taught to always place statements on their
own line.
x = 0
y = 0
z = 0 I accepted this completely without thinking about it much.
20 years later I have finally come to realize that if (x,y,z)
represents a point that
x = y = z = 0 or
(x,y,z) = (0,0,0)
is not always so bad. It conserves lines of code, and being able to
see more lines of code at one time is beneficial.
In python,

x = y = z = 0
(x, y, z) = (0, 0, 0)

is exactly two statements, so all is still well with the world. ;-)
Some guidelines recommend functions with only a single return
point. I don't understand why this insanity got started. At
one point it was recognized that multiple entry points into a
function was confusing, but why did it have to get extrapolated
to multiple exit points. Upon entry to a function, I sometimes
like to verify that everything is ok before proceeding and if it
is not just get out. Parameters can validated, resources
acquired, or whatever.
It's that "resources acquired" part that messes people up. I've
seen it over and over and over again. Memory leaks. Dangling
pointers. Unrecoverable file handles. Especially as functions
that acquire lots of resources evolve over time and someone adds
code to acquire another resource or detect another error condition
and then doesn't find all the subsequent exit points. It's less
of an issue with languages with proper garbage collection, but it
can be a real nightmare in (e.g.) C or assembler. Unit tests that
cover all possible resource leaks are difficult to construct
correctly. C++ partially addresses the problem with RIAA (if
coders use it properly) and a hodgepodge of "smart" objects that
do pseudo self-garbage collection.

A single exit point also gives me a fighting chance to add
something to the logical end of a function, like setting the "I'm
done" flag or logging the result.

If I know that my function only has one exit point, then it's also
easier to add "let's see what this function is returning"
debugging code, because I know exactly where to put it and where
to look for it later when I want to take it out. In some systems,
the fact that a given function reaches its (single) exit point is
extremely valuable information.

OTOH, I'm usually the first one to stand up at a design review and
declare that some function or some method is too long or too
complex and should be broken up *before* such problems occur.

And that all said, I agree that a bunch of pre-checks and a quick
exit, BEFORE DOING ANYTHING ELSE, near the top of a function can
make the rest of some functions much more clear. Again, I've seen
it a million times: I'll add one more validation down here, but
forget to release that memory we just acquired up there.
At my work we currently have a guideline to always use brackets in
"if" statements.
if
{
single statement
}
else
{
single statement
}
Yep, those guidelines are useless. Shouldn't we spend our code
review time doing something productive?
And so it goes. I guess I am a believer in TIMTOWTDI.
The more code I read, the more I wish people would use the
*obvious* way. ;-)
The other thing about guidelines is that once somebody publishes
a book with guidelines, lookout. Your employer may soon have
you following them all whether you agree with them or not.
Rational Rose and UML are great examples of this, but that is
another story.

Yes it is, and I have lived it. Eeuuww.

Regards,
Heather

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

[MetalOne]

> It's that "resources acquired" part that messes people up. I've

seen it over and over and over again. Memory leaks. Dangling
pointers. Unrecoverable file handles. Especially as functions
that acquire lots of resources evolve over time and someone adds
code to acquire another resource or detect another error condition
and then doesn't find all the subsequent exit points. It's less
of an issue with languages with proper garbage collection, but it
can be a real nightmare in (e.g.) C or assembler. Unit tests that
cover all possible resource leaks are difficult to construct
correctly. C++ partially addresses the problem with RIAA (if
coders use it properly) and a hodgepodge of "smart" objects that
do pseudo self-garbage collection.

A single exit point also gives me a fighting chance to add
something to the logical end of a function, like setting the "I'm
done" flag or logging the result.

If I know that my function only has one exit point, then it's also
easier to add "let's see what this function is returning"
debugging code, because I know exactly where to put it and where
to look for it later when I want to take it out. In some systems,
the fact that a given function reaches its (single) exit point is
extremely valuable information.

OTOH, I'm usually the first one to stand up at a design review and
declare that some function or some method is too long or too
complex and should be broken up *before* such problems occur.

And that all said, I agree that a bunch of pre-checks and a quick
exit, BEFORE DOING ANYTHING ELSE, near the top of a function can
make the rest of some functions much more clear. Again, I've seen
it a million times: I'll add one more validation down here, but
forget to release that memory we just acquired up there.

Good points.
With resource acquistion, I was mainly thinking along the lines of

int file_compare(const char *filename1, const char *filename2)
{
FILE *infile1 = fopen(filename1, "r");
FILE *infile2 = fopen(filename2, "r");
if (!infile1 || !infile2)
{
// error
if (infile2)
fclose(infile2);
if (infile1)
fclose(infile1);
return FAILURE;
}

// compare files
return SUCCESS
}

as opposed to

int file_compare(const char *filename1, const char *filename2)
{
int result = SUCCESS;
FILE *infile1 = fopen(filename1, "r");
if (infile1)
{
FILE *infile2 = fopen(filename2, "r");
if (infile2)
{
// compare files
}
else
{
result = FAILURE;
}
}
else
{
result = FAILURE;
}
if (infile2)
fclose(infile2);
if (infile1)
fclose(infile1);
return result;
}

[Greg Ewing (using news.cis.dfn.de)]

MetalOne wrote:

I finally agree that long unabbreviated names are better. Years later,
I realize that expressions can be hard to read with long variable
names. It occurs to me that mathematics always use one character
variables like x,y,z or the greek symbols.

I think the important thing is not to use *arbitrary*
abbreviations. There is usually more than one plausible
way to abbreviate a long word to a medium-size word.
Remembering that it's abbreviated and exactly how it's
abbreviated is a cognitive burden that one can do without.
Deciding on no abbreviations cuts out a whole lot of
degrees of freedom that provide little benefit.

Extremely short names in the mathematics style are something
else, I think -- not so much abbreviations as a different
approach to naming altogether. It often makes sense,
especially if the names tie in with symbols used in
mathematics literature on the subject.

Also, local names are different from global ones. It
probably doesn't matter much what sort of names you
use locally, but global ones need to be as memorable
as possible. Descriptive, fully-spelled-out names
seem to be best for that.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Andy Salnikov]

"MetalOne" <jc*@iteris.com> wrote in message
news:92**************************@posting.google.c om...

Good points.
With resource acquistion, I was mainly thinking along the lines of

int file_compare(const char *filename1, const char *filename2)
{
FILE *infile1 = fopen(filename1, "r");
FILE *infile2 = fopen(filename2, "r");
if (!infile1 || !infile2)
{
// error
if (infile2)
fclose(infile2);
if (infile1)
fclose(infile1);
return FAILURE;
}

// compare files
return SUCCESS
}

as opposed to

int file_compare(const char *filename1, const char *filename2)
{
int result = SUCCESS;
FILE *infile1 = fopen(filename1, "r");
if (infile1)
{
FILE *infile2 = fopen(filename2, "r");
if (infile2)
{
// compare files
}
else
{
result = FAILURE;
}
}
else
{
result = FAILURE;
}
if (infile2)
fclose(infile2);
if (infile1)
fclose(infile1);
return result;
}

Latter version has an error - scope of infile2 is the first if _only_.
Write it like
this (and this is my preferred style too :)

int file_compare(const char *filename1, const char *filename2)
{
int result = FAILURE;
FILE *infile1 = fopen(filename1, "r");
if (infile1) {
FILE *infile2 = fopen(filename2, "r");
if (infile2) {
// compare files
result = SUCCESS ; // maybe
fclose(infile2);
}
fclose(infile1);
}
return result;
}

// Andy.

[Rocco Moretti]

Heather Coppersmith wrote:

On 12 Mar 2004 23:08:19 -0800,
jc*@iteris.com (MetalOne) wrote:

Some guidelines recommend functions with only a single return
point. I don't understand why this insanity got started. At
one point it was recognized that multiple entry points into a
function was confusing, but why did it have to get extrapolated
to multiple exit points. Upon entry to a function, I sometimes
like to verify that everything is ok before proceeding and if it
is not just get out. Parameters can validated, resources
acquired, or whatever.

It's that "resources acquired" part that messes people up. I've
seen it over and over and over again. Memory leaks. Dangling
pointers. Unrecoverable file handles. Especially as functions
that acquire lots of resources evolve over time and someone adds
code to acquire another resource or detect another error condition
and then doesn't find all the subsequent exit points. It's less
of an issue with languages with proper garbage collection, but it
can be a real nightmare in (e.g.) C or assembler. Unit tests that
cover all possible resource leaks are difficult to construct
correctly. C++ partially addresses the problem with RIAA (if
coders use it properly) and a hodgepodge of "smart" objects that
do pseudo self-garbage collection.

Unfortunately, the way I've seen "single exit points" handled in complex
functions is either to use a flag variable, which may or may not
correspond to the temporary variable for storing the return value, or to
enclose the whole function in an try: except block, raising a
specialized exception to quit. Neither of these is too elegant in my
opinion, and runs into the same problems seen with breaking out of
deeply nested loops. (A suggestion for which on a recent thread, BTW,
was to put them in a function and use return from multiple points).

Perhaps someone should write up a PEP:

def fun(params):
#Function body
finally:
#Cleanup code

Disavowing-all-responsibility-(Unless-Guido-likes-it)-ly'rs

-Rocco