Anti-Patterns in Python Programming

by aburan28 • 12 years ago

320 237 12 years ago

orf• 12 years ago

Interesting read, a couple of things I noticed though:

1. In "Checking for contents in linear time" both examples are the same. Perhaps remove the list entirely in the second example

2. Itertools.islice helps if you need to slice a list with a bajillion elements

tribaal2• 12 years ago

The more frequent and dangerous pitfalls are, in my humble opinion:

- Bare except: statements (that catches everything, even Ctrl-C)

- Mutables as default function/method arguments

- Wildcard imports!

scott_w• 12 years ago

Possibly the most interesting anti-pattern I saw was:

a_list_of_words = "my list of words".split(" ")

I never enquired why, since there were bigger issues in the code e.g. "unit testing" by running the code, taking the result and putting it as the check value. By running repr(value), copying out the string then comparing self.assertEqual(repr(value), '[<Object1: unicode_value>, ...]')

oddthink• 12 years ago

I do that all the time in the interpreter, especially when slicing pandas DataFrame objects, e.g.:

    df_subset = df['date buyer nwidgets'.split()]

That is far easier to type than the explicit list, with all its punctuation. Now, it's definitely weird that they did a `split(" ")` rather than just using the default, but the idea is the same.

I do try to strip stuff like that out before I put it into a script, replacing it with the explicit list, but I'm never sure if that actually improves anything. It's not as if the explicit list is any easier to read.

coldtea• 12 years ago

How is this a real "anti-pattern"?

Inefficent, or bizarre way to do it maybe.

Anti-pattern is supposed to mean something more, though.

In this case there are no adverse effects and no ambiguity -- so, I guess the programmer was just lazy to construct the list.

bkeroack7• 12 years ago

Why even use a list here? Tuples are for immutable/constant data.

a_tuple_of_words = ("my", "tuple", "of", "words")

a_tuple_of_words = "my", "tuple", "of", "words"

james2vegas• 12 years ago

perhaps that line was written by someone used to Perl, where they would have had

@a_list_of_words = qw/my list of words/;

there

bluecalm2• 12 years ago

This is actually useful: you may want to experiment with different list_of_words in the future and typing the words between [" ", " ", " "] is time consuming. It's also less readable.

cabalamat• 12 years ago

Mutables as default function/method arguments

It would really make sense to change the semantics of Python to fix this issue.

klibertp3• 12 years ago

Remove a `static` keyword from C (used inside a function) while you're at it...

bkeroack7• 12 years ago

Change them how, to no longer have functions be first class objects? The behavior of mutable default arguments is clear if you know how Python treats function objects. Any "fix" would handicap the language.

peter-row• 12 years ago

Also, not knowing what scope a variable has when creating closures.

SEJeff8• 12 years ago

Couldn't agree more! One of my all time new python interview questions gets a surprisingly large number of developers.

Given a function like:

    def append_one(l=[]):

        l.append(1)

        return l

What does this return each time?

    >>> append_one()

    >>> append_one()

    >>> append_one()

ryangittins2• 12 years ago

The l (lowercase L) and the 1 (one) look really similar. Could that be the cause of some confusion? Of course, the function name helps, but most developers have learned not to trust function names to be an accurate description of what the function does, especially in tricky interview questions.

Still, I'd change this to something like:

    def append_five(l=[]):

        l.append(5)

        return l

It tests the same thing (knowledge of how default parameters work), but without the confounding problem of similar-looking characters. Of course, syntax highlighting would help the applicant out.

All of that being said, I still don't doubt that many developers don't know what they should about default parameters.

jmount• 12 years ago

Wow, that is really ugly semantics. Here are some notes of mine on how hard R works to avoid exposing this sort of aliasing/mutability issue to the user: http://www.win-vector.com/blog/2014/04/you-dont-need-to-unde...

rmrfrmrf2• 12 years ago

At what level would you test an interviewee with this kind of question: Python guru, Python expert, Python ninja, Python rockstar, or merely "is familiar with Python"? Your example is a very common gotcha that has been covered ad nauseam, but IMO it's still the kind of bug that would be caught immediately in code review and is very easily fixed.

