Besides Blocks: Data Structures Review

[cycomachead]

Lab Content: http://beautyjoy.github.io/bjc-r/llab/html/topic.html?topic=berkeley_bjc%2Fpython%2Fbesides-blocks-data-struct.topic&novideo=true&noreading=true&noassignment=true&course=cs10_fa14.html

For each item that needs fixing please add - [ ] to the beginning of the line.

[cycomachead]

Page 1: http://beautyjoy.github.io/bjc-r/cur/programming/python/lists_intro.html?topic=berkeley_bjc/python/besides-blocks-data-struct.topic&step=1&novideo=true&noreading=true&noassignment=true&course=cs10_fa14.html

• [x] No blue thing for the first line
• [ ] Snap! blocks are too big
• [x] ':' should be inside a <code>

Page 2: http://beautyjoy.github.io/bjc-r/cur/programming/python/list_mutability.html?topic=berkeley_bjc%2Fpython%2Fbesides-blocks-data-struct.topic&novideo=true&noreading=true&noassignment=true&course=cs10_fa14.html&step=2

• [x] Lots of python's that need to be capitalized
• [x] Mutability needs to be bolded the first time
• [x] The section on mutability needs to make references to Snap! and explain why this matters
• [x] stray character at the end of the copy example
• [x] The operator (again) needs to be inside a <code> block
• [x] The operator should be explained. (About it iterating through the list)
• [ ] Now would be a great time for a rant on readability and code golf, and the more appropriate .copy() method. https://docs.python.org/3.4/library/copy.html
• [ ] there should be a comparison to Snap! with the names list being shown in Snap!. (The beatles list should obviously be modified, but the names one isn't clear)
• [ ] Should mention for students to write a copy block in Snap! (like we provided for HW2 and HW3)
• [x] No "[]" are the Note... Also the joke needs to be made more clear..."closed course" doesn't make sense. A ;-) would probably help....

Ok, I don't have time for any more comments.... :/

[jacburge]

• [x] Typo on Introduction to Python Lists page, "Baisc List Operations"

[jacburge]

• [x] Typo on Abstract Differences Between Lists and Dictionaries page: "differnece" (last word) - Awesome diagram on this page btw.

[jacburge]

• [x] Typo on 2D Dictionaries in Python page: "congratualtions" at the end

[jasnowiss]

+1 for Michael's mutability comment on page 2 "there should be a comparison to Snap! with the names list being shown in Snap!. (The beatles list should obviously be modified, but the names one isn't clear)" Snap mutability for lists works the same as for Python.

HOFs in Python page: http://beautyjoy.github.io/bjc-r/cur/programming/python/python_hofs_comprehensions.html?topic=berkeley_bjc%2Fpython%2Fbesides-blocks-data-struct.topic&novideo=true&noreading=true&noassignment=true&course=cs10_fa14.html&step=6

• [x] I really like the idea of using the for loop syntactic sugar to represent map and keep! I also really like how you guys substituted functions in with [function(x) for x in my_list]. Can you include a description that functions can be used for keep as well? [x for x in my_list if function(x)] Also typos at the bottom for Exercise 3.2 ("Substitue Sequences" in the title and in the code screenshot).

General thoughts: Is there a way to have the full functionality of combine without importing reduce? That would be awesome to never have them import map, filter, or reduce, or have them deal with lambdas!

Overall, great job guys!

[jasnowiss]

Actually though, should map, filter, reduce, and lambdas be mentioned in some small degree at some point since I think 61a teaches them? I'm not saying in this lab, but maybe at some point?

[cycomachead]

Actually though, should map, filter, reduce, and lambdas be mentioned in some small degree at some point since I think 61a teaches them? I'm not saying in this lab, but maybe at some point?

I do think so, also because the list comprehensions are not a HOF. Furthermore, list comprehensions have side effects isn't really a BJC way of doing things. We should leave them in for now, but there should very much be map filter and reduce in the lab in the future. (Also because these functions are common mappings to so many other environments.

https://docs.python.org/3.4/tutorial/datastructures.html

In the future, I'd really like to see lambdas in this lab (or some other intro lab) as well.

[cycomachead]

Can you include a description that functions can be used for keep as well? [x for x in my_list if function(x)]

+1

Also, we're missing combine entirely... :/

[aaaschmitt]

I wrote a page on combine....."trying to combine" I mention reduce and say it isn't worth knowing (it's not even standard library anymore in python 3.4). Exercise 4 has them write their own combine for strings and numbers.

[aaaschmitt]

This lab is already really heavy....I would not have put lambdas here. We decided not to fully discuss mutability in snap. It could be added I suppose, but the hope was to not have too detailed of discussions as much of the work is really in the exercises.

[cycomachead]

New iterators page (since I just looked at it):

• [x] Typos in the Hello example. The proper way needs a comma after the word Hello. → "Hello, " + name. (True of the join in Snap! as well).
• [x] The range function as an iterator should really be a compared to a "make list" block from x to y. Then that list should be used in the Snap! for each block. (The difference is that technically range is a lazy list, but those are also in Snap! too. :))

