Merge pull request #5 from hclivess/master

review of the whole class

transcripts/01-introduction/1.txt

@@ -23,11 +23,11 @@
 1:13 if you have a class and the class has a get value and set value,
 1:17 because in Java that is typically the way you do encapsulation,
 1:20 and people bring those classes in this code over and migrate it to Python,
-1:24 they might still have this weird getter setter type of code.
+1:24 they might still have this weird getter/setter type of code.
 1:28 And that would look completely bizzare in Python
 1:31 because we have properties for example.
 1:33 So we are going to look at this idea of Pythonic code,
-1:36 now it's pretty easy to understand but it turns out to be fairly hard to make concrete,
+1:36 now, it's pretty easy to understand but it turns out to be fairly hard to make concrete,
 1:40 you'll see a lot of blog posts and things of people trying to put structure
 1:44 or examples behind this concept of Pythonic code.
 1:48 We are going to go through over 50 examples of things I consider Pythonic

transcripts/01-introduction/2.txt

@@ -40,7 +40,7 @@
 2:04 is they are not using loops correctly,
 2:07 so we'll talk about when and how you should use loops
 2:10 and we'll even talk about the controversial else clause
-2:12 for for in and while loops.
+2:12 for "for...in" and "while" loops.
 2:14 Next, we'll talk about tuples.
 2:16 Tuples are smallish, read-only collections
 2:18 that let you package up related possibly heterogeneous data
@@ -59,10 +59,10 @@
 2:57 and add amazing powers to your application.
 3:00 People who are new to Python often skip this step
 3:03 and they look at something they have to do and are just like
-3:07 OK I think I can implement it in these 20 lines of code.
+3:07 OK I think "I can implement it in these 20 lines of code".
 3:10 It's very likely that there is already a package out there
 3:14 that you can use to do this,
-3:16 so we are going to study two packages one for http
+3:16 so we are going to study two packages one for HTTP
 3:18 and one for database access to really bring home this point of look to PyPi
 3:24 and look to open source first before you start writing your own algorithms.
 3:28 Of course, over time, we may add more topics than what are described here,

transcripts/01-introduction/4.txt

@@ -2,7 +2,7 @@
 0:02 Well this course assumes that you have some basic knowledge
 0:04 on how to create functions, classes, loops, those types of things,
 0:07 and we focus really on the best way to do those.
-0:10 So if you are brand new to Python,
-0:12 I recommend you check out my course
-0:14 Python Jumpstart By Building Ten Applications
-0:16 and you can find that at talkpython.fm/course.
+0:09 So if you are brand new to Python,
+0:11 I recommend you check out my course
+0:13 Python Jumpstart By Building Ten Applications
+0:14 and you can find that at talkpython.fm/course

transcripts/01-introduction/5.txt

@@ -3,7 +3,7 @@
 0:06 So, this course is built with Python 3 in mind.
 0:10 If you don't have Python 3 installed,
 0:12 you can get it for your operating system at python.org/downloads,
-0:15 or you can home brew or apt get install it.
+0:15 or you can "Homebrew" or "apt get install" it.
 0:17 That said, most of the topics will actually be quite similar
 0:21 between Python 2 and Python 3,
 0:23 so we'll talk about Python 2 whenever there are significant differences.
@@ -20,8 +20,8 @@
 1:02 a lot of the PyPi packages were not updated and so on,
 1:05 now if we look at today Python 3 has default as much more common
 1:08 than it has been but more importantly,
-1:12 if you look just four years into the future, not far at all,
-1:14 you will see that Python 2 is end of life,
+1:11 if you look just four years into the future, not far at all,
+1:14 you will see that Python 2 is "end of life",
 1:17 there will be no more support for Python 2 in less than four years.
 1:20 And that means, whoever has projects, written in Python 2
 1:23 have to not just start upgrading them,
@@ -36,4 +36,4 @@
 1:49 going forward it's all about Python 3."
 1:51 So, that's why this course itself is based on Python 3,
 1:54 even though like I said,
-1:56 differences are quite minor for the topics we are covering.
+1:55 differences are quite minor for the topics we are covering.

transcripts/02-PEP8/1.txt