Retric• 12 years ago

I would caution you not to interview on things you would not be happy to see in your code base.

In my experence your much better off with people that look at odd syntax and say, "I don't know what that does" vs those who do.

mark-r3• 12 years ago

I've seen this trotted out time and time again, and at least in this simplified form it's a red herring. If you're going to mutate the argument, it doesn't make sense to give it a default value. If you're going to return a modified form of the input you need to make a copy of it. Doing both is simply absurd.

geertj2• 12 years ago

Agreed on all counts. However I do find myself using mutables as default arguments sometimes because the generated documentation is clearer.

For example, this is a real method in one of my projects:

  def listen(self, address, ssl=False, ssl_args={}):
      pass

I like the way this turns up in the docs because it's immediately clear that ssl_args needs to be a dict. Otherwise I have to describe it in words.

tribaal2• 12 years ago

Well, that's throwing people implementing subclasses under the bus, IMO.

Why not just add @param annotations in your docstrings instead?

jamiis• 12 years ago

You should not ever use mutable default args. The documentation benefit is drastically outweighed by the potential for nasty bugs. http://pythonconquerstheuniverse.wordpress.com/2012/02/15/mu...

kunstmord• 12 years ago

In case you're using Python 3, why not write ssl_args: dict, ssl: bool=False?

doctoboggan• 12 years ago

I agree that bare excepts are bad, however they do not catch Ctrl-C. If you _do_ want to catch Ctrl-C you have to except a KeyboardInterrupt explicitly.

njharman3• 12 years ago

This is untrue (just tested) for at least Python 2.7.x. under Linux, try ... except catches Ctrl-C.

LyndsySimon9• 12 years ago

Wildcard imports are OK, if and only if the module is specifically designed with this usage in mind.

Example: nose.tools

msvalkon• 12 years ago

Check out Raymond Hettingers Transforming Code into Beautiful, Idiomatic Python talk on youtube [1].

Great talk on avoiding some of the common pitfalls new python developers step in. Exposes some nice language features.

[1] https://www.youtube.com/watch?v=OSGv2VnC0go

gshubert172• 12 years ago

And the slides are here:

https://speakerdeck.com/pyconslides/transforming-code-into-b...

gr3yh47• 12 years ago

# Avoid this

lyrics_list = ['her', 'name', 'is', 'rio']

words = make_wordlist() # Pretend this returns many words that we want to test

for word in words:

    if word in lyrics_list: # Linear time

        print word, "is in the lyrics"

# Do this

lyrics_list = ['her', 'name', 'is', 'rio']

lyrics_set = set(lyrics_list) # Linear time set construction

words = make_wordlist() # Pretend this returns many words that we want to test

for word in words:

    if word in lyrics_list: # Constant time

        print word, "is in the lyrics"

the second example should read ... if word in lyrics_set: ...

darkxanthos• 12 years ago

Just to point out, if you really will have a tiny list and that's knowable, it's possible this example would be best with a straight linear time check. It could be fewer operations than hashing a string and looking it up. Practically pedantry though.

constantine_• 12 years ago

Thanks for pointing out this mistake. It's now fixed.

cuu5082• 12 years ago

write a list comprehension (...) code just looks a lot cleaner and what you're doing is clearer.

I know how to use list comprehensions, but often avoid using them and use the standard for loops. List comprehensions look nice and clean for small examples, but they can easily get long and become mentally hard to parse. I would rather go for three 30 character lines instead of one 90 character line.

meowface2• 12 years ago

I'm a bit torn on it.

In a case where you need to do a lot of nested appends, I've found that even a long list comprehension can be easier to read. You just have to be sure to properly indent it and break it up into multiple lines. My rule is that every extra `for` starts a new line, and sometimes moving the predicate to its own line when it's too long, too.

cuu5082• 12 years ago

For a concrete example, I was just recently converting a list-of-dicts into a dict-of-dicts. Here's an isolated snippet:

http://pastebin.com/8q46bK0v

