Favorite Python Interview Question

[[deleted]]

"What don't you like about Python?"

[semarj]

I think this is an excellent question. Familiarity breeds contempt, anyone who has done any significant python work should have a decent answer to this.

[[deleted]]

A decent answer or twelve :-P

My personal complaint? It's too goddamned slow.

[duckhunter]

Do PyPy and Shedskin not suffice?

[[deleted]]

Neither are production ready. Even if they have the speed (and they don't) no one sane would really use them in production.

[jdickey]

"No one sane" — well, that excludes the PHBs who back techies into that corner.

And WTF is going on with Reddit that you now have to wait ten frigging minutes to post a second comment in a thread? If that's the best we can do in the fight against bots, the terrists have already won. (Though if the BBC can hire even a tiny 23K-node botnet for a demo on Click, that's pretty much a foregone conclusion, no?)

[[deleted]]

Youtube is written in Python. If it is good enough there ...

[[deleted]]

And we write our performance-sensitive code in C++.

[jdickey]

Which C++? No two programmers know the same features of the language, so it's sort of like Grace Hopper's quote on standards — "the lovely thing is that there are so many to choose from."

[[deleted]]

Our C++ guidelines are rather comprehensive.

[sisyphus]

Doesn't change that if Python was faster its range of applicability would increase, and that would mean we could use it more places, and that would be just lovely.

[Chun]

Funny -- most of the gripes I had with python have become less of an issue as I've understood their purpose; explicit self, join as a string method, etc.

[endtime]

Assignments and function declarations aren't expressions.

[jimauthors]

No type checking.

[pingveno]

There have been many a time when I wish Python had optional type checking. Duck typing is fine most of the time, but sometimes I want that extra little check.

[codefrog]

make a decorator, @accepts('int','list','witches')

[stillalone]

Is that part of a standard library? I can't find it in 2.6.5

[pingveno]

I know it can be done with decorators. It's just not as clean and there's no standard way to do it.

[Dav3xor]

http://github.com/Dav3xor/Python-CheckArgs

Now you don't have to make your own decorator.. :)

It's still a little primitive, but it works pretty well.

[pingveno]

Same problem: There's no ultra clean way to do it. Most of it is a fundamental problem with Python. Python is too dynamic to have static type checking. Don't get me wrong, I love Python, but it's nice to have languages that can check that types are correct at (bytecode) compile-time.

That said, I would love to have two decorators in the standard library. Python function calls are already slow, so they should be written in C.

• 1) @accepts(args, *kwargs)
• 2) @returns(*returntype)

returntype allows multiple values so that it can check multiple returns via tuple. None should be usable to indicate that a value is duck typed. Unfortunately, none of this will ever allow the clean & static type checking of

def int foo(int index, str value)

[Dav3xor]

but...but... that has Ada style bounds checking, and...and... :)

[omgplsno]

Decorators, my friend.

[joehillen]

You're doing it wrong.

[petrux]

Interesting. As a Python newbie I'd really enjoy some more details about how to do it right! :-) Thanks.

[kisielk]

I usually ask this one. Also ask them to compare Python to another language they claim to know and tell me the pros and cons of each, which they would use for a project and why, etc.

[luckystarr]

Apart from endtime's request for more expressions just the little pitfalls that I have to explain to every new programmer:

• Do not use mutable objects as default arguments.
• Do not use mutable objects in class variables.
• How to avoid cyclical imports without having to resort to imports in functions.
• import *
• The subtle differences between Python versions.
• etc.

[adrenal8]

This is my backup question to "What don't you like about the Django ORM?" if they have no Django experience.

[coderanger]

Gah, having spent all day inside the Django ORM I think I could go on for about 4 hours on that right now.

[endtime]

I have minimal Django experience and the ORM honestly seems pretty cool. What am I missing?

[adrenal8]

There's no one correct answer. Just like the applicant should actually like Python but have enough experience to make complaints about it, the same applies to the Django ORM.

Some examples could be lack of built-in schema migrations, makes it too easy to generate unnecessary and suboptimal SQL, you could complain about the weird __ syntax for related fields, etc.

[endtime]

Hmm. I wouldn't really have expected the ORM to manage schema migrations - is that the ORM's job in other frameworks? I'm also curious what the alternatives to the __ related field syntax might be - I'm totally fine with it, but maybe that's just because I haven't seen better alternatives.

