Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python Interview Questions

Reply
Thread Tools

Python Interview Questions

 
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-19-2012
On Mon, 19 Nov 2012 09:59:19 -0500, Roy Smith wrote:

> OK, I've just read back over the whole thread. I'm really struggling to
> understand what point you're trying to make. I started out by saying:
>
>> Use a list when you need an ordered collection which is mutable (i.e.
>> can be altered after being created). Use a tuple when you need an
>> immutable list (such as for a dictionary key).

>
> To which you obviously objected. So now you write:
>
>> I think a tuple is an immutable sequence of items, and a list is a
>> mutable sequence of items.

>
> So how is that different from what I said? Is this whole argument
> boiling down to your use of "immutable sequence" vs. my use of
> "immutable list"?


Sheesh, of course not. Give me some credit.

I gave some examples of when somebody might use lists, tuples, sets and
dicts. Apparently I forgot a couple, and you responded with a sarcastic
comment about the "One True Church Of Pythonic Orthodoxy And Theoretical
Correctness" and gave a couple of additional examples.

Although I didn't come out and *explicitly* say "I agree" to your
examples, I actually did, with one proviso: your example of using an
"immutable list" as dict key. So I asked a question about that *specific*
use-case:

[quote]
Under what sort of circumstances would somebody want to take a mutable
list of data, say a list of email addresses, freeze it into a known state,
and use that frozen state as a key in a dict? What would be the point?
Even if there was some meaningful reason to look up "this list of 12000
email addresses" as a single key, it is going to get out of sync with the
actual mutable list.
[end quote]

Your reply was to give your stack trace script as an example. That's a
fine example as a use-case for a temporary list, and I've done similar
things dozens, hundreds of times myself. As I said:

[quote]
Sure, I have built a collection of items as a list, because lists are
mutable, then frozen it into a tuple, and *thrown the list away*, then
used the tuple as a key. But that's not the same thing, the intent is
different. In my case, the data was never intended to be a list, it was
always intended to be a fixed record-like collection, the use of list was
as a temporary data structure used for construction. A bit like the idiom
of ''.join(some_list).
[end quote]

To me, this sounds *exactly* like your use-case: your data, stack traces,
represent a little chunk of immutable data that you build up a line at a
time using a temporary list first, just like I wrote. And I said so.
There's no sign in either your code or your description that the stack
traces get treated as mutable objects in any way once you have finished
building them a line at a time. So your real world, practical, "in the
trenches" example matches my experience: you build a *fixed data record*
using a *temporary list*, throw the list away, and then never mutate that
data record again.

So why are we disagreeing? Like many such discussions on the Internet,
this one has rambled a bit, and I've misunderstood some of your code
(sorry), and you seem to have misunderstood the question I am asking.
Maybe my explanation was not clear enough, in which case, sorry again.

I'm asking about the case where one might want the key to remain mutable
even after it is used as a key, but can't because Python won't let you.
There's no sign that your stack trace example is such an example.

As I earlier said:

[quote]
But I can't think of any meaningful, non-contrived example where I might
want an actual mutable list of values as a dict key.
[end quote]


and I still can't.



--
Steven
 
Reply With Quote
 
 
 
 
Prasad, Ramit
Guest
Posts: n/a
 
      11-19-2012
Roy Smith wrote:

>
> OK, I've just read back over the whole thread. I'm really struggling to
> understand what point you're trying to make. I started out by saying:
>

> > Use a list when you need an ordered collection which is mutable (i.e.
> > can be altered after being created). Use a tuple when you need an
> > immutable list (such as for a dictionary key).

>
> To which you obviously objected. So now you write:
>

> > I think a tuple is an immutable sequence of items, and a list is a
> > mutable sequence of items.

>
> So how is that different from what I said? Is this whole argument
> boiling down to your use of "immutable sequence" vs. my use of
> "immutable list"?



'''
Roy:

> Usea list when you need an ordered collection which is mutable (i.e.
> can be altered after being created). Use a tuple when you need an
> immutable list (such as for a dictionary key).

Steven:
I keep hearing about this last one, but I wonder... who *actually* does
this? I've created many, many lists over the years -- lists of names,
lists of phone numbers, lists of directory search paths, all sorts of
things. I've never needed to use one as a dictionary key.
'''

To me this is more of a question than an argument. Now moving
on to your specific example.