To my eye, the list comprehension version is reasonable. But I like the imperative style better: it uses the most basic language features and at a glance you can tell what it does. My favourite is the dictionary comprehension version, it's the shortest but still conveys clearly what it's doing.

bkeroack7• 12 years ago

Depends on how you want to program: imperative vs functional.

Personally I think list comprehensions are the most beautiful part of Python, though sometimes I use map() when I'm trying to be explicitly functional (I realize it's allegedly slower, etc).

Generally I think list comprehensions are cleaner and allow you to write purer functions with fewer mutable variables. I disagree that deeply nested for loops are necessarily more readable.

existencebox• 12 years ago

Deeply nested I'd usually agree, but if you end up with deeply nested comprehensions as a result, in either case, you're probably better off with a little bit of restructuring/splitting things more functions to at least make the nesting cleaner to read.

However, I think he was referring to if the conditionals/additional modifications needed to build your list get a bit excessive, so you'd have a like... [dostuffto(A) for A in alsodostuffto(LIST) if conditional(A)] (but with more complex operations at each step).

Granted at that point you can argue that you should do just as my example shows and put the "dostuffto" into more encapsulated functions, but sometimes that doesn't seem like the right choice.

SEJeff8• 12 years ago

Map is not allegedly slower, it is demonstrably slower.

$ python -mtimeit -s'nums=range(10)' 'map(lambda i: i + 3, nums)' 1000000 loops, best of 3: 1.61 usec per loop

$ python -mtimeit -s'nums=range(10)' '[i + 3 for i in nums]' 1000000 loops, best of 3: 0.722 usec per loop

Function calls have overhead in python, list comprehensions are implemented knowing this fact and avoiding it so the heavy lifting ultimately happens in C code.

thinkpad20• 12 years ago

I agree. I try to use list comprehensions when I can, but the fact is that as soon as you have to do any sort of logic in your map, it quickly gets unwieldy. I'd much rather use a functional style in many of these cases, but python's syntax and crummy lambdas (as compared to what would be natural to do in say JavaScript or Ruby), means that in the majority of cases I find myself using an imperative style.

metaphorm2• 12 years ago

an anti-pattern is a design pattern gone bad. these aren't anti-patterns. they're just noobie mistakes and non-idiomatic expressions.

ascotan• 12 years ago

is it an anti-pattern to call something an anti-pattern because the author isn't sure what an anti-pattern is?

greenspider• 12 years ago

read this right after using a range in a loop in order to get the index. Can't believe I went this long without knowing about enumerate.

maxerickson2• 12 years ago

It first mentions enumerate as a footnote after looping with a range:

https://docs.python.org/2/tutorial/controlflow.html#for-stat...

But the tutorial in the Python docs has pretty high information density and good coverage of things like this.

(I think there is some risk that this comment will be interpreted as If you don't know enumerate you need to look at the tutorial. That isn't what I intend, I just want to point out that the tutorial is a reasonably dense resource that hits on a lot of stuff like enumerate.)

parham3• 12 years ago

Instead of this:

    # Do this  
    lyrics_set = set(lyrics_list) # Linear time set construction  
    words = make_wordlist()  
    for word in words:  
        if word in lyrics_set: # Constant time  
            print word, "is in the lyrics"

You could do this:

    lyrics_set = set(lyrics_list)  
    words = set(make_wordlist())  
    matched_words = list(lyrics_set & words)  
    for word in matched_words:  
        print word, "is in the lyrics"

LyndsySimon9• 12 years ago

Of, off the top of my head:

    for word in (set(lyrics_list) & set(words)):
        print('{} is in the lyrics'.format(word))

parham3• 12 years ago

Even shorter, nice. How about this one liner, the last bit is looking a bit messy any ideas?

    print " is in the lyrics \n".join([set(lyrics_list) & set(words)]), "is in the lyrics"

ForHackernews• 12 years ago

   matched_words = set(lyrics_list).intersection(make_wordlist())

LyndsySimon9• 12 years ago

I can't think of a single case where using sentinel values is necessary or appropriate in Python.

Generally speaking, one should just return from within the loop.

agentultra• 12 years ago

