Verbosity in lesson notebooks


#1

While I realize it would be way too verbose for day to day programming I think it would be very helpful to students who are new to numpy, keras, etc. if the notebooks didn’t rely so heavily on import aliases.

If I see a reference to get_file() in a notebook cell I have to expend time/mental energy to find where it comes from. I would much rather see:

keras.utils.data_utils.get_file(...)

(and yes, I am aware of the built-in help notebooks provide for method information, etc.; my suggestion still stands)


#2

I second this


(Jeremy Howard) #3

Just type get_file in a cell and hit shift-enter, and it will tell you where it comes from :slight_smile:


(Jeremy Howard) #5

OK Reed. Sorry to have bothered you. I appreciate your feedback.


#7

I don’t really think its really that big of an issue though.
Its still a course, and most of the time, I used the notebooks as a guideline instead of a library.
name spacing would just make it a little easier , maybe about 5%
Whats more important is to learn the concepts so that you can create your own DL models and the workflows that go with them(which are extremely good. nowhere else will you find jeremy’s tips and tricks that can greatly improve output)

@jeremy you didnt bother anybody. I kinda feel bad now :frowning:


#9

you could refactor the libraries into correct namespaces and submit a version that looks better. Maybe jeremy will even accept the changes upstream


(Even Oldridge) #11

@Reed I think part of the pushback you’re feeling may be coming from your attitude. @jeremy was trying to be helpful too and your whole conversation is very defensive and framed as if he attacked you which isn’t the case.

I do agree with your argument that the dependency on import aliases is possibly confusing to brand new students, but it’s also common coding practice which they’re going to have to learn as the vast majority of examples they’re going to encounter are going to be written in this way.

The title of the course is Practical Deep learning for Coders. In that context I think Jeremy’s approach of presenting code as it would commonly be written is the better method. As you code in this way it’s possible that early on you build up an underlying understanding a little more slowly, but you’re able to code (and read other’s code) much more quickly and efficiently once you understand the common package aliases so I’d question that there’s any real impediment to learning from code examples like those presented in the course.