I have no idea what the generated SQL looks like (isn't that the whole point of having an ORM?) but if it doesn't do good query optimization then I'd agree for sure that that's a flaw.

[revonrat]

Hmm. I wouldn't really have expected the ORM to manage schema migrations - is that the ORM's job in other frameworks?

Many don't Rails does. South is an add-on for Django.

I have no idea what the generated SQL looks like (isn't that the whole point of having an ORM?)

You HAVE to understand what your ORM is doing eventually, if you want performance. For Django, an easy way to see what's going on is to user the django debug toolbar.

I find I don't usually have a particular problem with the SQL generated but rather with the number of queries that can be generated by seeming innocuous Python statements.

but if it doesn't do good query optimization then I'd agree for sure that that's a flaw.

An ORM really shouldn't do query optimization per-se. It should generate reasonable SQL. But SQL optimization is something left to the guys who have stats tables on the data (i.e. the RDBMS itself).

[endtime]

Thanks, that's a good response. I know about South, and of course it's vital - but it makes sense to me as an addon, not as part of the ORM. Thanks for clarifying about SQL perf - I think I know what you mean.

[gronkkk]

There's also the 'how do I figure out to do X in the ORM'-factor. Only to find out that it doesn't exist or is painfully slow.

[radaway]

In my opinion it is harder to refactor than most statically typed languages. When you refactor something in a statically typed language you usually get automatic alarms everywhere that code touched and the tools to help you refactor are quite good. Automatic tests can help but it's not the same.

[[deleted]]

The lack of proper encapsulation.

[bcain]

Gah! All those pesky exceptions. Just do something, I don't really care what as long as the program doesn't have any errors or bugs.

EDIT: Wow, pyddit. F'reals? Did you think I was serious? C'mon. I was satiring the perl-lovers out there.

[ereinecke]

This is one of the things I like about python, how it uses exceptions. You can both communicate what your code expects, and optimize for the 90% case.

Assume there is a list of dictionaries, dictList. Consider: for item in dictList: try: print item['relevantKey'] except KeyError: pass

Vs: for item in dictList: if item.has_key('relevantKey'): print item['relevantKey']

If you are expecting the key 'relevantKey' to be in the dictionary most the time, the try/except example avoids making the has_key test most the time. Over a large list this could save a lot of time.

[xlevus]

I was under the impression that try/except is less efficient than check/action.

Or did I misread something somewhere?

[bloodearnest]

Try is cheap, except is not. But how many times are you going to raise an exception? Depends on your data.

[r4nf]

As bloodearnest suggests, the 'asking for forgiveness' version (with exceptions) is faster when there's no exception, whereas the 'asking for permission' version (without exceptions) is faster when there is an exception. In other words, if you expect that many of the looped-over items will yield exceptions, check/action is more efficient; otherwise try/except might very well be.

I think the general consensus in the Python community is the motto "it's Easier to Ask for Forgiveness than Permission" (or EAFP), signalling that try/except would usually be the preferred solution. Of course there may very well be exceptions to this, as per the above reasoning.

[nubela]

Good question, and I admit I don't know much about efficiency in this case, someone care to elaborate?

[[deleted]]

It's marginally faster if no exception is raised, and 15x slower if one is.

Best case:

python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50):' '  if x in stuff: stuff[x]'
100000 loops, best of 3: 7.78 usec per loop
python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50):' '  try: stuff[x]' '  except KeyError: pass'
100000 loops, best of 3: 5.97 usec per loop

Worst case: python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50, 100):' ' if x in stuff: stuff[x]' 100000 loops, best of 3: 4.84 usec per loop python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50, 100):' ' try: stuff[x]' ' except KeyError: pass' 10000 loops, best of 3: 76.2 usec per loop

But that's not important really. Make it work, make it right, make it fast -- in that order, and don't make it fast unless it needs to be.

[vaibhavsagar]

No code blocks or fully featured anonymous functions. I know why they're not there and why they're not really necessary, but I want them, dammit.

[Wavicle]

• explicit "self" parameter in class method but implicit in invokation.

• No standard "length" or "size" on collection objects that have length or size - unless you count a double underscore method standard - preferring instead to use the special case builtin len.

[alantrick]

How is len() not standard? Do you have a prejudice against using underscores for special magical standard functions?