As far as combine: It says "We won't be talking about it here..." which is weird though. I think it's worth showing examples because there's a huge difference between syntactic sugar which involves calling a function, but not calling it in the other examples.

I wasn't advocating for lambdas in this lab necessarily, but at some point. They are one of the main topics of BJC so it'd be nice to have them.

As far as mutability...my main concern is that the comparison to Snap! doesn't seem complete. The point should be that, to a large extent, they already understand mutability and immutability. I think some notes / a few more sentences would help. That's all. (Also the graphic itself is confusing, because it doesn't illustrate the problem of mutable data.) (Which is also another reason for map, IMO.)

Not all of these really need to be fixed this week...

[cycomachead]

In general, I don't think we should ever say that something isn't worth knowing. If we really do think combine isn't worth it, then it just shouldn't be taught, except for a footnote.

In some ways, it's all about style, I guess. I think my only real problem with the different formats is that it's not clear about when things are functions.

[cycomachead]

• [x] Flatten Exercise: Should be clear that we are discussing only 2D lists, and not N-D lists (which is also a good exercise...)

[aaaschmitt]

I strongly disagree with a lot of your higher level comments on combine and HOFs in python, Michael. We should talk about this in person sometime. Map, Filter, and Reduce are snap-like, but they are VERY un-pythonic. We are teaching Python here, not snap in Python.

[cycomachead]

It's not about "Snap"...it's what BJC is. And I don't really have a problem with "pythonic" (though, personally I find this idea rather annoying since the docs list the map solution as "equivalent"). I do agree we should teach something practical.

I guess I don't necessarily mind the list comprehensions version, but I still don't like trivializing the use of reduce that way. I also really think the idea of when you are calling vs passing a function should be clear, especially if we are mentioning reduce.

I don't really like the reasoning in this post, but this is the reason there's no reduce... I think sum, any, and all are probably worth mentioning since they are fairly common operations. (Interestingly, product is not defined in Python 3, and string concatenation is still weird. But I think these are relatively minor details not worth mentioning.)

I think the 61A lab section on sequences does an interesting job of promoting common Python syntax but keeping the traditional ideas of function programming. (I also like the function name apply_all since it's better than map.)

http://cs61a.org/lab/lab04/#sequences

Their idea of reduce is not bad, though requiring an initial value seems weird. http://cs61a.org/lab/lab04/lab04.py More equivalent would probably be:

def reduce(reduce_fn, s):
    reduced = s[0]
    for x in s[1:]:
        reduced = reduce_fn(reduced, x)
    return reduced

Aside: My main issue with list comprehension in Python, and this applies somewhat to Snap! as well, is that there's a tendency to try to nest too many levels which I've seen happen often in 61A. We probably don't need to worry about this in our labs though. I just really feel like it's worth trying to explicitly encourage readable paradigms which Python doesn't always do. Though the docs do a nice job of laying things out: https://docs.python.org/3.4/tutorial/datastructures.html#nested-list-comprehensions and simple (1 or 2 level) comprehensions aren't that bad.

[aaaschmitt]

Yes that is a good reduce function, but it still requires the concept of lambdas pretty much (just function passing in general in Python), which, as I have said, we decided to stay away from since this lab is already pretty full. This lab is about data structures not functions as data. By using list comprehensions as a comparison to map and keep we get around having to worry about function passing. It's impossible for us to teach all of 61a, so we thought it was best to just give them a strong fundamental understanding of Python data structures. They can worry about the intricacies of function passing when they get to 61a.

[cycomachead]

I don't think it should be in this lab, but the built in reduce function also requires functions as data. It's weird to me that we mention reduce and then just write a loop to combine things... I also very much think that we need lambdas / HOFs in our Python curriculum at some point.

• [x] Append page has no title: https://inst.eecs.berkeley.edu/~cs10/labs/cur/programming/python/list_functions.html?topic=berkeley_bjc%2Fpython%2Fbesides-blocks-data-struct.topic&novideo=true&noreading=true&noassignment=true&course=cs10_fa14.html&step=3

Edit: To clarify: "it" referred to Lambdas not reduce. The idea of reduce should be there.

[aaaschmitt]

That's the point................sighhhhh

Reduce is difficult to use, but I felt it should be mentioned since it is the only direct parallel to snap's combine. Then we explain that the most straightforward way to combine (as suggested by the python documentation) is to use a for loop.

Quote from the python 3.0 release: "Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable." --> this is what is taught in the lab

Students will struggle with this lab a lot. Lamdas should not be in this lab.

[cycomachead]

Lamdas should not be in this lab.

The must be in our Python curriculum somewhere though...I agree this lab is long though. Again, we can't fix that for this semester but sometime they really do need to be discussed.

Reduce is difficult to use,

I don't really agree with this, other than the need to understand the equivalent of passing a function in Python, which is actually fairly simple. (See previous point).

"Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable."

Except..the solutions are completely not more readable in this case. (Also why there are sum and join functions...)

The common cases for reduce are implemented as builtins in Python, with the exception of product.

[cycomachead]

That's the point................sighhhhh

By the way, I meant lambda not reduce.