C
Chris Angelico
Huh. And then I scroll down, and that's precisely what he's doing. Do
you understand why this is a bad thing to do?
ChrisA
Huh. And then I scroll down, and that's precisely what he's doing. Do
you understand why this is a bad thing to do?
ChrisA
I
Ian Kelly
The 'item' parameter, though, is probably not a constant, and it's
interpolated just the same.
The lack of an ORDER BY is the least of the problems with that SQL.
He's also using LIMIT without OFFSET, so the only thing that the
'item' argument changes is how many rows are returned (all but one of
which are ignored), not which one is actually fetched.
It's a bit sad that these are touted as answers to interview
questions. I wouldn't hire anybody who gave answers like these.
C
Chris Angelico
No, he's using the two-arg form of LIMIT.
The code does not work as posted; there are args missing from the
INSERT example, for, uhh, example. It makes it hard to evaluate the
quality of the code, in some places. I'm not sure what these posts are
supposed to be, but I hope they're not being held up as model answers
to interview questions. For a start, I can't find any sort of clear
questions.
Or is the code itself the question and "How would you improve this"?
ChrisA
D
Dave Angel
Skip ahead to about page 13 to get more traditional questions, There,
many of the simplest questions have invalid answers, or confusing
explanations.
For example, on page 15, the question that says " ... if a list of words
is empty..." uses a="" as its source data to test with.
The first question on page 16 forgets to construct a loop, thus
processing only the first line in the file.
page 18 introduces new syntax to the language:
print n+=1 ##will work
and reassures us in the comment that it will work !!
page 18 also claims that values are passed to function by value.
R
Roy Smith
I was going to comment on some of the specific items, but I got hung up
being unable to copy-paste text from your site so I could quote it.
That's usually done with some variation on "user-select: none" in the
CSS, but I didn't see that. I'm assuming it's some javascript trickery.
Why do you do that? It degrades the usability of the site, and doesn't
provide any real protection against people stealing content.
R
Roy Smith
Ian Kelly said:
Over time, I've become convinced that most interview questions are crap.
The best programming interview questions always start with, "write a
program ...".
R
Roy Smith
Ian Kelly said:My mistake. I didn't even know there was a two-arg form of LIMIT.
Must be a MySQL thing.
What are you talking about? SQL is an ISO Standard. Therefore, all
implementations work the same way. Didn't you get the memo?
C
Chris Angelico
My mistake. I didn't even know there was a two-arg form of LIMIT.
Must be a MySQL thing.
Yeah, it's not something I've used, but when my current job started,
we were using MySQL and I used to eyeball the logs to see what queries
were performing most suboptimally. (There were some pretty egregious
ones. Most memorable was rewriting a TEXT field several times a second
with several KB of PHP serialized array with status/statistical
information. Structured information, yes. Stored as a clob.) My first
databasing experience was DB2, with the uber-verbose "FETCH FIRST n
ROW
Everyone who wants to use LIMIT without ORDER BY should try their code
on Postgres. You'll quickly discover the problem.
ChrisA
K
Kushal Kumaran
Since your website's Terms of Use state that you own the content, it
is your problem to make sure whatever's there is there legally.
Here's one example, though, to get you started: See the entry "Why
can’t I use an assignment in an expression?" at
http://docs.python.org/faq/design.html, and compare with the content
under the identical heading on page 3 of the CorePython section.
M
MRAB
The section below it comes from here:
http://svn.effbot.org/public/stuff/...help-find-bugs-or-perform-static-analysis.xml
C
chinjannisha
Hi I had one doubt.. I know very little bit of python .I wanted to know when to use list,tuple,dictionary and set? Please reply me asap
thanks
thanks
D
Dennis Lee Bieber
They are used when they are appropriate to the algorithm being
coded.
S
Steven D'Aprano
Use a list when you want a list of items that should all be treated the
same way:
list_of_numbers = [1, 3, 5.1, 2, 6.5]
total = sum(list_of_numbers)
or when you need a collection of items where the order they are in is
important:
winners = ['george', 'susan', 'henry'] # 1st, 2nd, 3rd place
print('The winner is:', winners[0])
Use a tuple when you want a collection of items that mean different
things, a bit like a C struct or Pascal record:
a = (23, "henry", True, 'engineer')
b = (42, "natalie", False, 'manager')
c = (17, "george", True, 'student')
Use a dict when you need a collection of key:value mappings:
config = {'name': 'fred', 'pagesize': 'A4', 'verbose': True, 'size': 18}
address = {'fred': '(e-mail address removed)', 'sally': '(e-mail address removed)'}
if config['verbose']:
print('sending email...')
send_email_to(address['fred'], "Subject: Hello")
Use a set when you want to represent a collection of items and the order
is not important:
failed = {'fred', 'tom', 'sally'} # set literal syntax in Python 3 only
# use set(['fred', 'tom', 'sally']) in Python 2
if 'george' in failed:
print('George, you have failed!')
R
Roy Smith
Steven D'Aprano said:
That is certainly the right answer according to the One True Church Of
Pythonic Orthodoxy And Theoretical Correctness. But, let me give an
alternative answer which works for The Unwashed Masses Who Live In The
Trenches And Write Python Code For A Living:
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).
S
Steven D'Aprano
Oh I'm sorry, did something I say suggest that the couple of examples I
gave are the *only* acceptable uses? My apologies for not giving an
exhaustive list of every possible use of lists and tuples, I'll be sure
to punish myself severely for the lapse.
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.
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.
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).
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.
D
D'Arcy J.M. Cain
Well, as long as *you* never needed it then...
CellBlock = 9 # There's a riot going on...
Cell = 17
Bunk = "top"
Prisoner = {(CellBlock, Cell, Bunk): "Bernie Madoff"}
R
Roy Smith
Steven D'Aprano said:
Hmmm. I didn't mean any offense. I was just pointing out that what's
true in theory and what's true in practice aren't always the same.
I've got a script which trolls our log files looking for python stack
dumps. For each dump it finds, it computes a signature (basically, a
call sequence which led to the exception) and uses this signature as a
dictionary key. Here's the relevant code (abstracted slightly for
readability):
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)
You can find traceback_helper at
https://bitbucket.org/roysmith/python-tools/src/4f8118d175ed/logs/traceba
ck_helper.py
The stack that's returned is a list. It's inherently a list, per the
classic definition:
* It's variable length. Different stacks have different depths.
* It's homogeneous. There's nothing particularly significant about each
entry other than it's the next one in the stack.
* It's mutable. I can build it up one item at a time as I discover them.
* It's ordered. f1(f2()) is not the same as f2(f1()).
But, to use it as a dictionary key, I need to make it into a tuple,
since keys have to be immutable.
C
Chris Angelico
That's a structure, not a list. Every key will consist of precisely
three values: two integers and one keyword string. Already covered by
a previous example.
ChrisA
S
Steven D'Aprano
Er, no, it's inherently a blob of multiple text lines. Sure, you've built
it a line at a time by using a list, but I've already covered that case.
Once you've identified a stack, you never append to it, sort it, delete
lines in the middle of it... none of these list operations are meaningful
for a Python stack trace. The stack becomes a fixed string, and not just
because you use it as a dict key, but because inherently it counts as a
single, immutable blob of lines.
A tuple of individual lines is one reasonable data structure for a blob
of lines. Another would be a single string:
signature = '\n'.join(stack)
Depending on what you plan to do with the signatures, one or the other
implementation might be better. I'm sure that there are other data
structures as well.
Once complete, the stack trace is fixed length, but that fixed length is
different from one stack to the next. Deleting a line would make it
incomplete, and adding a line would make it invalid.
The complete stack trace is inhomogeneous and immutable. I've already
covered immutability above: removing, adding or moving lines will
invalidate the stack trace. Inhomogeneity comes from the structure of a
stack trace. The mere fact that each line is a string does not mean that
any two lines are equivalent. Different lines represent different things.
Traceback (most recent call last):
File "./prattle.py", line 873, in select
selection = self.do_callback(cb, response)
File "./prattle.py", line 787, in do_callback
raise callback
ValueError: what do you mean?
is a valid stack. But:
Traceback (most recent call last):
raise callback
selection = self.do_callback(cb, response)
File "./prattle.py", line 787, in do_callback
ValueError: what do you mean?
File "./prattle.py", line 873, in select
is not. A stack trace has structure. The equivalent here is the
difference between:
ages = [23, 42, 19, 67, # age, age, age, age
17, 94, 32, 51, # ...
]
values = [23, 1972, 1, 34500, # age, year, number of children, income
35, 1985, 0, 67900, # age, year, number of children, income
]
A stack trace is closer to the second example than the first: each item
may be the same type, but the items don't represent the same *kind of
thing*.
You could make a stack trace homogeneous with a little work:
- drop the Traceback line and the final exception line;
- parse the File lines to extract the useful fields;
- combine them with the source code.
Now you have a blob of homogeneous records, here shown as lines of text
with ! as field separator:
../prattle.py ! 873 ! select ! selection = self.do_callback(cb, response)
../prattle.py ! 787 ! do_callback ! raise callback
But there's really nothing you can do about the immutability. There isn't
any meaningful reason why you might want to take a complete stack trace
and add or delete lines from it.
R
Roy Smith
Er, no, it's inherently a blob of multiple text lines.[/QUOTE]
No, it's a list that looks like (taken from the doc string of the code I
referenced):
[('/usr/lib/.../base.py', 'get_response'),
('/home/songza/.../views.py', 'song_info'),
('/home/songza.../api.py', 'get_song'),
('/home/songza/.../api.py', 'api')]
[it doesn't really have ...'s in the paths; I just elided some text to
make it easier to read]
No. Each entry in the list represents a source file and a function
name. They're all the same "shape". You could remove one or add
another one, or shuffle the order, and you would have something which
was syntactically correct and semantically meaningful (even if it didn't
represent an actual code path.
You mean, kind of like the code I cited does?
I think we're going to have to let this be. You obviously have your
concept of what a tuple is and what a list is. I disagree. I don't
think either of us is right or wrong, we just have different ways of
thinking about things.
You come at it from a theoretical point of view. You think of each type
as an embodiment of certain concepts ("it represents a fixed-length
heterogenous sequence"). Your thinking is driven by what each type was
intended to be used for.
I come at it from a practical point of view. To me, each type is a
collection of methods. I have certain operations I need to perform. I
pick the type which offers those operations. If the set of operations I
need to perform (in this case, {append, hash}) don't exist in a single
type, I'm forced to use both types and convert from one to the other as
needed.
The theorist understands that a chisel and a screwdriver were intended
for different purposes, but the pragmatist gets the paint can open.