Funky OS of FFI APIs... but Python has a nice way of abstracting away the pattern using the second argument to iter().

jessaustin• 12 years ago

I get what you're saying, but even when sentinels are used inside a function, returning a -1 to the caller seems like a pretty bad API. It's OK to raise ValueError! I had thought the idiomatic sentinel value was an instance of object() you could is against, anyway.

LyndsySimon9• 12 years ago

I agree - especially when you're returning a list index, since `[-1]` is a valid index in Python.

omegote• 12 years ago

Point 3 of the iteration part is not good advice. With [1:] you're making a copy of the list just to iterate over it...

omaranto3• 12 years ago

You're right. I still wouldn't recommend looping over indices, but rather using itertools.islice(xs, 1, None) instead of xs[1:].

zo14• 12 years ago

You're right... But at least it's a shallow copy.

moretti• 12 years ago

I always struggle to understand why a list comprehension

  alist = [foo(word) for word in words]

is considered more Pythonic than map

  alist = map(foo, words)

XorNot• 12 years ago

You use list comprehensions in other places you wouldn't use map. The difference in text size as you posted is minimal, but the list comprehension - once you're used to reading them - tells you exactly what's going on.

Where as map could be anything. It could be redefined for all you'd know.

blossoms3• 12 years ago

    alist = [foo(word) for word in words if word.startswith('a')]
    alist = map(foo, filter(lambda word: word.startswith('a'), words))

Which reads better?

lolpep8• 12 years ago

Map and filter, of course; less syntactical noise, simple function semantics, and plenty of precedent and equivalents in all other languages.

TheLoneWolfling2• 12 years ago

Those are not equivalent. You need to wrap the map in a list() call.

RHSeeger• 12 years ago