'''
def extract_stack(lines):
"in traceback_helper module "
header = lines[0]
stack = []
for line in lines:
m =frame_pattern.match(line)
if not m:
continue
frame = (m.group('path'), m.group('function'))
stack.append(frame)
# [Convert to tuple and return after finished building stack.]
return (header, stack)
[...]
def main(args):
crashes = {}
[...]
for line in open(log_file):
if does_not_look_like_a_stack_dump(line):
continue
lines = traceback_helper.unfold(line)
header, stack = traceback_helper.extract_stack(lines)
signature = tuple(stack)
if signature in crashes:
count, header = crashes[signature]
crashes[signature] = (count + 1, header)
else:

crashes[signature] = (1, header)
'''

Seems to me that Steven is suggesting that stack (after being built)
should converted to a tuple before being returned, because a "stack"
for any unique exception should be unique and immutable. You do this
anyway; you just do it before putting it into a dictionary rather
than before returning it.

Same net effect (as long as you do not modify `stack` later), so no
real argument.


~Ramit


This email is confidential and subject to importantdisclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
 
Reply With Quote
 
 
 
 
Roy Smith
Guest
Posts: n/a
 
      11-20-2012
In article <50aac3d8$0$29983$c3e8da3$(E-Mail Removed) om>,
Steven D'Aprano <(E-Mail Removed)> wrote:

> By the way, your news client seems to be mangling long URLs, by splitting
> them when they exceed the maximum line length.


Hmmm. So it did. My bad.
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      11-20-2012
In article <50aac66c$0$29983$c3e8da3$(E-Mail Removed) om>,
Steven D'Aprano <(E-Mail Removed)> wrote:

> I'm asking about the case where one might want the key to remain mutable
> even after it is used as a key, but can't because Python won't let you.


Ah. Now I see what you're getting at. Thank you.

Well, I will admit that it probably doesn't make sense to mutate an
object after it's put into a dict (or at least mutate it in a way which
changes it's hash value and/or whether it compares equal to the original
object). If you did (assuming lists were allowed as keys):

l = [1, 2, 3]
d = {l: "spam"}
l.append(4)
print d[l]

I'm not sure what I would expect to print. It's not too hard to
experiment, though. All you need do is:

class HashableList(list):
def __hash__(self):
return hash(tuple(self))

and python is then happy to let you use a list as a key. I just played
around with this a bit off-line. I think I got the results I was
expecting, but since I'm not sure what I was expecting, that's hard to
say.

However, you didn't ask if it made sense to mutate an object after using
it as a key. You asked if it made sense to let the object remain
mutable after using it as a key. That's a harder question.

Let's say I had lots of of lists I wanted to use a dictionary keys. As
it stands now, I have to convert them to tuples, which means copying all
the data. For a lot of data, that's inefficient.

Wouldn't it be nice (or at least, more efficient) if I could just use
the original lists as keys directly, without the extra copy? I would
have to understand that even though they are mutable, interesting (and
perhaps, unwanted) things if I actually mutated them. But, we're all
consenting adults here. If I'm willing to accept responsibility for the
consequences of my actions in return for the efficiency gain, why
shouldn't I be allowed to?

I guess the answer is, that I am allowed to. I just need to do the
HashableList deal, shown above (no broken URL required to read the code).
 
Reply With Quote
 
elisha.java@gmail.com
Guest
Posts: n/a
 
      09-23-2013
On Tuesday, October 30, 2007 12:24:04 PM UTC-7, Tim Chase wrote:
> > I have used Python for a couple of projects last year and
> > I found it extremely useful. I could write two middle size
> > projects in 2-3 months (part time). Right now I am a bit
> > rusty and trying to catch up again with Python.
> >
> > I am now appearing for Job Interviews these days and I am
> > wondering if anybody of you appeared for a Python
> > Interview. Can you please share the questions you were
> > asked. That will be great help to me.