@@ -32,7 +32,7 @@
 1:30 one of the very first official updates to the Python language
 1:34 was this thing called PEP 8 which is a style guide for Python.
 1:38 Mostly this talks about the actual structure of your code,
-1:41 like "you should use spaces not tabs", those types of things,
+1:41 like "you should use spaces, not tabs", those types of things,
 1:44 but it also has some guidance on patterns as well.
 1:47 We'll look at the few of the recommendations from PEP 8
-1:50 before we move on to the more design pattern style recommendations.
+1:50 before we move on to the more design/pattern/style recommendations.

transcripts/02-PEP8/2.txt

@@ -1,16 +1,16 @@
 0:01 The first PEP 8 recommendation that we are going to look at
 0:03 is around importing modules and packages.
-0:05 So let's switch over here to PyCharm and have a look at some not so great code.
+0:05 So let's switch over here to PyCharm and have a look at some not-so-great code.
 0:09 You can see on line seven here, we are importing collections,
 0:12 the recommendation from PEP 8 is that all module level imports
-0:16 should go at the top unless there is some sort of function level import
+0:16 should go at the top, unless there is some sort of function level import
 0:19 you are doing kind of unusual, conditional things.
 0:22 And notice there is a little squiggle under here,
-0:24 and that's actually PyCharm saying here is a PEP 8 violation,
-0:27 a module level import is not at the top of the file.
+0:24 and that's actually PyCharm saying "here is a PEP 8 violation,
+0:27 a module level import is not at the top of the file."
 0:29 So we can take this and put it at the top of the file, now everything is happy.
 0:34 So let's look at few other things we can do,
-0:37 we could say from os import change directory change flags and change owner.
+0:37 we could say "from os import change directory, change flags and change owner."
 0:44 This is a good way to import a bunch of items
 0:47 from os and not have to state their name,
 0:49 we could do this a different way, using what's called a wildcard import,
@@ -28,41 +28,41 @@
 1:25 So it's why it's always recommended to use this style of importing.
 1:28 You may wonder why this is gray in PyCharm,
 1:31 PyCharm is just trying to help us out saying
-1:33 here are some unused imports you can actually remove,
-1:35 but if I write something like c = chdir
+1:33 "here are some unused imports you can actually remove",
+1:35 but if I write something like "c = chdir",
 1:38 then that part will go away.
 1:40 But of course, because we are importing the same thing twice
 1:42 basically it's also saying, I'll move that.
-1:45 Here we go, so now it says you are using chdir change owner but not change flags,
-1:49 down below it's using change owner.
-1:52 All right, now change flags, if I do something with that, it also lights up.
+1:45 Here we go, so now it says "you are using change dir, change owner but not change flags",
+1:49 down below it's using "change owner".
+1:52 All right, now "change flags", if I do something with that, it also lights up.
 1:56 All right, so there was never a problem with that import,
 1:59 that was just PyCharm trying to tell us "hey, look out,
 2:01 you are actually not using that import."
 2:03 Another mistake that people make is they might say something like this,
-2:06 import collections os and let's say multiprocessing,
+2:06 "import collections, os" and let's say "multiprocessing",
 2:10 they may put multiple imports on a single line.
 2:14 That also works just fine, however, again,
 2:16 PEP 8 recommends that you put one import per line
 2:19 so it's very clear line by line what you depend on here,
-2:24 so we could fix this by saying, let me just put a no, something like that,
-2:28 and we could of course fix this, like so, import os, import multiprocessing.
+2:24 so we could fix this by saying, let me just put a "no:", something like that,
+2:28 and we could of course fix this, like so, "import os", "import multiprocessing".
 2:35 So this would be the recommended way to write what was on line four.
 2:39 So let's look at that import guidance a little more clearly.
 2:43 Here we have at the top two bad styles of imports,
-2:47 first line import sys os multiprocessing, on a single line;
-2:51 PEP 8 says do not import multiple modules on a single line,
-2:55 and avoid from module import star these wildcard imports
+2:47 first line: "import sys, os, multiprocessing", on a single line;
+2:51 PEP 8 says "do not import multiple modules on a single line",
+2:55 and avoid "from module import star", these wildcard imports
 2:59 because you may accidentally, unknowingly overwrite other imports.
 3:03 So we have our better set of imports,