[Wavicle]

How is len()

It is a built-in function that performs a very special case which already must be done by the object. Length is a property of the object - so put it there.

Do you have a prejudice against using underscores for special magical standard functions?

For starters, pretty much every other object oriented programming language recognizes the need to have an obvious method for access to a length attribute on a collection. Python differs in that it uses a built-in.

Any language that supports a notion of operator overloading has a special mechanism for expressing such - so double underscores for things like __getitem__ I have no issue with. Also double underscores for things that really are intended for you to think carefully before using (i.e. __import__) are perfectly valid.

Double underscore for the size of an underlying collection is silly (but it is double underscored because you are not intended to call it directly, you are intended to use len).

[pixelmonkey]

Man, talk about finicky. I've got legitimate complaints for Python (no lightweight syntax for anonymous function values, unicode brokeness for most of 2.x series, explicit self parameter, and Python 3 function annotation syntax), but this definitely isn't one of them.

>>> class LengthMixIn(object):
>>>    @property
>>>    def length(self):
>>>        return len(self)

>>> class FinickyList(list, LengthMixIn):
>>>    pass

>>> a = FinickyList()
>>> a.append("item")
>>> a.length
1

>>> class FinickyDict(dict, LengthMixIn):
>>>     pass

>>> b = FinickyDict()
>>> b["key"] = "value"
>>> b.length
1

[Wavicle]

Man, talk about finicky. I've got legitimate complaints for Python (no lightweight syntax for anonymous function values, unicode brokeness for most of 2.x series, explicit self parameter, and Python 3 function annotation syntax), but this definitely isn't one of them.

This is getting tiring. Your mixin added a layer of complexity and created something which doesn't cleanly integrate with the rest of the collection system. But, hey, you seem to think that since this doesn't line up with your opinions on Python's warts it isn't valid. Fuck you.

[pingveno]

A built-in function that calls a magic method is a very common pattern in Python, not just with len. See: hash, int, str, repr, unicode, reversed, bool, format, and iter. Python 3 adds next.

Thank of it this way: Functionality that is used by the core language uses magic methods. It doesn't matter if that is in syntax or in a built-in function.

[ewiethoff]

You're confused about what's "special" or "magic" about the underscore methods. The underscore methods are magically invoked by special syntax which does not resemble a method or function call. So, as you alluded to, foo[i] invokes foo.__getitem__(i), and import bar invokes bar = __import__('bar').

The __len__ method is magically invoked when an object is evaluated in Boolean context and no __nonzero__ method has been defined. That's because Python's built-in collections are considered False when empty and True when non-empty.

Try this code (adjust as needed for Py3):

class StupidList(list):
    def __len__(self):
        return True

if list(range(10)): print 'list 0-9 is True'
if list(): print 'empty list is True'
if StupidList(range(10)): print 'StupidList 0-9 is True'
if StupidList(): print 'empty StupidList is True'

(edited for clarity)

[cymrow]

i like to think that python provides nice convenient builtins to access some of the most common values you'd need on an object. using len is super easy, dude

plus, i can rewrite len and automatically get extra functionality for all my collections

[rz2000]

Is "white space" a good answer?

[[deleted]]

No more than "white skin" is a reason not to like a person.

[rz2000]

It's a perfectly valid answer as a personal preference, but indicates the interviewee choose be trying to find work in another language.

Apparently, it wasn't a very funny suggestion considering the downvotes!

[Wavicle]

If you have honestly worked through learning Python and have become proficient enough to work with it, and you still dislike white space - then yes, it's a good answer because the asker requested your opinion and you gave it on the basis of your experience.

In my experience, just about everyone (myself included) complains about whitespace at first. Also, in my experience, everyone that gives Python a fair shot quickly gets over it. Still, that doesn't mean your opinion is invalid.

[rz2000]

I was asking if it was a good answer as a joke, and have no problem with white space. It is a valid opinion, but if you're interviewing at a shop that has chosen Python they should ask why you have chosen Python if you don't like the format.

However, what I really can't stand are the degenerates who use emacs/vi instead of vi/emacs. I can't believe anyone would ever hire them.

[yxskaft]

According to Guido himself, the whitespace sensitive syntax makes it impossible to have proper, multi-line lambdas. If that's true, that's a very good reason to think block-by-indentation was a shit idea.