Data Structures Notes Feedback

[cooper-mj]

Another set of awesome notes - really well done!! As in my other feedback documents, the feedback in roughly chronological order, and line numbers referenced for convenience.

• Line 4: This statement feels a bit abrupt and out of place - perhaps add a bit more to it so that it signposts the flow of the notes. E.g. "We'll start by covering the common data structures in Python: we'll take a look at lists, tuples, and sets, all of which store collections of objects, and dictionaries, which store mappings between objects. Then, we'll look into constructing data structures through comprehensions, and at advanced looping techniques." (If it signposts the full set of notes, then it reads more purposefully and seems more complete).
• Line 15: Here, perhaps spell out explicitly that we can have lists within lists.
• Line 22: Not so much a critique as a flag for future - once the notes are hosted on our site, we'll need to make sure to link to the correct page on stanfordpython.com.
• Line 27: Could be nice to add len(mixed) here as well.
• Line 37: This section seems as though it requires a bit more rigorous treatment of the list function. What constraints, for example, are there on constructing lists from objects? How would it behave if I passed an int vs. a string vs. a dict? A slightly more detailed overview of the way that list behaves on different data types, and a couple more examples, could make this section clearer.
• Line 45: This is fantastic - I love this table and your subdivision of these functions.
• Line 45(ish): Perhaps spell out explicitly that since lists are mutable these are in-place operations.
• Line 52/61: It's peculiar that on Line 61 you mention that .sort returns None, while you don't make the same mention for .append which also returns None. I haven't verified this, but I'm going to guess that all of these functions actually return None, in which case you can make this note at the top before you delve into describing the individual functions.
• Line 61: Might be worth explaining that the .sort function requires objects of the same type (raises a TypeError otherwise), and going through how .sort sorts elements of different types (numbers is obvious, but an example showing sorting strings alphanumerically, for example, could be a useful addition).
• Line 138: Small grammatical nit: "just as with lists", or "just like with lists".
• Line 170: Unicornelius is 1001?! Why didn't I get to attend its 1000th birthday party?
• Line 203: This is very well phrased, and there's nothing wrong with it, but there's a little bit of unpacking work that needs to take place on the part of the student here. I might lightly suggest a picture - almost like what you did with the baggage tag - explaining why it's permitted to modify a list within a tuple, but why it's not permitted to change an integer within a tuple.
• Line 216: Before we move on to sets, we covered the list() function, and we will cover the set() function, but we don't cover the tuple() function. Is there a reason for this?
• Line 230: Contrast this with the O(N) for membership testing in lists and tuples.
• Line 231: Might be fun to note this is an O(N) way to eliminate duplicates? (I've seen that interview question twice in my experience so... might be a handy note). 😊
• Line 289: This section is clear, concise, and great. Fantastic job.
• Line 325: Since we're not assuming CS103 (or any familiarity with sets), it would be useful to (briefly) define here what a subset means in the context of set theory.
• Line 378: We've treated all other instances of collections with a high degree of specificity, so this one reads as vague. One comment: I believe it's worthwhile here to specify that d.keys() returns a dict_keys object, d.values() returns a dict_values, and d.items() returns a dict_items object, for completeness and specificity. And one question: to the best of your knowledge, why... a dict_keys/dict_values object (I understand the usefulness of dict_items for looping)? Are those types useful for anything other than casting to a different type of collection?
• Line 413: Typo.

A list comprehension looks has the following syntax

• Line 425: An example of a set comprehension would be great here. Also, explicitly defining the syntax of the dict comprehension would be helpful - e.g. showing that students can do something with this syntax (fn(key, value) for key in collection) in addition to this syntax from the example (fn(key, value) for key, value in collection).
• Line 439: I'm not sure we go into enough detail here about comprehensions (specifically list comprehensions), since this is the only place many students will see them rigorously treated before we blitz through them as a review in FP. Unless there's somewhere else we cover this, we should cover the conditional component of list comprehensions too.
• Line 447: I'd make the same comment here about typing as I made on Line 378; it might be worth explaining that this is a unique type, rather than just a collection?
• Line 461: Let's add a bit more detail about edge cases - e.g. how zip behaves when the two collections aren't of the same size.
• Line 483: Typo "then".