-3:06 import sys, import os, import multiprocessing,
-3:09 and these of course are going to allow us to use module name.symbol name
-3:14 so os.path for example in this sort of namespace style,
+3:06 "import sys, import os, import multiprocessing",
+3:09 and these of course are going to allow us to use "module name.symbol" name
+3:14 so "os.path" for example, in this sort of namespace style,
 3:17 and that's really nice to know where the particular symbol
-3:21 that you are working with like path, where it came from.
+3:21 that you are working with, like "path", where it came from.
 3:23 If you don't want to use that namespace style,
-3:25 you can use the final import we have here, from os import path,
-3:29 change mod and change owner.
+3:25 you can use the final import we have here, "from os import path,
+3:29 change mod and change owner".
 3:31 PEP 8 also have some guidance on the order and grouping of your imports.
 3:36 It says the standard library imports should go at the top,
 3:39 related third party imports should go in a little section below that

transcripts/02-PEP8/3.txt

@@ -1,16 +1,16 @@
 0:01 Next up, code layout. Let's see what PEP 8 has to say about it.
 0:03 The most important part about code layout that PEP 8 talks about is indentation.
-0:08 So, imagine we have a method called some method,
+0:08 So, imagine we have a method called some_method(),
 0:12 it says that you should indent four spaces,
-0:14 and PyCharm of course as you've seen knows PEP 8
+0:14 and PyCharm of course, as you've seen, knows PEP 8
 0:17 and indents four spaces for us automatically, so: one, two, three, four, there we are.
-0:22 And, we can write something so we could define a variable, hit enter,
-0:25 like an if statement,
+0:22 And, we can write something so we could define a variable, hit Enter,
+0:25 like an "if" statement,
 0:28 so something like "if x is greater than two", enter;
 0:30 Python does not like us to use tabs,
 0:33 PEP 8 recommends we use spaces and every indent is four spaces,
 0:36 but it even looks like if I hit tab and delete tab and delete,
-0:39 hit tab back and forth it's actually four spaces
+0:39 hit tab, back and forth, it's actually four spaces
 0:42 and PyCharm just treats blocks of four spaces like tabs for us
 0:45 so that it's easier for us to work with.
 0:48 Next, PEP 8 also talks about spaces between methods and other statements,
@@ -25,7 +25,7 @@
 1:15 and use the blank line sparingly but to indicate a logical grouping;
 1:18 so you can see maybe we wanted to define x
 1:20 and later have this if statement, that would be fine,
-1:23 but if we go farther you can see hey PEP 8 warning too many blank lines, put that back.
+1:23 but if we go farther you can see "hey, PEP 8 warning, too many blank lines", put that back.
 1:28 Last thing that I'll highlight is around classes,
 1:31 so if we have a class called AClass here, you can see it has three methods,
 1:36 and just like functions, it should have two blank lines separated in it
@@ -46,7 +46,7 @@
 2:24 but you know, it's a guidance,
 2:26 basically try to avoid having super long lines
 2:29 but don't do so by changing your code structures so much that it becomes small,
-2:33 so for example don't like create all your variables to just be one character
+2:33 so for example don't, like, create all your variables to just be one character
 2:37 so that when you combine them in some expression they still fit on the line,
 2:41 you would be better off using the continuation,
-2:44 but the idea of not having really long lines of code that's a good idea.
+2:43 but the idea of not having really long lines of code that's a good idea.

transcripts/02-PEP8/4.txt

@@ -1,22 +1,22 @@
 0:01 Next, let's look at what PEP 8 says about documentation and docstrings.
 0:04 Here we have our some_method, method that I wrote,
 0:08 and I added three more parameters,
-0:10 if I come down here and I say some method,
+0:10 if I come down here and I say some_method,
 0:13 see there is sort of note help in the IntelliSense,
-0:16 and if I say look it up, PyCharm does a little work
+0:16 and if I say "look it up", PyCharm does a little work
 0:19 to say what the type hints would be if it could look at the types
 0:23 the way the function is written,
 0:25 but it doesn't tell me really what a1, a2 or a3 mean,
 0:28 or what the method itself does,