>
> While I haven't interviewed precisely for Python, I've been
> on the other (interviewing) end and can offer a few of the
> sorts of things I ask. I don't expect perfect answers to
> all of them, but they show me a range of what the
> interviewee knows. I try and give a scattershot of
> questions from the following areas to try and narrow down
> where they fall in terms of pythonability, and then grill
> more deeply around the edges that I find.
>
> Basic Python:
> =============
> - do they know a tuple/list/dict when they see it?
>
> - when to use list vs. tuple vs. dict. vs. set
>
> - can they use list comprehensions (and know when not to
> abuse them?
>
> - can they use tuple unpacking for assignment?
>
> - string building...do they use "+=" or do they build a list
> and use .join() to recombine them efficiently
>
> - truth-value testing questions and observations (do they
> write "if x == True" or do they just write "if x")
>
> - basic file-processing (iterating over a file's lines)
>
> - basic understanding of exception handling
>
> Broader Basic Python:
> =====================
> - questions about the standard library ("do you know if
> there's a standard library for doing X?", or "in which
> library would you find [common functionality Y]?") Most
> of these are related to the more common libraries such as
> os/os.path/sys/re/itertools
>
> - questions about iterators/generators
>
> - questions about map/reduce/sum/etc family of functions
>
> - questions about "special" methods (__<foo>__)
>
> More Advanced Python:
> =====================
> - can they manipulate functions as first-class objects
> (Python makes it easy, but do they know how)
>
> - more detailed questions about the std. libraries (such as
> datetime/email/csv/zipfile/networking/optparse/unittest)
>
> - questions about testing (unittests/doctests)
>
> - questions about docstrings vs. comments, and the "Why" of
> them
>
> - more detailed questions about regular expressions
>
> - questions about mutability
>
> - keyword/list parameters and unpacked kwd args
>
> - questions about popular 3rd-party toolkits (BeautifulSoup,
> pyparsing...mostly if they know about them and when to use
> them, not so much about implementation details)
>
> - questions about monkey-patching
>
> - questions about PDB
>
> - questions about properties vs. getters/setters
>
> - questions about classmethods
>
> - questions about scope/name-resolution
>
> - use of lambda
>
> Python History:
> ===============
> - decorators added in which version?
>
> - "batteries included" SQL-capible DB in which version?
>
> - the difference between "class Foo" and "class Foo(object)"
>
> - questions from "import this" about pythonic code
>
> Python Resources:
> =================
> - what do they know about various Python web frameworks
> (knowing a few names is usually good enough, though
> knowledge about the frameworks is a nice plus) such as
> Django, TurboGears, Zope, etc.
>
> - what do they know about various Python GUI frameworks and
> the pros/cons of them (tkinter, wx, pykde, etc)
>
> - where do they go with Python related questions (c.l.p,
> google, google-groups, etc)
>
> Other Process-releated things:
> ==============================
> - do they use revision control
> (RCS/CVS/Subversion/Mercurial/Git...anything but VSS) and
> know how to use it well
>
> - do they write automated tests for their code
>
> Touchy-feely things:
> ====================
> - tabs vs. spaces, and their reasoning
>
> - reason for choosing Python
>
> - choice of editor/IDE
>
> Good luck with your interviewing and hope this helped,
>
> -tkc


I appreciate all these. I thought I knew Python!
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      09-23-2013
Somebody, whose identity has been lost in three-deep quoting, said:
> > > I am now appearing for Job Interviews these days and I am
> > > wondering if anybody of you appeared for a Python
> > > Interview. Can you please share the questions you were
> > > asked. That will be great help to me.


We have a standard list of about 2 dozen screening questions we use that
cover a broad but shallow swath of CS, Unix, and Python. I'm not going
to share the exact questions, but here's some of the Python topics we
cover:

The ramifications of string immutability.

How default function arguments work, especially how they interact with
mutable objects.

How booleans and various ways of testing for equality work.

A question about subclassing a built-in type.

List comprehensions vs. generator expressions.

We don't expect everybody to get every question, but it gives us a quick
first cut to evaluate applicants before we decide to bring them in for
an interview or not.

We also want to see that you understand some basic computer science. If
nothing else, you need to understand, what O(n) means, and be able to
give some examples of Python code which exhibit various orders of
complexity.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Please come and add questions to C++ interview questions onListenVoice Vijay C++ 2 05-07-2010 03:02 PM
Re: Anyone read "Python Interview Questions: Python CertificationReview"? Steve Holden Python 0 03-04-2009 02:44 PM
Re: Anyone read "Python Interview Questions: Python CertificationReview"? Tim Chase Python 0 03-04-2009 01:45 PM
ASP Interview Questions ASP Interview Questions reema ASP General 0 08-26-2008 11:57 AM
.NET Interview Question, C#, ASP.NET Interview Questions dotnetuncle Javascript 0 10-30-2007 03:08 PM



Advertisments