Admittedly, my thought would be to chain the calls, not nest them:

   alist = words.filter(lambda word: word.startswith('a')
                .map(foo)

That being said, my Python is limited and I don't know it filter/map are available as methods of a list. At the end of the day, there are cases where list comprehensions are much cleaner/understandable... and cases where the reverse is true.

LyndsySimon9• 12 years ago

I don't use FP practices in Python much, but if I did I'd define the filter outside the map, like so:

    begins_with_a = lambda x: x.startswith('a')
    alist = map(foo, filter(begins_with_a, words))

metaphorm2• 12 years ago

you can consider a list comprehension to be a sort of literal representation of the result of map. I think literals have a benefit for code readability and should be used when feasible (i.e. the literal is compact enough).

the other reason its considered more idiomatic in Python is just because the compiler does a better job of parsing and optimizing list comprehensions.

ufo• 12 years ago

I think the main reason is the lambda syntax. List comprehensions also let you do filter and nested loops.

dagw• 12 years ago

List comprehensions are more flexible and easier to read in the non-trivial case. Sure in the trivial case you show a map might be considered neater, but just adding a filter is enough to make the list comprehension more readable in my mind. Python's lambda syntax also makes using maps and filters quite ugly.

Compare:

   alist = [x**2 for x in mylist if x%3==0]

   alist = map(lambda x: x**2,filter(lambda x: x%3==0, mylist)

Plus python also has set comprehension and dict comprehension, which share essentially the same syntax.

column• 12 years ago

hi, you are lacking a closing parenthesis in your second example.

Peaker3• 12 years ago

In Haskell, the latter looks like:

  alist = (map (**2) . filter (\x -> x `mod` 3 == 0)) myList

Or:

  alist = (map (**2) . filter ((== 0) . (`mod` 3))) myList

If alist is a transformation, and not applied to myList, it's cleaner:

  alist = map (**2) . filter ((== 0) . (`mod` 3))

Though Haskell also has list comprehensions, with more "mathy" syntax:

  alist = [x**2 | x <- mylist, x `mod` 3 == 0]

zo14• 12 years ago

Don't forget generator comprehensions which are almost identical to list comprehensions. But instead of evaluating the whole result set and returning it, they return a generator that you can then iterate over. Very neat stuff.

TheLoneWolfling2• 12 years ago

Those are not equivalent.

You cannot index a map object, for example.

a3n2• 12 years ago

Don't know if this is why, but the list comprehension takes an expression at the "foo(word)" location, and is therefore more general than map, which requires a function. The comprehension in that case is simpler.

  words = ['w1', 'w2', 'w3']

  [word[1] for word in words]

  ['1', '2', '3']
  
  map(lambda x: x[1], words)

  ['1', '2', '3']

I like looking at the list comprehension better. The use of lambda looks forced in this case. I also imagine there's a penalty for calling the (anonymous) function in map.

icebraining2• 12 years ago

In that case I'd use

  map(itemgetter(1), words)

yoo-interested3• 12 years ago

Speaking of find\_item, is the `for..else` loop (which can be used to write find\_item in another way) considered Pythonic? I personally like `for..else` loops but I don't know where the consensus is at.

PeterGriffin2• 12 years ago

http://en.wikipedia.org/wiki/No_true_Scotsman

Don't ask what's "more Pythonic" or "less Pythonic", Python is not a cult, it's a very practical scripting language. Ask for benefits and weaknesses of a given approach in given circumstances.

dlitz• 12 years ago

Speaking a language in the same way as other speakers of that language makes you easier to understand.

msellout5• 12 years ago

I don't see `else` used very often on loops, but it is an unambiguous language feature. That's Zen enough for me.

msl09• 12 years ago

I find that the testing for empty is a bit misguided if you want to be rigorous with types. for instance:

     >>>def isempty(l):
     >>>    return not bool(l)
     >>>isempty([])
     True
     >>>isempty(None)
     True

If embedded within your program logic this kind of pattern can waste precious time with debugging. You can catch your errors much more quickly if you are explicit with your comparisons.

u124556• 12 years ago

Consider using xrange in this case. Is xrange still a thing? doesn't range use a generator instead of creating a list nowadays?

omaranto3• 12 years ago

Well, I'd say no, not in "Python".

It seems to me that when people say "Python" they still mostly mean Python 2, where range returns a list and xrange a generator. In Python 3 there is no xrange and range returns a generator, but I think people still most often call that language "Python 3", not "Python".

minopret• 12 years ago

Yes, I'd revise as "Consider using Python 3 in this case." This is a chief reason why I now avoid Python 2. Python 3 is more than five years old. Where we have discretion to choose Python 3, it's time to exercise that discretion. Not because 3 is greater than 2. Because Python 2 has prominent pains that are healed in Python 3.

shadowmint• 12 years ago

Mmm... you should always use 'if x is not None:' imo.

It's very common for libraries to make values evaluate to False, and very easy to get bugs if you just lazily test with 'if x'.

Sqlalchemy springs to mind immediately as one of the common ones where using any() and if x: is a reeeeeallly bad idea; there are plenty of others.

I'm pretty skpetical about modifying your coding behavior based on what libraries you happen to be currently using.

'If x' isn't your friend.

tomp• 12 years ago

Especially taking into account the more bizarre bugs (features?) of python:

    (bool(datetime.time(0)), bool(datetime.time(1))) == (False, True)

I always consider `if x:` a bug, unless x can only be a boolean. Furthermore, it seriously hinders readability and clarity of the code.

CmdrKrool2• 12 years ago

Agreed. Especially if you program in more than one language, trying to remember the subtleties of each one's collection of rules for "truthiness" is a fraught exercise. And isn't it Python people who like to say, "explicit is better than implicit"?

Zancarius• 12 years ago

I was specifically looking through these comments for your example.

I got bit by this once, and it's certainly... strange (it's also surprising). It's considered "behavior consistent with the rest of Python" [1] (which I can agree with) even if it makes little sense in terms of immediate readability to someone who hasn't previously encountered it. Fortunately, the workaround is easy, and it is documented.

There's at least a couple of spats on the mailing list regarding this feature that are of interest to the curious or at least those who are interested in the history of such behavior.

[1] http://bugs.python.org/issue13936

rmrfrmrf2• 12 years ago

I always consider `if x:` a bug, unless x can only be a boolean.

Oh, like this? ;)

   var eventA = new Date(), eventB = new Date();

   if (!parseInt((eventA - eventB) / 1000)) {
     console.log("these events occurred simultaneously");
   } else {
     // troll harder with confusing use of 'asynchronous'
     console.log("these events occurred asynchronously");
   }