-0:30 and obviously it's poorly named so this doesn't help as well.
+0:30 and obviously it's poorly named, so this doesn't help as well.
 0:33 So what we should do is give it some docstrings,
 0:35 and docstrings are just a string by itself on the first line of the method,
-0:40 or module if you're documenting the module or class if you're documenting the class.
+0:40 or module, if you're documenting the module or class, if you're documenting the class.
 0:44 So we can just say triple quote
-0:46 and then I hit enter and PyCharm will actually look at the method and help us out,
+0:46 and then I hit Enter and PyCharm will actually look at the method and help us out,
 0:49 so it knows it returns a value
-0:52 and it knows it has three parameters called a1, a2 and a3,
-0:54 so when I hit enter, I get the sort of structured way of documenting my method
+0:51 and it knows it has three parameters called a1, a2 and a3,
+0:54 so when I hit Enter, I get the sort of structured way of documenting my method
 0:59 so we'll say something like "some_method returns a larger of one or two",
 1:03 which is not actually what it even returns,
 1:06 it's just a silly method I threw in there to talk about spaces,

transcripts/02-PEP8/5.txt

@@ -3,27 +3,27 @@
 0:05 your functions, methods, classes, and other symbols in your code.
 0:08 Before we get to the specifics,
 0:11 I just want to give you one of my core programming guidelines around naming,
-0:14 and that is names should be descriptive.
+0:14 and that is: Names should be descriptive.
 0:17 Let's imagine you are writing a function.
 0:19 If you write the function and then you start to  put a comment
 0:22 at the top to describe what that function does,
 0:24 I encourage you to stop and think about just making the concise statement
 0:29 about what that comment is the name of the function.
 0:32 I am a big fan of Martin Fowler's reafctoring ideas
-0:35 and especially the code smells that he talks about,
-0:38 and code smells are things in code that are not really broken
+0:35 and especially the "code smells" that he talks about,
+0:38 and "code smells" are things in code that are not really broken
 0:41 but they kind of smell off, like a function that is 200 lines long,
 0:47 it's not broken, it just doesn't seem right.
 0:50 It sort of smells wrong, right, so breaking that
 0:53 to a smaller bunch of functions through refactoring might be the solution.
 0:57 And when he talks about comments he says
 0:59 comments are deodorant for code smell,
 1:01 instead of actually fixing the code
-1:04 so it's remarkably descriptive and easy to understand,
-1:06 people often put comments to say here is this really hard to understand thing,
+1:03 so it's remarkably descriptive and easy to understand,
+1:06 people often put comments to say "here is this really hard to understand thing,
 1:10 and here is the comment that says why it's this way
 1:13 or what it actually does or maybe in my mind,
-1:15 what it really should be named.
+1:15 what it really should be named."
 1:17 So my rule of thumb is if you need a comment
 1:19 to describe what a function does, you probably need a better name.
 1:22 That said, let's talk about how PEP 8 works.
@@ -44,7 +44,7 @@
 2:07 And if you happen to create your own exception type,
 2:09 here we might want to raise a RepositoryError and it derives from the exception class,
 2:14 when you have exceptions they should always be named in error,
-2:18 so something error. Here we have RepositoryError.
+2:18 so "SomethingError". Here we have RepositoryError.
 2:22 As you have seen in other cases, PyCharm will help us here,
 2:24 notice I renamed other_method, here to be Javascripty style
 2:28 with the capital M and not the underscore,
@@ -53,7 +53,7 @@
 2:36 It'll even let us hit Alt+Enter and give us some options about fixing this up,
 2:41 it doesn't quite understand how to rename it for us
 2:44 but at least it gives us the option to go over here and do a rename.
-2:47 Now this is not this renaming in place, but this is a refactor rename
+2:46 Now this is not this renaming in place, but this is a refactor rename
 2:49 across the entire project, so if we had hundreds of files, docstrings,
 2:53 that sort of stuff, this would fix all of those.
 2:57 It'll show us where it's going to change,