LyndsySimon9• 12 years ago

It depends.

If you're checking to see if that value is None, then yes - you should check that.

If you're merely checking if the value is truthy, then using "if x:" is completely legitimate.

pyfish• 12 years ago

I agree. The author brings this to light as well and warns about the implications of changing what is considered "truthy" in x.

keeperofdakeys2• 12 years ago

I've found "if x" to be much less readable, especially when I'm looking at code written in a language I'm not familiar with. When I'm reading such code, I want to be 100% what something is doing, and not have to read documentation when avoidable.

glimcat• 12 years ago

    "Explicit is better than implicit."

If you mean is not None, you should say is not None.

It's fast and readable and there are no "just be aware that" disclaimers to tack on afterwards.

sophacles5• 12 years ago

The only thing I disagree with is "use nested comprehensions" thing. In my mind: x = [letter for word in words for letter in word]

is inside-out or backwards or backwards. I want the nested for being the less specific case:

   x = [letter for letter in word for word in words]

makes more sense in my mind.

(It's also my first answer to the "what're some warts in the your language of choice).

jules4• 12 years ago

Even clearer:

    x = [for word in words: for letter in word: letter]

This also has the advantage of being readable left to right without encountering any unbound identifiers like all other constructs in Python.

hueving5• 12 years ago

As someone who spends a significant amount of time in python that is much harder to follow. There is an expectation for order in list comprehensions and what you wrote completely violates it.

njharman3• 12 years ago

I'm in the camp that if your list comp needs more than one for clause, it's complicated enough to be broken out into actual for loop.

jevgeni2• 12 years ago

Everybody, listen to this person!

wodenokoto• 12 years ago

I use python for datamining, and most of my work is done exploring data in iPython.

First, don't set any values in the outer scope that aren't IN_ALL_CAPS. Things like parsing arguments are best delegated to a function named main, so that any internal variables in that function do not live in the outer scope.

How do I inspect variables in my main function after I get unexpected results? I always have my main logic live in the outer scope because I often inspect variables "after the fact" in iPython.

How should I be doing this?

hyperion2010• 12 years ago

If you are using the interpreter directly then that particular bit of advice is hard to follow since you basically live in global all the time. For that reason I would say that this advice applies mainly to .py files.

LyndsySimon9• 12 years ago

Agreed.

There's a big difference between "scripting" and "writing software" in terms of best practices.

If you're writing some ETL scripts in an IPython notebook, it would be overkill to encapsulate everything to keep your global scope clean.

msellout5• 12 years ago

I'd try to test smaller chunks of code for validity. If any block of code is longer than 12 lines, I get nervous that I don't understand what it's doing. Refactor your code into functions as you confirm the code behaves as expected in the interpreter.

It's very difficult to write automated tests when all logic is in outer scope rather than chunked into functions.

yeukhon• 12 years ago

PEP 8 is the universal style guide for Python code.
If you aren't following it, you should have good reasons beyond "I just don't like the way that looks."

Core dev and Guido have said many times PEP 8 are not holy.

See https://mail.python.org/pipermail/python-dev/2010-November/1...

In essence, a "stupid reason" like "I don't like it" is a valid reason not to adopt PEP 8.

In fact, I don't like the PEP 8 recommendation on docstring. I like Google's docstring (aka napoleon in Sphinx contrib-module).

http://sphinxcontrib-napoleon.readthedocs.org/en/latest/exam...

me_myself_and_I• 12 years ago

I don't think there us such thing as a pattern per language, unless the language is really unique. IMO what does exists is Language Bad Practices, which are actually tied to the language itself.

An (anti)pattern is something abstract and can be applied to any other similar language.

mimighost• 12 years ago

I would say that the leaky out scope problem combined with those really similar typos is perhaps most diffcult to spot out.

noobermin2• 12 years ago

Question, how do you over multiple long lists (in python 2) especially if zip itself takes a long time to zip them, for example.

takeda• 12 years ago

You use Python 3.

J/K, while this is technically a limitation of Python 2, there actually is izip in itertools package which is a generator and works in similar way to zip in python 3.

noobermin2• 12 years ago

Awesome! I knew there was some lazy zip-ish thing for python 2. I personally hate using range(len(foo)) as anyone else.

jimmaswell2• 12 years ago

You just use a for i in range(len(... and ignore this web article's opinion on it since the situation calls for it

ggchappell• 12 years ago

This is a nice little article, but I wonder about some of the design decisions. In particular:

The simplifications employed (for example, ignoring generators and the power of itertools when talking about iteration) reflect its intended audience.

Are generators really that hard? (Not a rhetorical question!)

The article mentions problems resulting from the creation of a temporary list based on a large initial list. So, why not just replace a list comprehension "[ ... ]" with a generator expression "( ... )"? Result: minimal storage requirements, and no computation of values later than those that are actually used.

And then there is itertools. This package might seem a bit unintuitive to those who have only programmed in "C". But I think the solution to that is to give examples of how itertools can be used to create simple, readable, efficient code.

elandybarr3• 12 years ago

Failing to use join is a big one.

I have seen countless instances of people writing the logic to output commas in between items (like for CSV export) that they want to concatenate into a string.

    header_line = ','.join( header for header in headers )
    csv_line    = ','.join( str(dataset[key]) for key in dataset.keys() )

Example for a case of a dictionary mapping a string to a bunch of numbers.

cpenner461• 12 years ago

Any reason not to do the first one more compactly?

     ','.join(headers)

elandybarr3• 12 years ago

Oops. Good catch!

marcinw• 12 years ago

Proper Python would use the csv module for this operation, as your CSV export would break if `header` or `dataset[key]` contains a comma.

elandybarr3• 12 years ago

Yeah. This was a special case for a one line CSV that was requested by my client. It was a dictionary with a bunch of single measurements.

rcfox• 12 years ago

You should just use dataset.values() (or itervalues if you're using Python 2) instead of iterating over the keys, and then looking them up.

andreasvc• 12 years ago

You're relying on dataset.keys() being in the same order as headers. Really, you should use the csv module, even for one-line CSV files.

me_and• 12 years ago

Things like parsing arguments are best delegated to a function named main, so that any internal variables in that function do not live in the outer scope.

Why a function named `main`? We're not writing C here, there's no need for a function named `main`. Let's call it something that's actually useful, like `parse_cmd_arguments`

natmaster• 12 years ago

islice should be used, not xrange

jimmaswell2• 12 years ago

Set membership checking is constant-time? Somehow I don't believe that.

TorKlingberg• 12 years ago

It's a hash table, so constant time lookup in the average case. It could be argued that it's actually O(log(n)), but it would not matter for any practical n.

kstrauser• 12 years ago

Sets are basically hash tables that store only keys and not values. You can easily write your own Set implementation by subclassing `dict` and stripping out references to `.values()`, etc.

As such, testing for membership is an O(1) hash table lookup. If you're skeptical:

    $ python -m timeit -s 'nums=range(1000000)' '100000 in nums'
    1000 loops, best of 3: 1.4 msec per loop
    
    $ python -m timeit -s 'nums=range(1000000)' '500000 in nums'
    100 loops, best of 3: 7.15 msec per loop
    
    $ python -m timeit -s 'nums=range(1000000)' '900000 in nums'
    100 loops, best of 3: 13 msec per loop
    
    $ python -m timeit -s 'nums=set(range(1000000))' '100000 in nums'
    10000000 loops, best of 3: 0.0572 usec per loop
    
    $ python -m timeit -s 'nums=set(range(1000000))' '500000 in nums'
    10000000 loops, best of 3: 0.057 usec per loop
    
    $ python -m timeit -s 'nums=set(range(1000000))' '900000 in nums'
    10000000 loops, best of 3: 0.0584 usec per loop

Anti-Patterns in Python Programming

Related Stories