[CLASSICAL MUSIC]
DAVID J. MALAN: All right, this is CS50's Introduction
to Programming with Python.
My name is David Malan, and this is our week on object-oriented programming,
or OOP.
It turns out that, in the world of programming,
there's different paradigms of programming languages.
There's different ways of solving problems with code,
and it's a little hard to see this at first
if you've only learned one language.
But over time, if and when you learn other languages besides Python,
you'll start to notice certain patterns and certain capabilities
of some languages but not another.
Thus far, within the world of Python, you and I
have largely been writing code that's procedural in nature, whereby we're
writing procedures; we're writing functions;
and we're doing things top to bottom.
Everything is step by step by step, as you would
expect in general from an algorithm.
But along the way, we've actually dabbled
in another paradigm known as functional programming with Python whereby we've
been able to pass functions around.
We even had an anonymous function some weeks ago.
And that's evidence of features of a functional programming language,
even though we've just scratched the surface thereof.
Today we focus on another paradigm, and this one in more detail--
namely object-oriented programming.
And now, while some of you might have prior programming experience
and have learned languages like Java, which are, by design, fundamentally
object-oriented, Python indeed allows you a bit of flexibility
when it comes to how you solve problems with code.
But it turns out object-oriented programming
is a pretty compelling solution to problems
that you invariably encounter as your programs get longer, larger,
and more complicated.
So indeed, OOP, for our purposes, is going
to be a solution to a problem that builds on so many of the lessons past.
So let's go ahead and do this.
Let's start by writing a program very procedurally
by opening up VS Code here.
I'm going to go ahead and create a program called student.py.
And in this program, I want to do something relatively simple
initially, as we might have done some weeks ago now, where I just
ask a user for their name and, maybe in the context of the Harry Potter
universe, their house, and just print out where that student is from.
And let's gradually enhance this program by adding more and more features to it
and see if we don't stumble upon problems that, up until now,
we might not have had very elegant, well-designed solutions to.
But if we introduce, explicitly, object-oriented programming
as a programming technique, I bet we can clean up our code
and set the stage for writing even more sophisticated programs, longer programs
down the line.
So in student.py, let me go ahead and do a name variable,
setting it equal to the return value of input,
and just prompt the user for their name like this.
And then let me go ahead and do the same for a house variable
and prompt the user for their house, using input like this.
And let's do something super simple now.
Let's just go ahead and print out an f string
that says something like name from house,
just so that I can confirm that the contents of these variables
are indeed as I expect.
I'm not going to do any error checking or trimming
or anything like that for now.
I'm really just going to spit back out whatever the user just typed in.
All right, let me go ahead and run Python of student.py.
Let's use our go-to, like Harry, as in Harry Potter, from Gryffindor.
And when I hit Enter, now let's see if I see that Harry from Gryffindor
is indeed the case.
All right, so I think we have a working program at this point, but let's
now introduce some of those lessons learned way back from week zero
where we started writing our own functions,
not necessarily because it solves the problem more correctly--
I daresay this is correct as is.
But it begins to give us building blocks that we can extend so
as to solve more complicated programs.
So let me go back up to student.py, and let's go ahead now and do this.
Let's put the entire logic I just wrote inside of our typical method
called main, and let me indent those three lines so that at least they're
now combined into one main method.
But instead of using input on line 2 an input on line 3,
don't we go ahead and assume, for the moment,
that we've got some function called get_name in the world,
and let's go ahead and assume we've got another function like get_house
in the world that don't take parameters.
But their purpose in life is, by their name,
going to be to get the user's name and to get their users house, respectively.
And then I'm going to print out the exact same f string as before.
I, of course, need to implement these functions now.
So let me go lower in my file and define a function called get_name.
Nothing in these parentheses because it's not going to take a parameter.
And I'm going to go ahead and do something like name equals input
("Name"), just like before, and then I'm going to go ahead and return name.
So it's a super simple function, but it's an abstraction.
I now have a function called get_name whose implementation details
I don't have to care about anymore.
I just know that the function exists.
And I can tighten this up, in fact, .
Don't really need a name variable on line 8
if I'm immediately going to return that same name variable on line 9.
So let me just tighten this up a little bit
even though it doesn't change the functionality
and just immediately return the return value of the inputs function call here.
Let's do something very similar now for get_house,
which will similarly take no arguments.
I'm going to go ahead and return the return
value of input, this time prompting the user for their house.
And I need one final detail.
At the very bottom, let's continue our habit of doing if the name of this file
equals, equals, quote, unquote, main, then let's go ahead
and actually call main and recall that we have that in place
so that, if this eventually becomes part of a module, a library of sorts,
I don't accidentally call main blindly.
I only do it if I mean to run main from the command line on this file.
All right, so if I didn't make any mistakes here, let me go ahead
and, in my terminal window, again, run Python of student.py, Enter.
Let's type in Harry, Enter.
Let's type in Gryffindor, Enter.
And we're set.
Harry from Gryffindor seems to still be working.
So we haven't really solved the problem any more correctly,
but I've laid the foundation to maybe now do
some more interesting things because I've
had these building blocks in place.
But let me propose that we could be doing this a little bit differently.
get_name, get_house is fine.
But at the end of the day, I'm really trying to get a student from the user.
I want their name and their house, not just one or the other.
So maybe it would be a little cleaner still
to define a function called get_student and let
get_student do all of this work for us.
Now, theoretically, get_student could call get_name and could call get_house.
But because these functions are so short,
I think I'm OK with just defining one function, called get_student,
that similarly won't take any arguments.
But it's going to do two things.
It's going to get the students name, by prompting them with input as before.
And it's going to get the student's house,
by also prompting them as before.
Now, hmm.
I want to return the student, but I think
I might have painted myself into a corner
here because I now have two variables-- name and house.
And yet, up until now, we've pretty much returned one or the other.
We've returned one value.
So any suggestions for how we can perhaps
solve this problem that I just created for myself, whereby I want to return,
really, a student, but I currently have a name variable and a house variable.
I'd minimally like to return both of those.
AUDIENCE: I believe that, we can return a dictionary,
includes the name and the house.
DAVID J. MALAN: Yeah, so we absolutely could
return a dictionary-- a dict object in Python, whereby maybe one key is name;
one key is house; and the values thereof are exactly
the values of these variables.
So we could totally do that.
I worry that that might be getting a little complicated.
I wonder if there's a simpler way instead.
Any other instincts-- even if you're not sure it would work?
AUDIENCE: Return both name and house?
DAVID J. MALAN: Return both name and house.
I like the sound of that.
It sounds simple.
I don't have to figure out what a dictionary is going to look like.
And in fact, this, too, would be a valid approach,
even if you've not seen this before.
It turns out, in Python, that you can return multiple values,
but that's a bit of a white lie.
Or we could take Muhammad's approach of actually returning a dictionary
and putting multiple keys therein.
So here, again, we have yet another example
of how you can solve the same problem in at least two ways,
and I daresay we're about to see even more.
So one way you could solve this problem, whereby
you want to return multiple values, would be to do something like this.
I could go ahead and literally return not just name, but I could put a comma
and also return house.
This is not necessarily something you can do in other languages
if you have programmed in other languages before.
It depends on the language.
But it looks like, thanks to this comma, maybe I can, in fact,
return two values as [INAUDIBLE] proposed.
Well, if I'm returning to values in this way on line 10,
how do I get both values at the same time?
Well, there's a couple of ways.
Let me go up to my main function.
I know, minimally, I'm going to have to change the get_name
and get_house to get_student.
But what am I going to store the return value in?
I think I could actually do this.
And we have seen this technique before, where you can unpack,
so to speak, sequences of values that are coming back.
And indeed, consider this to be exactly that. name,
house is some kind of sequence that I'm returning of values-- name, house.
So if I want to unpack those and store the return
values in two separate variables, I can, in fact,
use the commas on the left-hand side of my assignment operator, the equal sign,
to do just that.
Now, to be clear, I don't need to call these variables name and house here.
I could simplify this and use just n here and h here,
and then I could return just n and h.
But I would argue that's not very clear to the reader as to what's going on.
So I think, in this case, even though it's
a coincidence that I've used the same variable names in get_student
and get_name, and in main, it's a little more readable to someone like me.
So I'm going to leave it as is.
Well, let's go ahead and see, now, if this works.
Let me clear my screen down here and run Python of student.py, Enter.
Let's again type in Harry.
Let's again type in Gryffindor, Enter.
And voila, we still see that Harry is from Gryffindor.
But what are we actually doing here?
What are we actually doing by returning this value?
Well, it turns out that what we've just done is use a tuple.
A tuple is another type of data in Python that's a collection of values--
x, y or x, y, z.
It's similar in spirit to a list, in that sense, but it's immutable.
It's not mutable.
Now, what does that mean?
A list, as we've seen it before, is a data structure in Python
that you can change the values of.
You can go into bracket 0 for the first location and change the value there.
You can go to bracket 1, bracket 2, bracket 3 and actually change
the values in lists.
But if you have no intention of changing the values of variables
and you want to return, effectively, multiple values,
you don't have to even return it as a list.
You can return it as a tuple instead, just by using a comma.
And it turns out we can make explicit that-- here's the white lie.
I'm not actually returning to values per se.
Whenever you use a comma in this way on line 9,
you're actually returning one value, which is a tuple.
Inside of that tuple now are two values.
So it's similar in spirit to returning one list with two thing Here
I'm returning one tuple with two things.
And the mere fact that I've used a comma and nothing else
tells Python that I indeed want to return a tuple.
But there's more explicit syntax that we can use instead.
I can actually-- more verbosely-- put explicit parentheses around the values
of this tuple just to make more clear to me, to the reader
that this isn't two values per se.
This is one value with two things inside of it.
And what I can actually do then, too, is--
I don't have to unpack this up here, so to speak.
I can actually go up here and maybe give a more apt name, like student,
and I can name the value, or rather name the variable
in which I'm storing the return value of get_student as,
quote, unquote, "student."
So maybe this is a little better design now
because I'm sort of abstracting away what a student is.
It's implemented at the moment as a tuple with two values.
But at least, now I have a variable called what I mean, a student.
But there's going to be a catch.
On line 3, I still want to print out that student's name and their house.
But I don't have a name variable anymore, and I don't have a house.
And I also don't have a dictionary, as was proposed earlier, so I can't even
go at those keys by name.
But what a tuple is-- it's very similar in spirit to a list,
but it is indeed just immutable.
And what I mean by that is I can still index into it
numerically by saying student [0] for the item
in the first location in that tuple.
And then over here, instead of house, I can say student [1].
student [1] is going to give me the second location in that tuple.
Let me go ahead and clear my terminal window.
Again, run Python of student.py.
Let's type in Harry.
Let's type in Gryffindor, Enter, and we still have some working code.
Let me pause here now and see if there are
any questions on this technique of returning a tuple
and indexing into it in this way.
AUDIENCE: I guess, what's an actual use case where
you would use a tuple versus a list or something else that's similar?
DAVID J. MALAN: It's a really good question.
When would you use a tuple versus a list?
When you want to program defensively, or, in general,
when you know that the values in this variable shouldn't change,
so why would you use a data type that allows them to be changed?
It just invites mistakes, bugs down the line, either
by you or colleagues who are interacting with your code.
So tuple is just another way where you can increase
the probability of correctness by just not letting anyone, yourself included,
change the contents therein.
So it's just another tool in your toolkit.
But let's make clear, then, what I mean by "immutable."
Again, I claim that "immutable" means that you cannot change the value.
Well, let's go ahead and try to do this.
Let me go ahead and run this program once more as is--
Python of student.py.
Let me go ahead and type in, for instance--
how about Padma's name?
And I'm going to go ahead and say that Padma
is in Gryffindor as in the movies.
And we see-- Padma from Gryffindor.
But technically, I went down this rabbit hole in looking at Harry Potter
more closely.
Technically, in the books, Padma, I believe, was from Ravenclaw.
So this is actually a mistake or an inconsistency
between the movies and the books.
Let's see if we can't fix this inconsistency in our code.
So how about we do this?
If the student's name that's inputted equals Padma,
why don't we override whatever the house is
and change it to be properly Gryffindor.
Let me go ahead and do if student--
now, if I want to get at Padma's name, I'm going to have to do student [0].
I have to know what location the name is in in this tuple.
But if that value equals equals Padma, let's go ahead with this if statement
and make a change.
Let's change the student's [1] value.
So the second value, if we're zero indexing--
let's change it to be another house in the world of Harry Potter
called Ravenclaw.
So I'm just fixing maybe the user's input.
They watched the movie so they type in Padma Gryffindor,
but, mm-mm, in the books, it was Padma from Ravenclaw.
All right, let me go ahead and go down to my terminal window,
clear my terminal, and do Python of student.py, Enter.
I'm going to do Harry as well as Gryffindor, just to demonstrate
that that is still working as intended.
Let me clear my screen again, though, and run Python of student.py on Padma,
and I'll put her, too, in Gryffindor, as in the movies, and hit Enter.
And now I just see a big mess of errors on the screen.
Some kind of exception has been thrown.
And indeed, a type error has happened.
I'm using a data type wherein there's an error, and what is that error?
Well, 'tuple' object does not support item assignment.
It's a little arcanely expressed-- that is, it's not really very user friendly.
But if you think about what those words mean,
'tuple" object does not support item assignment.
So assignment is copying from right to left.
So somehow, that's invalid.
And here is a manifestation of the immutability of tuples.
You cannot change location 0 or 1 or anything inside.
That is a feature.
That is the design of a tuple.
So if I want to override that, I think I'm
going to have to use a different type of data that we've used before--
namely a list, and that's fine.
If you want to enable yourself and colleagues using your code
to change the contents of that container,
well, we can go ahead and return not a tuple using
explicit parentheses or no parentheses, just the comma,
but I can use square brackets.
And if I'm using square brackets on the left and the right,
this is indeed explicitly a list.
Same idea, but it's mutable.
That is to say you can change the contents of a list.
So making no other changes, just returning a list
with square brackets instead of a tuple with parentheses or just the comma.
Let me go ahead now and run Python of student.py, Enter.
Let me type in Harry and Gryffindor again.
That's still working.
Good to see.
Let me run this once more and type in Padma and Gryffindor, as in the movies,
but no, now we've corrected it to be Padma from Ravenclaw,
as in the books instead.
Any questions now on tuples versus lists or this idea
of immutability versus mutability.
AUDIENCE: Can we use a nested tuple in Python, like a nest list?
DAVID J. MALAN: Absolutely.
You can have not only nested lists in Python,
where one of the elements in a list could be another list-- so you
have some square brackets out here; you might have some other square brackets
inside.
You can absolutely do the same with a tuple as well.
There is no constraint on the types of values you can put in there.
We've not had occasion to do that in this case.
I'm just returning a simple tuple with two elements.
But yes, you could absolutely do that, too.
Other questions on tuples versus lists?
AUDIENCE: OK, for example, when I see the square brackets,
is it mainly used for the list?
DAVID J. MALAN: Oh, a really good question.
Sort of.
So when you create a value like a list, you use square brackets,
and that would indeed be a visual indicator
that this is definitely a list.
If you instead see parentheses, that's a visual indicator,
when creating a value, that it's definitely a tuple.
However, somewhat confusingly, both lists and tuples
use square brackets when you access the contents of them.
When you index into them at location 0 or location 1
you always use square brackets.
So that's the distinction there.
Good question.
Allow me to propose now, if I may, that we solve this problem yet another way,
and let's see if we're either making things better or for worse than us.
Recall that dictionaries, or dict objects, also exist in Python.
And a dictionary is this collection of keys and values.
And the upside, in particular, of a dictionary
is that they have better semantics.
You don't just have to assume that a name is always
going to be at location 0; house is always going to be at location 1.
That's the kind of thing, especially if you had three, four, or more values--
eventually you or someone is going to get confused and forget
what the order is and you're going to write buggy code.
So a dictionary is a little more powerful
in that you can semantically associate keys, little descriptions,
with the values--
those keys and those values, respectively.
So let me go ahead and do this, and we can do this in a few different ways.
But let me propose that we focus on get_student here .
And let's go ahead and do this.
Let me go ahead and delete the implementation of get_student as is.
Let me create a student variable and initialize it to an empty dictionary.
And I can do that with just two curly braces here.
And then let me go ahead and set two keys inside of that dictionary.
Inside of the student, there will be, quote unquote, a "name"
key, and the value of that is going to be whatever the return value of input
is when I prompt the user for their name.
And then the "house" key, inside of that same student dictionary,
is going to be the return value of whatever the user types
in for their house. , And lastly I'm going to go ahead and return student.
So now I am literally returning one thing, still,
but this time, it's a dict rather than a tuple, rather than a list.
But there are still two things in it, technically four things
if you count the keys and the values.
But there's two key value pairs.
Now, my code up here is going to have to change a little bit.
And let's simplify this and remove, for instance, now
the Padma if statement just to focus on what's changing at hand.
And let me go ahead now and leave line 2 alone.
I'm still going to have a student variable that gets assigned the return
value of get_student.
But what I want to do here now is actually access the keys inside of that
dictionary-- not by numeric index, which was for tuples and lists--
0 and 1, but by way of the keys.
Now, normally, I might be in the habit, as I personally
am, of using double quotes-- quote, unquote, "name" inside of there
and quote, unquote, "house" inside of there.
But before I even run this code and show you a mistake--
see an error on the screen, does anyone want to call out
what I have done wrong here?
This is just an f string.
I just want to print out the value of the name key, the value of the house
key in this dictionary.
AUDIENCE: [INAUDIBLE]
DAVID J. MALAN: Your audio was a little garbled for us.
But I think I heard double quotes and single quotes.
So I'm going to assume that, indeed, you've identified precisely the issue.
I'm just going to confuse Python right now.
Even though this is an f string inside of double quotes, prefixed with an f,
I can't actually use my double quotes inside my double quotes
because that's going to potentially confuse Python.
If I run this program now, Python of student.py and hit
Enter, I get a syntax error.
So the program didn't even run fully.
It just couldn't be understood because it got confused by those double quotes.
So the simplest fix here would indeed just
be to use not double quotes but single quotes around the keys,
or conversely, flip the double quotes on the outside to single quotes,
then use double quotes in the inside.
You just want to be consistent.
So a subtle detail, but again, this is now specific to dictionary syntax.
This isn't fundamental to how we're solving this current problem at hand.
Well, let's go ahead and try this.
Let me go ahead now and run Python of student.py.
Let's go ahead and type in Harry.
Let's type in Gryffindor.
And hopefully, Harry is back from Gryffindor.
No syntax errors.
No other errors.
I think I'm back in business here.
And what I do like to be clear about using a dictionary
is that it's allowing me just better semantics.
And again, I don't have to remember, memorize, document that 0 is name;
1 is house.
Instead, "name" is name and "house" is house.
It's just a little clearer, a little more expressive.
So that's generally a good thing, especially if we stored more data about
students than just their name and their house-- if you had three fields, four,
five, 10 different fields--
no one's going to want to remember or be able to remember forever which is zero
which is 1, which is 2, and so forth.
Better to introduce names, like "name" and "house" in this case.
But let me tighten this up further.
I'm typically in the habit of not introducing variables unnecessarily,
unless they make the code more readable.
And an alternative way to format the same code would be this.
Strictly speaking, I don't need to create an empty dictionary,
then add one key to it, then add a second key to it,
and then return that dictionary.
I can actually consolidate this all into one statement, if you will.
Let me go ahead and do this.
Let me go ahead and say name equals inputs return value,
house equals inputs return value, and then,
instead of returning any variable name student, which I'm going to propose
doesn't need to exist anymore, let me just create
and return the dictionary all at once.
Let me do, quote, unquote, "name" in lowercase here, and then the variable.
It's storing the user's name.
Then, quote, unquote, "house," as my second key, the value of which
is going to be house, the variable.
Now, is this better?
Maybe, maybe not.
Maybe the first way was a little more readable,
and that's totally fine to create variables
if they improve the readability of your code.
But just know that you can also create and return a dictionary on the fly
like this, so to speak, all in one line, and I
think it's arguably pretty reasonable in this case.
Why?
It's just pretty short.
I probably wouldn't do this if it got longer and longer and longer.
I might minimally then start moving my key value pairs to separate lines.
But this would just be a slightly more compact way of doing this as well.
But let me propose we do one more change.
Let's go ahead and introduce that same special casing of Padma
to fix her house from Gryffindor, for instance, to Ravenclaw.
How do we do this with dictionaries?
Well, dictionaries, like lists, are mutable.
You can change what is in them, just like you can lists.
How do you do that?
It's just a little different syntactically.
So let's go back into main and do this fix.
If the student variable has a name key that equals equals Padma, then,
indented, go ahead and change the value of the house key inside of that student
dictionary to be, quote, unquote, "Ravenclaw" instead.
So very similar in spirit to what we did with a list.
But instead of using location 0 and 1, we're much more clearly, explicitly,
semantically using, quote, unquote, "name" and, quote, unquote,
"house," because you index into lists and tuples using numbers, but you index
into dictionaries using strings, as I've done here.
All right, let me go ahead and run Python of student.py.
We'll again do Harry from Gryffindor.
And I think all is well.
Let me run it one more time this time with Padma, who, in the movies,
is from Gryffindor, but should really be from Ravenclaw.
Any questions then on this progression from tuples to lists to dictionaries?
We haven't necessarily introduced anything new, other than those tuples,
which have been available to us all this time.
But the goal at the moment is just to demonstrate this distinction
among these different data types and how they
each work a little bit differently.
AUDIENCE: What if a combination of lists is there in our tuple?
We can change the list because are immutable but lists are mutable?
DAVID J. MALAN: Correct.
You can change the contents of lists, and you
can put most anything you want in them-- other lists or strings, as I've done,
integers, or anything else.
Tuples you can do the exact same thing, but you cannot change them once
you've created them.
A dictionary is more like a list in that it is mutable.
You can change it.
But the way you index into a dictionary is
by way of these keys, these strings, as we keep saying,
rather than by numbers--
those numeric indices.
All right, well, let me propose that there is yet
another way of solving this problem.
And I would argue that there's now an opportunity at hand.
Even though this program isn't particularly complicated--
all I'm doing is collecting a name from the user and a house
from the user-- you could imagine wanting,
longer term, to collect even more information,
like the student's patronus or magical spell
or a whole bunch of other information that might belong in a student.
And right now, we're just using these very general purpose data
types in Python--
a tuple to combine some values together; a list to do the same,
but let us change it later; a dictionary, which is more powerful
because it's a little more structured.
It does have keys, and it has values, not just values.
But you know what?
We wouldn't have to be having this conversation if the authors of Python
had just given us a data type called student.
Wouldn't it have been nice if there were just
a type of variable I could create in my code called student?
Then we wouldn't have to figure out, well,
do we use a tuple or a list or a dictionary?
But that's pretty reasonable.
You can imagine just how slippery of a slope that is, so to speak,
if the creators of a language had to anticipate
all the possible types of data that programmers like you
and me want to store in your programs.
So they just gave us these general purpose tools.
But they gave us another general purpose tool
that's going to allow us to create our own data types as well
and actually give them names, and that terminology is a class.
A class is like a blueprint for pieces of data objects.
A class is a mold that you can define and give a name.
And when you use that mold or you use that blueprint,
you get types of data that are designed exactly as you want.
So in short, classes allow you to invent your own data types in Python
and give them a name.
And this is a primary feature of object oriented programming,
to be able to create your own objects in this way
and, in the case of Python in classes, even give them some custom names.
So what does this mean in real terms?
Well, let me go ahead and come back to VS Code
here, and let me propose that we introduce a little bit of new syntax.
I'm going to go ahead and clear my terminal window first.
I'm going to go to the top of my file, and I'm just going to start a thought
but not finish it yet.
I'm going to use this new keyword for classes, called, literally, class,
so the new keyword we're going to have here.
And if I go back to our slides here, this
would be the official URL where you can read up more
on this particular feature of Python.
In the official tutorial, class is a new keyword we can use.
Now, this is coincidentally related to students because students take classes,
but it has nothing to do with the fact that we're dealing with students.
Class is a general purpose term in a lot of languages--
Python among them-- that allow you to define these custom containers
with custom names for pieces of data.
So let's go back to VS Code.
Let's use this new keyword.
And let me propose that we create a class called Student.
And by convention, I'm going to use a capital S here,
and I'm going to go ahead, and with a colon,
get to, later, the implementation of this class.
So I'm just going to use dot dot dot, which is a valid placeholder for now,
that just indicates to me that I'm going to come back
to implementing this later.
But as of now, it does, in fact, exist.
I now have a student class defined for me that I can now use in my code here.
How am I going to use it?
Well, first of all, let me go down to get_student,
and let me change this code to no longer use a dictionary but to use this class.
I'm going to do this.
I'm going to give myself a variable called student, as I've done before,
but I'm going to set it equal to capital Student ().
So I'm going to do what appears to be calling a function
and that function, Student with a capital S, notice,
matches the name that I gave this class at the top of my file.
All right, what do I next want to do?
I'm going to go ahead and give this student a name.
Now, if I were still using a dictionary, I
would say student, quote, unquote, "name," using square brackets.
But this is not a dictionary.
It turns out classes have what, for now, we'll
call attributes, properties of sorts that allow you to specify values inside
of them.
And the syntax for that happens to be a dot.
We've seen dots before.
We've used it in the context of modules and libraries, more generally.
This is another similar in spirit use of a dot
that allows you to get at something inside of something else.
So student.name is going to be the syntax
I use for giving this student a name.
And that name is going to be whatever the return value of "Name" is.
And then I'm going to go ahead and say student.house to give
another attribute called "House" and give that the return value of input
here, prompting the user for house.
And then, as before, I'm just going to return student.
But now what's really powerful about class,
and object-oriented programming more generally,
is that I've created this custom data type called, literally,
Student, capital S. I've stored one such student in a variable
like I can always do in a variable called student, lowercase s.
But I could call it anything I want.
It just makes sense to call it student as well, but lowercase for clarity.
And then I'm returning that variable.
And because of my syntax in lines 14 and 15,
that has the result of putting inside of that class
a name attribute and a house attribute.
I just need to make one more change up here.
I'm going to go ahead and remove our Padma
code, just so we can focus only on what's new,
rather than fixing her house.
And I'm going to go in here and change the syntax that
previously was for dictionaries.
Again, dictionaries use square brackets and then strings in quotes--
either single quotes or double quotes, depending on the context.
Here, though, I'm going to change this to be student.name,
and over here, I'm going to change it to be student.house.
And that's just going to be my new syntax for getting the contents of what
appears to be a class called student.
Let me go ahead and rerun Python of student.py, Enter.
Let's type in Harry's name as before.
Let's put him in Gryffindor, crossing our fingers as we often do,
and Harry is indeed from Gryffindor.
What, though, have I done?
Let's introduce one other bit of terminology here
it turns out that I can create a class, using that class keyword.
But any time you use a class, you're creating what are called objects.
And here is the word objects, as an object-oriented programming, or OOP.
Let me go back to my code here.
And even though I haven't really implemented much of it at all--
I literally just left it with a dot, dot, dot--
that's enough code, lines 1 and 2, to just invent a new data type called
Student, capital S, that may or may not have some future functionality as well.
That's enough to create a class.
What, though, am I doing on line 11?
On line 11, what I'm technically doing is creating an object of that class.
So this, too, is another term of art.
You create objects from classes.
So if we go back to that metaphor, that a class is
like a blueprint for a house or a class is like a mold,
an object is when you use that blueprint to build a specific house
or something that comes out of-- in plaster, the mold, when you actually
use that mold to create such an object.
So a class is, again, the definition of a new data type.
The object is the incarnation of, or technically instantiation of.
And another term for objects would actually be an instance.
You have instances of classes as well.
So that's a lot of vocabulary.
But at the end of the day, it just boils down to this.
You can define your own class, which is really your own data type.
You can then store attributes inside of it, using this dot notation here.
And then you can access those same attributes using code like this here.
And now, I have a proper "student" data type,
and I don't have to hack something together
using a tuple or a list or even a dictionary.
I now have a proper data type called "student" that the authors of Python
didn't give me; I gave myself.
Any questions now on classes, this new keyword, class, or this idea
of these objects or instances thereof?
AUDIENCE: Is the class object mutable or immutable?
DAVID J. MALAN: A good question.
And we've clearly laid the stage for having that conversation
about every data type now.
We will see that they are mutable, but you can make them immutable.
So you can get the best of both worlds.
Now, by writing some actual code-- and we'll write more code than the dot,
dot, dot in just a bit, other questions on classes or these objects thereof?
AUDIENCE: Then what would be the properties of those classes?
DAVID J. MALAN: So at the moment, the properties of-- or the attributes of,
as I've been calling them thus far-- would just be "Name" and "House."
It turns out that there may very well be other attributes built into classes
that we may see before long.
But for now, the only two attributes that I care about
are the ones that I myself created--
namely "Name" and "House" or, again, what I would call attributes.
And in a little bit, we're going to start
calling those same attributes, more technically, instance variables.
"Name" and "House," as I presented them here in VS Code
are really just variables called "name" and called "house" inside
of an object whose type is student.
All right, so what more can we do with these classes?
Well, again, on line 11 is where we're instantiating
an object of the student class and assigning it to a student variable.
We're then adding attributes--
"Name" and "House," respectively-- on lines 12 and 13 currently.
Both of those have values that are technically
strings or strs, because that's what the return value of the input is.
But those attributes values could actually be any data type.
We're just keeping things simple and focusing on defining students
in terms of two strings--
"Name" and "House."
And then, on line 14, we're returning that variable.
We're returning that object to main so that we can actually
print out who is from what house.
Well, let's go ahead and add a bit more functionality here because, right now,
on lines 12 and 13, this is a little manual.
And it's a little reckless of me to just be putting anything
I want inside of this student object.
It turns out with classes, unlike with dictionaries,
we can actually standardize, all the more, what those attributes can be
and what kinds of values you can set them to.
So let me go ahead and do this.
Let me propose that it would actually be really
nice if, instead of doing this here, let me go ahead
and simplify my code as follows.
Let me go ahead and give myself a local variable called name
and set it equal to the return value of input, like we've done many times now
already.
Let me give myself one other variable for now, called house,
and set it equal to the return value of input
as well, prompting the user for their house.
And now, instead of creating a student object from my student class
and then manually putting the name attribute inside of it
and the house attribute inside of it, let
me actually do something more powerful.
Let me do this.
Let me call that Student function, which is identical to the class name--
just by defining a class, you get a function
whose name is identical to the class name, with the capital letter included.
But instead of just doing open parenthesis,
closed parenthesis, let me pass in the name that I
want to fill this object with and the house that I want to put in that object
as well.
And now let me set the return value as before to be student equals like this.
So what have I done that's different?
Fundamentally, I'm still getting user input in the same way.
I'm using input on line 11 and input on line 12.
And I just so happen to be storing those return values in local variables.
And now we're setting the stage for the more powerful features of classes
and object-oriented programming more generally.
Notice that I'm deliberately passing to this capital S Student
function, name, house--
I'm passing in arguments to the function.
Now, the student class is not going to know what to do with those yet,
but now I'm standardizing how I'm passing data into this student class.
And ultimately, it's going to give me an opportunity to error
check those inputs, to make sure that the name is valid, that it has a value
and it's not just the user hitting Enter.
It's going to allow me to ensure that it's a valid house, that it's
Gryffindor or Hufflepuff or Ravenclaw or Slytherin
or not just hitting Enter or some random value that the user types in.
Because I'm passing "Name" and "House" to the student
class, this particular function, I'm going
to have more control over the correctness of my data.
So let's now go up to the student class, which, up until now,
I left as just dot, dot, dot.
It turns out that, in the context of classes,
there are a number of not just attributes or instance
variables that you can put inside, but also methods.
Classes come with certain methods, or functions inside of them,
that you can define, and they just behave in a special way,
by nature of how Python works.
These functions allow you to determine behavior in a standard way.
They are special methods in that sense.
Now, what do I mean by this.
Well, let me go back to VS Code here.
And let me propose that I start to define a standard function
called underscore underscore, or Dunder, as it's
abbreviated, init, underscore underscore,
and then I'm going to go ahead and do open parentheses,
and then I'm going to put in here, literally, the word self.
More on that in just a moment.
But now, inside of this function, I'm going to have an opportunity
to customize this class's objects.
That is to say this underscore, underscore init method,
or Dunder init method is specifically known as an instance method,
and it's called exactly this.
This is designed by the authors of Python.
And if you want to initialize the contents of an object from a class,
you define this method, and we'll see what it's about to do here.
Let me go back to VS Code, and let me do something like this.
self.name = name, and self.house = house.
But I don't want to just init this object very generically.
I want this method, called init, to take in not just self but name,
house as well.
Now, what in the world is going on?
Because there's a lot of weird syntax here.
There's this Dunder init method--
double underscore, init, double underscore.
There's, all of a sudden, this parameter called self.
And then there's this new syntax-- self.name and self.house.
Now you're seeing really a manifestation of object-oriented programming.
It's not all that different fundamentally
from what we've been doing for weeks with dictionaries,
by adding keys to dictionaries.
But in this case, we're adding variables to objects, a.k.a.
instance variables to objects.
Now, what's going on?
Let's do this in reverse.
Let's go back to the line of code we wrote earlier.
On line 15, I am treating the name of this class--
Student with a capital S-- as a function.
And I am passing in two values--
"Name" and "House."
What I've highlighted here on the screen, on line 15,
is generally known as a constructor call.
This is a line of code that is going to construct a student object for me.
Using synonyms, it is going to instantiate a student object for me.
And again, how is it going to create that object?
It's going to use the student class as a template, as a mold of sorts
so that every student is structured the same.
Every student is going to have a name.
Every student's going to have a house.
But because I can pass in arguments to this Student function, capital S,
I'm going to be able to customize the contents of that object.
So if you think about the real world-- if you've ever been on a street
or a neighborhood where all of the houses look the same but they might be
painted differently; they might be decorated a little bit differently
on the outside, all of those houses might have been built using the exact
same blueprint--
a mold, if you will.
But then you can specialize exactly the finer points of those houses.
By painting the outside a different color or planting different trees,
you can style them differently.
Similar in spirit here, we have a Student blueprint
that's always going to have now a name and a house, but it's up to you and me
to pass in any name and any house that we want.
Now, where is this function?
The fact that I'm calling Student, capital, S and then a parenthesis
and a closed parenthesis with arguments inside
suggest that there's a function somewhere
in the world that has been defined, with def, that's going to be called.
Well, as you might have guessed by now, the function
that will always be called, by definition of how Python classes work,
is a function called double underscore, init, double underscore.
Why?
It's a crazy name, but it's what the authors of Python
chose to just implement the initialization of an object in Python.
Now, the only weird thing--
especially weird thing, I will admit, is this.
It would be way clearer, to me, too, if the only two parameters for init we're
just name, house.
That's how we've defined every function thus far in the class.
You just specify the parameters that you want the function to accept.
And that lines up with what I'm doing on line 15.
I am only passing in two things to the student function.
But it turns out that the authors of Python
need to give us a little bit of help here
because suppose that you pass in "Name" and "House" to this init method.
And a method is just a function inside of a class.
What are you going to do with the name and the house?
Literally, where are you going to put them?
If you want to remember the name and the house for this student,
you've got to be able to store those values somewhere.
And how do you store them in the current object
that has just been "instantiated?"
Well, the authors of Python decided that the convention
is going to be that this init method also, semi secretly, takes
a third argument, that has to come first.
By convention, it's called self, but you could
call it technically anything you want.
But the convention is to always call it self.
And self, as its name implies, gives you access
to the current object that was just created.
What does that mean?
Again, now, on line 14, now that it's moved down a little bit,
this line here is a constructor.
It constructs a student object.
But there's nothing in that object initially.
There's no name; there's no house.
But the object exists in the computer's memory.
It's up to, now, you to store the name and the house inside of that object.
How do you do that?
Well, Python will just automatically call this init method for you,
and it's going to automatically pass in a reference to an argument that
represents the current object that it just constructed in memory for you,
and it's up to you to populate it with values.
And what this means is that, inside of your init method,
you can literally do self.name to create a new attribute, a.k.a.
an instance variable, inside of that otherwise empty
object and put this name inside of it.
It allows you to do self.house and store that value of house.
Now, you could call these things anything you want.
They could be n.
They could be h, as before.
But that's really not very self-explanatory.
Much better to do this kind of convention. self.name equals name.
self.house equals house.
And this is like installing into the otherwise empty object the value name
and house and storing them in, really, identically named instance
variables in the object.
And again, an object is just an instance of a class.
Now, I know that was a lot of vocabulary.
That's a lot of weird syntax.
So any questions on this init method, whose purpose in life,
again, is to initialize an otherwise empty object when you first create it?
AUDIENCE: So what is the difference between the init method and default
constructor?
DAVID J. MALAN: A good question.
So in other languages-- if you programmed before.
For instance, Java-- there are functions that are explicitly called
constructors that construct an object.
They initialize it with values.
Python technically calls this init method the initialization method.
It initializes the value.
It's on line 15 now of my code, if I scroll back down, that I'm technically
constructing the object.
It turns out there's another special method in Python,
that we won't talk about in detail today,
called underscore underscore, new, underscore underscore
that actually handles the process of creating
an empty object in memory for us.
But, generally speaking, you, the programmer,
don't need to manipulate the new function.
It just works for you.
Instead, you define your own init method here
and init function inside of your class, and that method
initializes the contents of the object.
So there's technically a distinction between constructing the object
with new and initializing it with init.
But in the world of Python, you pretty much only worry about the init method.
Python generally does the other part for you.
A good question.
Others?
AUDIENCE: What about if you want to store more than one name or more
than one house?
DAVID J. MALAN: A good question.
If you want to store more than one name or more than one house,
you can do this in different ways.
You could create other attributes-- technically called instance variables--
like self.name1, self.name2.
But we've seen, in the past, that that is not
a very good design, just to have multiple variables to store
multiple things.
Maybe, instead, you have an instance variable called self.names, plural,
and you set it equal to a list of names or a list of houses.
Now, in this case, I don't think that really solves a problem because I'm
trying to implement a student, singular, so it doesn't really make sense
to have multiple first names.
Maybe a nickname, maybe a last name, so we could add those, too.
But I don't think we need multiple names per se
and, in this case, multiple houses.
But absolutely, you could do that using some of our familiar building blocks
like lists.
Other questions?
AUDIENCE: How are classes or objects represented in memory?
DAVID J. MALAN: How are classes and objects represented in memory?
So the class is technically just code.
It is the code on the top of my file-- lines 1 through fou4--
that defines that blueprint, that template, if you will.
Objects are stored in the computer's memory
by taking up some number of bytes.
So you're probably familiar with bytes or kilobytes or megabytes.
There's some chunk of bytes, probably all
in the same location in the computer's memory
or RAM, where those objects are stored.
But that's what Python, the program, handles for you.
Python the interpreter figures out where in the computer's memory to put it.
You and I, the programmers, get to think and solve problems at this level.
Python, the interpreter, handles those lower level details for you.
How about one final question on classes and objects?
AUDIENCE: So my question is if we can the same do
the same thing with the dictionaries, so why to use classes?
DAVID J. MALAN: Good question.
If you can do the same things as you can with dictionaries,
why should you use classes?
Because we are just scratching the surface now of what
you can do with classes.
Allow me to go back, now, to my keyboard and show you
more of what you can do with classes.
But in short, you can do much more with classes.
You can ensure the correctness of your data much more with classes.
You can error-check things.
And generally, you can design more complicated software more effectively.
And we'll continue to see, today, features
of Python and object-oriented programming more generally
that allows us to do just that.
So let me propose, in fact, that first, let's just tighten up this current
implementation, which again has us with an init method that just declares two
instance variables-- self.name and self.house, house, which, again,
just creates those variables inside of the otherwise empty object and assigns
them values--
name and house, respectively.
Let me go ahead and just do one little thing here.
I don't really need this student variable.
Let me just tighten this up so that each time we improve or change the code,
we're focusing, really, on just the minimal changes alone.
So I've not fundamentally done anything different.
I just got rid of the variable name, and I'm just
returning the return value of this student function
that's constructing my new object for me.
So I'm just tightening things up as we've done many times in the past.
Well, what if something goes wrong in creating this student?
For instance, what if the user does not give us a name, and they just hit
Enter when prompted for name.
I don't want to put in my computer's memory
a bogus student object that has no name.
I'd ideally like to check for errors before I even create it
so I don't create a nameless student.
It would just be weird and probably a bug to have an object that has no name.
Similarly, I don't want the user to be able to type
in something random as their house.
At least in the world of Harry Potter, there's really
only four houses, at Hogwarts at least.
There's, again, Gryffindor and Hufflepuff
and Ravenclaw and Slytherin-- a list of four valid houses.
It would be nice if I somehow validated that the user's input is indeed
in that list.
Now, I could do all of that validation in my get_student function.
I could check, is the name empty?
If so, don't create the student object.
Is the house one of those four houses?
If not, don't create the student object.
But that would be rather decoupled from the student itself.
get_student currently exists as just my own function in my student.py file.
But classes-- and really, object-oriented programming-- more
generally encourages you to encapsulate, inside
of a class, all functionality related to that class.
So if you want to validate that a name exists--
if you want to validate that a house is correct,
that belongs just fundamentally in the class called student itself,
not in some random function that you wrote elsewhere.
Again, this is just methodology because, again,
if we think about writing code that gets longer and longer, more and more
complicated, it should make just intuitive sense that,
if you keep all the house--
all of the name and all of the house-related code in the student,
it's just better organization.
Keep all of the related code together, and that's probably
going to set you up for more success.
And indeed, that's part of this methodology
of object-oriented programming.
Let me go ahead now and change my students classes
init method to do this.
If the name is blank--
so if not name-- and we've seen this kind of syntax before.
If you say in Python, Pythonically, if not name,
that's doing something like this.
If name equals, equals, quote, unquote--
but I can do this a little more elegantly.
Just say, if not name, would be the more Pythonic.
Well, I want to return an error.
I might want to do something like this.
Print missing name.
But this is not good enough.
It does not suffice to just print out missing name
and then let the rest of the code go through.
All right, well, what could I do instead?
In the past, we've seen another technique I could do sys.exit,
and I could say something like missing name, and I could go up here
and I could import sys.
But this is a really obnoxious solution to the problem.
Just because you or maybe a colleague messed up
and called a function with an invalid name,
you're going to quit my whole program?
That's really, really extreme of a response,
and you probably don't want to do that if your program is
in the middle of running.
You might want to clean some stuff up.
You might want to save files you don't want to just exit a program sometimes
in some arbitrary line, just because input was invalid.
So I don't think we want to do that either.
But we do, now, have a mechanism for signaling errors.
Unfortunately, I can't do something like this.
I could try returning none and say, uh-uh, this student does not exist.
I'm going to hand you back none instead.
But it's too late.
If we scroll back down to where I'm creating the student, it's on line 17
now where I've highlighted this code.
The student has already been created.
There is an object somewhere in the computer's memory
that's structured as a student.
It just doesn't have any values inside of it.
But it's too late, therefore, to return none.
That ship has sailed.
The object exists.
You can't just suddenly say, nope, nope, there is no object.
There is an object.
It's up to you to signal an error.
And how do you signal an error?
Well, we've actually seen this before, but we haven't had occasion
to create our own errors.
It turns out, in Python, there's another keyword related to exceptions
that Python itself uses to raise all of those exceptions we've
talked about in the past.
When you've caught things like value errors or other such exceptions that
come with Python, well, it turns out you, the programmer can raise--
that is create your own exceptions when something just really goes wrong--
not wrong enough that you want to quit and exit the whole program,
but enough that you need to somehow alert the programmer
that there has been an error.
Something exceptional, in a very bad way-- something
exceptional has happened, and let them try to catch that exception as needed.
So let me go back to VS Code here and propose
that, if the user passes in an invalid name-- it's just empty,
so there's not a name.
Well, what I really want to do is this.
I want to raise a value error.
And we've seen the value errors before.
We've created value errors accidentally before.
And generally, you and I have tried to catch them if they happen.
Well, the flip side of this feature of exceptions in a language like Python
is that you, the programmer, can also raise exceptions
when something exceptional happens.
And you can even be more precise.
You don't have to raise a generic value error and let the programmer figure out
what went wrong.
You can treat value error and all exceptions in Python like functions
and actually pass to them an explanatory message like, quote, unquote,
"Missing name," so that at least the programmer, when they encounter
this error, knows, oh, I messed up.
I didn't make sure that the user has a name.
And now, what do you want to do instead?
Well, now, if you're the programmer, you could do something like this.
You could try to create a student except if there's a value error.
Then you could handle it in some way.
And I'm going to wave my hand with a dot, dot, dot,
at how you would handle it.
But you would handle it using try and accept, just like we have in the past,
and that would allow you, the programmer,
to try to create the student.
But if something goes wrong, OK, I'll handle it nonetheless.
So what's new here, again, is this raise keyword,
that just lets you and I actually raise our own exceptions
to signal these errors.
Well, let me go back to my code here, and I'm just
going to go ahead and not bother trying or catching this error.
For now, we'll just focus on raising it and assume
that, from our recon exceptions, you could add try and accept
as needed in places.
Let me go back to the code here and propose that something else could
go wrong with house.
If there is a name, we're good.
But if we're given a house but it's invalid,
we should probably raise an exception for that, too.
So what if we do this?
If house is not in the list containing "Gryffindor," quote, unquote,
"Hufflepuff," quote, unquote--
let's see, "Ravenclaw," quote, unquote, or "Slytherin,"
quote, unquote, then, with my colon, let's
raise another type of value error.
But rather than raise a generic value error,
let's pass in an argument, quote, unquote, "Invalid house."
And so here we now see a capability that we
can do with classes that we can't with dictionaries.
If you add an attribute to a dictionary, a key to a dictionary,
it's going in no matter what.
Even if the name is empty, even if the house is a completely random string
of text that's not one of these four houses,
it's going into that dictionary.
But with a class, and by way of this init method,
you and I can now control exactly what's going to be installed, if you will,
inside of this object.
You have a little more control now over correctness.
And so now let me go ahead and scroll back down to my terminal window
and clear it.
Let me run Python of student.py.
Let me type in something like Harry.
Let me type in Gryffindor, Enter, and we see
that, indeed, Harry is from Gryffindor.
What if I made a mistake, though?
What if I ran Python of student.py and typed Harry as the name,
but this time typed in Number Four, Privet Drive, which
is where he grew up, instead of his proper Hogwarts house.
Let me hit Enter now, and now you see a value error.
But this isn't one that Python generated for us, per se.
I raised this error.
And therefore, if I went in and wrote more code in my get_student function,
I could also catch this error with our usual try except syntax.
So all we have now is not just classes in our toolkit, but even more powers
when it comes to exceptions, and not just catching them ourselves
but raising them ourselves, too.
Any questions now on this use of classes and init and now this ability
to raise exceptions when something goes wrong inside of the initialization?
AUDIENCE: So what if the user has a middle name--
name, middle name, and last name?
How would you fix that?
DAVID J. MALAN: Good question.
If you wanted the student to have a first name, middle name, and last name,
we could do this in a bunch of different ways.
The simplest, though, if-- let me clear my screen here, and let
me just temporarily do this.
Let me propose that the init method take in a first argument, a middle argument,
and a last argument.
And then what I think I would do down here is ultimately have first = first,
and then I would do the same thing for middle and last.
So middle and middle, and then last and last.
And then what I would have to do here is,
when I actually ask the user for their name,
I might need to really go all out.
I might need to ask them first for their first name
and store that in a variable called first, and therefore pass in first.
I might similarly need to ask them for their middle name
and store that in a variable and then pass in a second argument, middle.
And then lastly, if you will, let me go ahead and create
a third variable called last, get the input for their last name,
and pass that in as well.
I could instead just use one input and just ask them for their whole name.
So type in David Malan, Enter, or David J. Malan-- all three of them,
and maybe I could use Python's split function,
maybe a regular expression to tease it apart.
That's probably going to be messy because there's
going to be people who don't have just two or three names.
They might have four or five.
So maybe sometimes it's better to have multiple prompts.
But that's not a problem because, with a class,
we have the expressiveness to take in more arguments if we want.
We could even take a list if we wanted.
But I think we'd probably want to have even more error checking then,
not just for name but for first, and then maybe for middle, and then
maybe for last.
So it just is more and more code, though there would be
ways to perhaps consolidate that, too.
Let me undo all of that and see if there are other questions now on classes.
AUDIENCE: I assume classes are something I
might do at the beginning of a project.
Can I just put them in a different file and import them
into my project, or my main code as needed?
DAVID J. MALAN: Absolutely.
A really good question.
You could imagine wanting to use this student
class, not just in student.py but in other files or other projects of yours.
And absolutely, you can create your own library of classes
by putting the student class in your own module or package,
per our discussion in the past about libraries more generally.
And absolutely, you can do that.
And later today, what we see is we've actually
been using classes-- you and I-- before, in third party libraries.
So you, too, can absolutely do the same.
How about one more question on classes?
AUDIENCE: Can you have optional variables in classes?
And two, can you have your own error names, like--
let's be egotistical and say I want to raise Eric error?
DAVID J. MALAN: Short answer, yes.
These init functions are just like Python functions more
generally, even though they're special in that they're
going to get called automatically by Python for you.
But if you wanted to make house optional,
you could do something like this.
You could give it a default value in the init function's signature
so to speak-- in that first line of code on line two.
And that would allow me to not have to pass in house.
In this case, I'm going to continue to always pass in name and house,
but you could make things optional.
And yes, to your second question, if you wanted to have your own error message,
like an Eric error, you could actually create your own Eric error exception.
And we'll see, in a little bit, that there's actually
a whole suite of exceptions that exist, and you, too, can invent those as well.
Let me propose, though, that we now introduce
one other aspect of this whereby we try printing out what a student looks like.
At the moment, if I scroll back down to my main function,
I'm still printing the student's name and house very manually.
I'm going inside of the object, doing student.name,
and I'm going inside of the object again and getting student.house,
just to see where the student is from.
But wouldn't it be nice if I could just print the student,
like I've been printing for weeks--
any, int, or float, or str, or any other data type?
Well, let's see what happens if I just try printing the student,
instead of manually going inside and trying to create that sentence myself.
Well, in my terminal window-- let me go ahead and run Python of student.py
again.
Let me type in Harry.
Let me type in Gryffindor.
And voila, Harry-- whoa, OK, main student object at 0x102733e80.
Well, what is going on?
Well, if you were to run the same code, you
might actually see something different on your computer
in terms of that number.
But what you're really seeing is the underlying representation, as a string,
of this specific object.
In particular, you're seeing where in the computer's memory it is.
This number, 30x102733e80, refers to, essentially, a specific location
in the computer's memory or RAM.
That's not really that interesting for me or you or, generally speaking,
programmers, but it's just the default way of describing,
via print, what this thing is.
But I can override this as well.
It turns out that there are other special methods in Python
when it comes to classes--
not just underscore underscore, init, underscore underscore,
but, continuing in that same pattern, underscore underscore, str,
underscore underscore.
So this, too, is a special method that, if you define it inside of your class,
Python will just automatically call this function
for you any time some other function wants to see your object as a string.
Print wants to see your object as a string.
But by default, if you don't have this method defined in your class,
it's going to print out that very ugly esoteric incarnation thereof,
where it says main__.Student object at 0x, dot, dot, dot.
Well, how can I then define my own str function?
Well, here, back in VS Code, let me propose that I go in
and define not just __ init, but let me define a second function in this class
here, as follows--
def __ str __.
There are two.
Even though the font in VS Code is putting the two underscore so close,
it just looks like a longer underscore.
There are indeed two there, on the left and the right just like for init.
This one only takes one argument that, by convention, is always called self
so that you have access to it.
And then, indented below that after a colon,
I'm going to go ahead and create a format string and return it.
So let me go ahead and return--
how about something generic first like "a student."
So I'm not going to bother even trying to figure out
what this student's name or house is.
I'm just going to always return "a student."
Let me go back now to my earlier code, which has print (student) on line 16.
Let me clear my terminal window and rerun Python of student.py, Enter.
Type in Harry, type in Gryffindor.
Last time, I saw that very cryptic output.
This time, I see, more generically, "a student."
More readable but not very enlightening.
Which student is this?
Well, notice that the double underscore str method takes in this self argument
by default. It's just the way the Python authors designed this method.
It will always be passed a reference to the current student object.
What do I mean by that?
When this line of code on line 6 is called,
print, because it's hoping it's going to get a string,
is going to trigger the underscore underscore, str, underscore
underscore method to be called.
And Python, for you, automatically is going to pass into that method
a reference to the object that's trying to be
printed so that you, the programmer, can do something like this.
Here's an f string with double quotes as usual.
I'm going to use some curly braces and say print out
self.name from self.house.
So there's nothing new in what I've just done.
It's just an f string-- an f on the beginning,
two double quotes, a couple of pairs of curly braces.
But because, automatically, this str method gets passed self, so to speak,
a reference to the current object, I can go inside of that object
and grab the name.
I can go inside that object again and grab the house.
So now, when I go back to my terminal window--
previously it just printed out a student.
But now, if I run Python of student.py, Enter--
type in Harry, type in Gryffindor, and one more time hit Enter,
Harry is again from Gryffindor.
But if I run this yet again--
let's, for instance, do Draco is from Slytherin, Enter.
Draco's from Slytherin.
Now it's customized to the specific object that we're trying to print.
Questions on this function here--
this Dunder str method.
AUDIENCE: Is there anything else that the underscore underscore,
str method can do?
The other question is, what's the difference between str and repr.
DAVID J. MALAN: A good question.
So there are many other methods that come with Python classes
that start with underscore underscore.
We're just scratching the surface, and we'll pretty much
focus primarily on these.
But yes, there are many others, and we'll
see at least one other in just a little bit.
Among the others is one called repr, which is
a representation of the Python object.
Generally speaking, the underscore underscore, repr,
underscore underscore method is meant for developers' eyes.
It typically has more information than "Harry from Gryffindor."
It would also say what type of object it is, like a student, capital
S, whereas underscore underscore, str, underscore underscore is generally
meant for users--
the users of the program, and it's meant to be even more user-friendly.
But both of those can be overridden as you see fit.
Well, let me propose now that we pick up where we've left off on student
and just add even more functionality, but not just these special methods
like double underscore init and double underscore str.
Let's create our own methods because therein lies the real power
and flexibility of classes if you and I as the programmers
can invent new functionality that's specific to students.
For instance, students at Hogwarts, over the time in school,
learn how to cast a certain type of spell.
So when they say, Expecto Patronum, something
comes out of their wand that typically resembles
an animal or something like that.
It's a special spell that they have to practice and practice.
So let's see if we can't store, not just the student's name and their house,
but also their "patronus," what, actually, they
conjure when using this spell.
Well, let me go ahead and clear my terminal window.
And in the top of my code here, in the init method of Student, let me go ahead
and start expecting a third argument, in addition to self, which automatically
gets passed in, called patronus.
And I'm not going to worry, for now, on validating
the patronus from an official list of valid patronuses, or patroni.
I'm instead going to go ahead and just blindly assign
it to self.patronus = patronus, and we're
going to let the user type whatever they want for now.
But I could certainly add more error checking
if I wanted to limit the patronus to a specific list of them here.
Let me go ahead now and prompt the user for this patronus,
as by-- in my get_student function-- defining a variable
called patronus or anything else, prompting the user
for input for their patronus.
And now I'm going to go ahead and pass in that third variable here.
So again, similar in spirit to just adding more and more attributes
to the class, I'm going to pass in all three
of these values instead of just two.
I'm not going to do anything interesting with that value yet.
But just to make sure I haven't made things worse by breaking my code,
let me run Python of student.py.
I'll type in Harry.
I'll type in Gryffindor.
And it turns out his patronus was a stag, .
And hit Enter I haven't seen what his patronus is in my output
because I didn't change my str method yet.
But at least I don't have any syntax errors.
So at least I've not made anything worse.
But suppose, now, I want to have functionality, not just
for initializing a student and printing out a student.
If my class is really meant to be a student, what I can do
is not just remember information about data about students.
What's powerful about classes, unlike dictionaries alone,
is that classes can have, not just variables or instance variables--
those attributes we keep creating.
They can also have functions built in, a.k.a.
methods.
When a function is inside of a class, it's called a "method,"
but it's still just a function.
At this point, we've seen two functions already-- two methods--
called a double underscore init and double underscore str,
but those are special methods in that they just work.
If you define them, Python calls them automatically for you.
But what if you wanted to create more functionality for a student
so that your class really represents this real world, or maybe "fantasy"
world notion of a student, where students not only have names and houses
and patronuses; they also have functionality.
They have actions they can perform like casting a charm, a spell, magically.
Could we implement, therefore, a function called charm, that
actually uses their magical knowledge?
Well, let's go ahead and define our very own function as follows.
Let me clear my terminal window, scroll back up to my student class.
And instead of creating yet another function that's special,
with double underscores, I'm going to invent my own function, or method,
inside of this class.
I want to give Harry and Hermione and all of the other students
the ability to cast charms, so I'm going to define a function that I
can completely, on my own, call charm.
I could call this function anything I want.
But because it's a method inside of a class,
the convention is that it's always going to take at least one argument, called
self, by convention so that you have access to the current object,
even if you don't plan to use it, per se.
All right, let me go ahead and propose that we implement charm in such a way
that the method returns an emoji that's appropriate for each student's
patronus.
How to implement this-- well, inside of the charm method,
let's go ahead and match on self.patronus,
which is the instance variable containing a string that
represents each student's patronus.
And in the case that it matches a stag, for instance, for Harry, let's go ahead
and return maybe the closest emoji--
this horse here.
How about in the case of an otter?
Well, in that case, let's go ahead and return, oh, maybe the closest match
to the otter, which might be this emoji here.
And let's see, in the case of a-- for Ron, rather than Hermione--
a Jack Russell terrier, let's go ahead and return--
don't have as many options here.
Why don't we go ahead and return the cutest available dog in that case.
And in the case of no patronus recognized,
as might cover someone like Draco, let's go ahead
and use a default case using the underscore as in the past,
and let's go ahead and return for this-- oh, what should happen
if someone doesn't have a patronus?
Why don't we just see a magical wand that
seems to fizzle out, as in this case?
All right, well, now, rather than just print the student,
let's go about printing their actual patronus.
So I'm going to go down to my main function here.
I'm going to still get a student, using the get_student function.
But rather than print student, let's go ahead and declare "Expecto Patronum!"
printing out just that as pure text.
And now let's go ahead and print out, not the student but, rather,
the return value of their own charm method.
So let me go back down to my terminal window and run Python of student.py
and Enter.
Name-- let's start with Harry.
He lives in Gryffindor.
Patronus is a stag.
And let's see--
Expecto Patronum!
And of course, we'd see the stag emoji.
What about someone like Draco, who, at least in the books,
doesn't have a known patronus?
Well, let's go ahead and clear my terminal window,
rerun Python of student.py, and this time, let's type in Draco for name,
Slytherin for house, and Patronus is unknown.
So I'm just going to go ahead and hit Enter.
And now, Expecto Patronum!
And it just of sizzles instead.
Questions now on what I've done by implementing this charm method.
AUDIENCE: Can we call a method outside the function?
DAVID J. MALAN: Absolutely.
And we're seeing that already.
If I scroll back down to my main function
which is outside of the class--
because it's all the way down in the file;
it's all left aligned, just like the class, notice on line 28,
I'm calling student.charm.
And I'm accessing a method that's inside of the student object,
even though my main function is outside of the class.
And what's different between our init function, or method, and our str method
that we've seen before--
those are called automatically when you try to create a student
or when you try to print a student.
For the first time, we're now seeing a method
that I invented inside of the student class that I can call anywhere I want.
And if I'm calling it outside of the class like I am here,
I just use the name of the variable containing
that student object, and I just do dot charm,
just like I could access the individual attributes or instance variables
inside of that object as well.
Other questions on classes and this new method, charm?
AUDIENCE: In the parentheses, you put self.
It's supposed to be an initializer.
But in the top part, you didn't define it the same way.
Would you have to put the class on-- why you didn't put the class right there?
DAVID J. MALAN: So notice the indentation here.
So on line 1, I've of course said class Student colon, and then everything
below that is indented at the moment.
That means that my init method, my str, method and this new charm method
are all inside of part of that class.
By convention then, each of these methods inside of a class
should expect that Python will automatically
pass in at least one argument to every method in a class,
and that argument will always be a reference to the current object,
the Harry object, or the Draco object that is currently
trying to cast a charm or be printed.
So whenever you create a method inside of a class
you should always have it take at least one argument called self
and then zero or more other arguments that are entirely up to you. init,
for instance takes three more. name, house, patronus, str
takes zero more charm, takes zero more.
But the convention is to always call that default argument "self,"
and Python just automatically gives you access to the current object.
Other questions?
How about one more, on classes and charms?
AUDIENCE: Sir, I just wanted to ask that you have put them all in double quotes.
So a does it take the emojis as a form of strings or something else?
DAVID J. MALAN: Yes, if unfamiliar, an emoji is just a character.
It's part of a mapping of numbers to letters known as Unicode.
And so whenever you see these emoji on the screen,
like the horse or the otter or the dog here,
specifically, that's really just a key from your keyboard.
You and I on Macs and PCs can't typically
type it because you see English characters
or some other human language.
But emoji are increasingly available via menus and dropdown and, in my case,
Copy Paste.
On Macs and PCs and Android devices and iPhones,
they are just characters, even though they look like pictures.
You can think of it like a graphical font almost.
So they're just text.
And indeed, if you put them between double quotes or single quotes
you can print emoji just like you can any other human character as well.
Well, let me propose, now, that we remove this patronus code just
to simplify our world and focus on some of the other core
capabilities of classes.
So at the risk of disappointing, I'm going
to get rid of all of these beautiful emoji and charms,
and I'm going to go ahead and stop asking the user now for their patronus.
And I'm going to stop passing it into init here.
And I'm going to stop doing this here.
And I'm going to instead just go ahead and restore our use of print student
here, and I'm going to go ahead and get rid of patronus down here.
So just essentially undo all of the fun charms we just created.
So we're now back at the point in the story where we have a student class,
with only two methods--
init and str.
The first of those takes, of course, self
as the first argument as it always will, plus two more now-- name and house,
no more patronus.
We're validating name up here.
We're validating house down here.
And then we're assigning name and house, respectively,
to two instance variables called name and house also.
But we use self to get access to the current object,
to store those values therein.
We then still have our str method here, which takes one argument--
by default, self, and that's it.
And that function is going to be called automatically any time
you want to convert a student object to a string,
just like print might want to do here.
So let me go ahead and just make sure I haven't broken anything.
Let me run Python of student.py.
I'll type in Harry.
I'll type in Gryffindor, Enter.
OK, we're back in business.
Gone are the charms and patronus, but at least I'm back to a situation
where I have names and houses.
But it turns out, at the moment, our use of classes
is not very robust, even though we have this mechanism, very cleverly,
if I may, in our init method of making sure
that we're validating name and house, making sure that name is not blank,
and making sure that house is a valid house among those four Hogwarts houses.
It turns out that classes will still let me
get at those attributes, those so-called instance variables,
using dot notation anyway.
Let me scroll down then and try to do this a little adversarially.
Suppose that online 16 I go ahead and call get_student,
which exists as before, and then I store the return value in a student
variable-- again, on line 16.
That will ensure that get_student gets called, which calls input and input.
And then it calls the student constructor,
which invokes, automatically, this init method.
So by way of how we've laid out my code, we're
going to ensure that name is not blank and house is definitely
one of those four values.
My error correction-- or error checking is in place.
But if I'm a little adversarial, I can still circumvent it.
Suppose that-- fine, going to require me to type in Harry and Gryffindor?
I'm going to go ahead and type in student.house
equals, quote, unquote, "Number Four, Privet Drive,"
and you're not going to be able to stop me.
Why?
Well, it turns out, with classes and objects
thereof, you and I can still access those instance variables
using this familiar dot notation.
That's how we began the story of classes-- just setting these attributes
ourselves.
But you can also read these attributes themselves
and change them later if you want.
And this will effectively circumvent the if condition and the other if condition
in our init method because that is only called when you first
create the student object.
There's nothing stopping me, at the moment,
from just changing the house or the name after.
So if I now clear my terminal window and run Python of student.py,
I'll still type in Harry and Gryffindor to meet my requirements
that the house be one of those four.
But when it's printed, notice, I've still overridden it.
So it seems that, while classes do allow us a little more control over the data
we're storing, it doesn't necessarily prevent the user--
or rather the programmer-- be it myself or maybe a colleague,
from still messing things up.
So here, too, in the spirit of programming a little more
defensively, allow me to introduce another feature of Python as well--
namely properties.
So a property is really just an attribute
that has even more defense mechanisms put into place,
a little more functionality implemented by you to prevent programmers, like me
and you, from messing things up like these attributes.
So again, a property is going to be an attribute that you and I just
have more control over.
How?
We just write a little more code, using some Python conventions.
And how we're going to do that is going to use, in just a moment, a feature--
a keyword known as @property, which is technically a function.
Property is a function in Python.
But we're about to see some new @ syntax that allows you to decorate functions.
And this, too, is a term of art.
In the world of Python, you can have decorators,
which are functions that modify the behavior of other functions,
if you will, and we'll leave it at that without going too much into the weeds.
And we'll see, by, example how you can use these decorators,
specifically to define properties.
So let me go back to VS Code here.
And let me propose that I do this.
I'm going to go ahead and create--
how about a property called house as follows.
Inside of my student class, I'm going to go ahead-- and below my init method
and below my str method, I'm going to go ahead and define
a function called house that takes, as it always must, one argument at least,
called self.
And what I'm going to do now is return self.house.
So I'm just going to define a method called
house, whose sole purpose in life is to return the value of house.
But I'm going to define one other method, curiously also called house,
but that's going to take into, as arguments, two values--
self as always and also a value called house.
And I'm going to now do this.
I'm going to do self.house = house.
Now, what have I done?
Well, let me just temporarily add some comments here.
In a moment, we're going to start referring to this generally
as a getter.
And down here, I'm going to refer to this as a setter.
And this is terminology frequently see in the world of Java.
Some of you have programmed in Java before.
But as the names imply, a getter is a function
for a class that gets some attributes.
A setter is a function in some class that sets some value.
And now, even though we're not done, and there's a bit of a mistake in the code
I've already written, intuitively, what we're going to do is this.
We're trying to prevent programmers, myself included,
from circumventing my error checking that I
put into place for name and house.
How can I do that?
Well, we don't have that many building blocks in programming.
We have things like variables for data, and we have functions for actions.
Well, why don't we do this?
Why don't we somehow require that, in order to access an attribute,
you go through some function.
And let's require that, in order to set some attribute,
you go through some function.
And conventionally, those functions are called a getter function and a setter
function.
And why are we using functions or, in this case, methods inside of a class?
Well, once you have functions, those are just actions or verbs
that you and I can create ourselves.
We can put any error correction I want in these functions
because it's code that's going to get executed top to bottom.
So how can I now prevent the user from setting the house to an invalid value?
Let me borrow some logic from before rather than blindly do this-- just set
self.house equal to the house value that's passed in-- let's add our error
checking there.
So if house is not in the following list of Gryffindor or Hufflepuff
or Ravenclaw or Slytherin, just as before,
let's go ahead and raise a value error, just to signify that, uh-uh, something
has gone wrong.
I'll be more explicit.
I'll include a message like, "invalid house," quote, unquote.
Otherwise, I'm going to proceed on, now, line 21 to set self.house to house.
So I've just copied, if you will, or retyped my error checking inside
of this so-called setter function.
Now, why have I done that?
Well, to be clear, whenever the user or the programmer
writes code like this, student.house equals, what's
about to happen magically is Python will not just
let the programmer access student house directly-- that attribute,
that instance variable, a.k.a.
self house.
It's instead going to magically automatically call
this setter function for me.
How does Python know to do that?
Well, if it's see that, on the left-hand side, there is self.house,
where house is the name of the getter or setter, and then it sees an equal sign,
indicating assignment, that's just enough of a visual clue to say,
wait a minute.
I'm not going to let you access that attribute directly.
I'm going to use the setter instead.
Why?
Because the equal sign means I'm trying to set.
I'm trying to assign a value from right to left into that attribute.
So what Python's is going to do automatically
is call this function for me.
And that's amazing because now I can execute code-- an algorithm to check,
do I want to let the user--
the programmer set that attribute to that value?
If not, I'm going to raise a value error,
and you're just not going to be able to do it.
If so fine.
I'll go ahead and set it for you.
But in order to do this, we need a little more syntax.
And I'm going to get rid of my comment, and I'm going to use that decorator.
I need to tell Python to treat this method as a getter.
And then the syntax for the setter is a little different.
You now say house.setter.
I wish one was getter and the other was setter.
That's not the way they designed it.
When you want to define a getter, you just say @property above the function.
And you name the function exactly like you would like the property
to be called-- quote, unquote, "house."
Once you do that, you can now use a new decorator
that's automatically created for you called @house,
because I called it house.
And then you literally say, @house.setter.
And this whole line, on line 17, is a clue to Python
that here comes a function, whose name is identical--
but notice that it takes two arguments-- both self, so you have access
to the contents of the object, and house, which is just
going to be a str that comes from the programmer from the human input return
value so that you can set that value as well.
But there's one fix I need to make now, here.
Everything else, I think, is still good.
However watch this.
I no longer need this error check here.
Why?
Because, if I scroll back down to my code here,
I claimed a moment ago that code like this, with student.house equals,
is going to automatically get Python to call my setter for me.
Guess what?
Even up here, in my init method, calling self.house equals
is also going to call my setter method, which is amazing
because now I can keep all of my error checking in one place in the setter,
and it will now get called either when I create the object for the first time,
because of init, or even if the programmer
tries to circumvent that init method and change the value of this attribute,
my setter will also get called.
My setter will get called any time I access .house.
But there's one fix I need to make.
Unfortunately, I have collided names.
Right now, if we go up here, on line 5, this is an instance variable.
It's a string inside of my self, inside of the current student object,
called name.
And this is another instance variable called house.
Unfortunately, if I have an instance variable called name and house,
I cannot also have functions called house.
They're going to collide.
You've got to decide.
Do you want the variable to be called house?
Or do you want the function to be called house?
Unfortunately, you can't have both because now Python
is going to confuse one for the other.
So the conventional fix for this is to do this--
to have the setter not store the value that's passed in self.house,
but to use an almost identical name, but to use a little indicator that
means you know doing this correctly.
You typically, by convention, put an underscore
in front of the instance variable's name.
And when you return it up here, you similarly put an underscore.
So now, technically, my instance variable is called _house,
but my property, which is a fancier attribute, if you will,
is called house alone.
Huge amount of syntax, I know, but it's a very powerful feature.
And again, this is why you can graduate from dictionaries alone and have
so much more functionality at your disposal.
Let me go ahead and clear my terminal window and run Python of student.py,
Enter, name.
All right, let's go ahead and type in Harry.
Let's go ahead and type in Gryffindor.
Crossing my fingers as always.
And now, look, "Invalid house."
This is a good thing.
Why?
Because, notice, in my main function, I'm
still trying, maliciously, if you will, to change Harry's house
to not be one of the four valid ones.
I'm trying to change it to his childhood home of Number Four, Privet Drive.
But because Python knows that, wait a minute, you're trying to assign--
that is, set a value--
and that value, a.k.a. house, is now defined
as a property you're going to have to go through the setter function instead
to even let you change that value.
And because I have this raise ValueError.
If the house is not as intended, you're not
going to be allowed to change it to an invalid value.
So I'm protecting the data on the way in, through the init method,
and I'm even defending the data if you try to override it there.
So I think the only solution for me, the programmer,
is, don't try to break my own code.
Let me remove that line because it's just not going to work.
Let me run Python of student.py and, again, type in Harry;
type in Gryffindor, Enter, and Harry's indeed from Gryffindor.
If I did something incorrect, like Harry from Number Four,
Privet Drive, Enter, we're again going to see the value error
because my code just doesn't let that value in via manual input now
or via that adversarial change.
All right, that was a lot.
But any question on properties?
AUDIENCE: Why we are using getter then setter?
It's just for the purpose so that we can find
that method, that function in our code.
DAVID J. MALAN: The reason that I'm going through the trouble of defining
this getter or setter is because I want to make sure that programmers cannot do
things like this.
If I'm going through the trouble of validating
the attributes for these student objects,
I don't want you to be able to go in there and just change them at will.
I want to have some control over that object
so that you can just trust that it's going to be correct as designed.
So using a getter and setter really just enables
Python to automatically detect when you're trying to manually set a value.
The equal sign and the dot, as I've highlighted here,
is enough of a clue to Python to realize, wait a minute,
you're trying to set a value.
Let me see if this class has a setter defined.
And if so, I'm going to call that, and I'm not just
going to blindly assign the value from right to left.
So it's just giving me more control.
Other questions on properties.
AUDIENCE: When we use getters, we just have just one argument.
And if we use setters, it's always going to be two arguments?
Is that normal?
DAVID J. MALAN: Correct.
It's always going to be one argument-- self
for the getter, two arguments for the setter-- self and something else.
And the intuition for that is, if you're getting a value,
you don't need to pass anything else in because you already know the object.
It's called student in this case.
So you're just going to get the value of that property.
But if you want to set the property to something else,
you've got to pass in that argument.
You've got to pass in the value to which you want to set it.
So it's always 0 or 1.
However, you see it as 1 or 2 because, again, any function inside of a class,
a.k.a.
a method, is going to be automatically passed self so that you have access
to that current object in memory.
How about one other question on properties?
AUDIENCE: Why didn't we use the same underscore house init method?
DAVID J. MALAN: A good question.
So even though I'm using the underscore house here, in my setter,
and the underscore house here, in my getter,
I deliberately did not use it up here.
The reason for that is that, by using self.house and this equal sign,
that's the same pattern that I want Python to recognize.
I want Python to automatically call the setter,
even when I'm passing in the house via the init method.
If I were to change this to do this, that would circumvent the setter,
and now there's no error checking in init whatsoever.
So it's such a fine line.
The only thing standing between us and error checking or no error checking
is the presence or absence of this underscore.
But that's typically the convention.
By not using the underscore there, make sure
that even that assignment goes through the setter
so that, honestly, I, don't have to copy paste the same error
checking in two places.
I can put it just in the setter.
So it's a better design, and that's why I manually retyped it at first,
but then I deleted it from init.
Well, allow me to propose that we make one other change to this file.
Might as well go ahead and define a property for name as well.
And let me go ahead and do this-- maybe above the house property
just to keep things in the same order as I defined them earlier.
Let me give myself another property.
This one is going to be called name.
It's going to take one argument called self, as always.
And this one, very similarly, is just going to return self._name.
So I'm going to anticipate that I'm going
to have to rename name also so that I don't have that same collision as
before.
But now let me go ahead and define another setter--
this one for name.
So the convention is @name.setter.
Why name?
Because the property I just created is called name.
So the getter and setter work in conjunction in this way, if you will.
Let me go down under that name setter and define another function,
also called name.
But the key thing here is that it's not identical.
It's not the exact same function name and the exact same number of arguments.
The setter, again, takes a second argument.
And I can call it anything I want, but I'm
going to call it name because that's what's being passed in.
And I'm going to put my error checking here.
If not name, just like we used to do, let's go ahead and raise a value error,
and let's put an explanatory message like "Missing name," quote, unquote.
Otherwise, let's go ahead and update self._name to equal name.
And I don't have to change init except to get rid
of this duplicate error checking now because, again,
if I use self.name equals here and self.house equals here
with no underscore, both of those assignments
are going to go through my two setter functions now.
Before we run this, let me go ahead and remove
this adversarial code, which we know won't work because we're catching it.
Let me go back down to my terminal window and run Python of student.py,
Enter.
Let's type in Harry.
Let's type in Gryffindor.
And that seems to work.
Let's try though, again, to run Python of student.py
with Harry from Number Four, Privet Drive.
This will not work.
A value error with invalid house, because that's not
one of the four Hogwarts houses.
And now, for good measure, let's run it one more time.
And let's not even give it a name.
Let's just hit Enter when prompted.
I can type anything for the house.
I'll go ahead and still give it Gryffindor, Enter.
And now we get another value error, but this one is for missing name.
So we seem, now, to have all the more of a defense mechanism in place
to ensure that name is as we expect.
It's got to have some value that's not blank.
And house is as we expect.
It's got to have one of those four values.
But at the risk of bursting everyone's bubble
and making you wonder, why did we just go through all of that,
unfortunately Python really focuses on conventions, not hard constraints.
And by that, I mean this.
If I go back into my main function after I've gotten a student on line 30
and I try to adversarially do something like this-- student.house equals
"Number Four, Privet Drive," we know this
won't work because my setter for house is going to catch this.
Watch again.
Python of student.py.
Let's type in Harry.
Let's type in Gryffindor, which will at least pass
our check that's induced by init.
But line 31 is going to trigger the same setter to be called,
and we're going to raise a value error saying "Invalid house."
Unfortunately, and if some of you are already
thinking a little adversarially, tragically, look what you can do.
You can change .house to be ._house.
Why?
Well, the instance variable is now called _house.
The property is called house, no underscore.
But the underlying attribute implemented as an instance variable is still called
_house.
And tragically, Python of student.py.
Let's type in Harry.
Let's type in Gryffindor, which is correct.
But watch what happens now.
Oh, my God.
We slip through.
So what was the point of all of this emphasis from me
on doing things the "right way," the Python quick way by having this getter
and setter?
Well, unlike languages like Java, that just
prevent you from doing things like this, Python
itself allows you to specify that certain instance variables can
be public and accessible to anyone's code, or protected,
or private, which means that no one else should be able to change these values.
In the world of Python, it's just the honor system.
It's not baked into the language itself that there's
a notion of visibility, public or private or even somewhere in between
protected.
Instead, you're on the honor system.
And the convention generally is, if an instance
variable starts with an underscore, please don't touch it.
Just don't.
That's on you if you touch that variable and break things.
The underscore is meant to signify a convention
that this is meant to be "private," but it really just
means, please don't touch this.
Sometimes, if there's two underscores, which you can use,
too, that's an even greater effort by programmers to say,
really don't touch this.
But technically speaking, there's nothing stopping you or me
from circumventing all of these mechanisms, these properties,
these getters and setters.
We're ultimately just on the honor system
not to do so when we see instance variables prefixed with one,
or perhaps even two underscores.
All right, so this is a lot all at once--
this Introduction to object-oriented programming.
But it might come as quite a surprise that, even though we
might have identified OOP by name in weeks past,
we've all been using classes and objects for weeks now in this class.
In fact, if you think back on one of the very first things we did in this class,
we used integers and just got integers from the user.
But if you haven't already--
if you go and dig into the documentation for integers,
which, again, lives at this URL here, you
would actually find that int itself is and has been for weeks a class.
And in fact, this is the signature of the constructor call for an int,
whereby you pass in x, like a number, quote, unquote, "50" or, quote,
unquote, something else-- you pass in optionally the base--
10 for decimal, 2 for binary or anything else.
And that int function will actually return to you, all this time,
an object of type int.
That is to say int is a class.
It is a template, a blueprint for creating integers in memory.
And any time you and I have converted a string, for, instance to an int,
you and I have been creating an object of type int that was calling,
apparently, the underscore underscore, init, underscore underscore method,
that someone else-- the authors of Python--
wrote to give us back that proper integer.
Besides that, if you can believe it, strs, strings in Python
have been classes since the first week of this class as well.
If you look up the documentation for a str,
which lives at a similar URL there, you will find that, when you instantiate--
that is, create a str--
it takes, optionally, a parameter called object here,
the default value of which is just, quote, unquote,
which allows you to create, in effect, an empty string, a blank string,
if you will.
But any time you and I have created strs or even used explicitly
the str function, you are getting back an object of type str.
Any time you and I have forced a string to lowercase per the documentation,
using syntax like this, you and I have been taking an object of type str
and forcing it all to lowercase by calling a method called lower,
a method that the authors of Python built into the str class,
but it's been there from the get-go, so this notion of methods is not
even new today.
You wouldn't have been doing it for this long.
If you've ever called strip to remove the leading and the trailing whitespace
from a string in Python, you are calling another method that came with Python--
written by the authors of Python.
And even though we didn't call it a class at the time,
a str, all this time, has been a class.
And instances of strings are, themselves, objects.
And those objects come therefore with these functions
built in-- a.k.a. methods that allow us to do things like force
to lowercase and strip whitespace from the beginning and end.
Let's do another.
list-- any time you've created a list, either syntactically with square
brackets or literally with L-I-S-T, open parentheses, closed parentheses,
which is also possible, you have been using a class.
If you go to the documentation for list, at this similar URL
here, or more specifically, the tutorial on lists here in Python,
you will see that a list is and has been,
since the early weeks of this class, a class itself.
And that list class takes, as part of its initialization,
an optional iterable, something that can be iterated over-- like 1, 2, 3,
or some list of values, and you can then get back
a list containing those same iterable values.
If you've ever appended something to a list in this class,
as I have myself in the past, you've been
using a method called append that comes with the list class that, per the x
here, takes an argument that allows you to append something
to the current list, a.k.a.
Self in the context of that method.
We can do this all day long.
If you've used a dictionary or a dict in Python--
I've actually, all this time, been calling them dict objects,
and that's for a reason.
dict itself is a class in Python, if you pull up
its official documentation here.
And you'll see that it is defined, indeed, as itself a class.
And that class comes with methods as well.
And so any time we've manipulated dictionaries,
we've been underneath the hood, using all of those same methods.
And in fact, we can see this if we're really curious.
Let me go back over here to VS Code.
And let me go ahead and create a new file that, very simply, does
something play around with data types.
And let me go ahead and create a new file, for instance,
called, say, type.py, just so that I can poke around inside of some values.
And in type.py, I'm just going to go ahead and do this.
I'm going to print out whatever the type is of, say, the number 50.
And This is a function you've not necessarily seen me use already,
and it's not one you would frequently use in your own code.
There are other ways to detect, if you need to,
what the type is of a variable.
But in this case, type of 50 is just going to tell me and then print out
what the data type is of that value.
Now, hopefully, all of us could guess that 50 is indeed
going to be an integer--
that is, an int, but we can see it in this way.
And this, too, is what's powerful about knowing a bit of programming.
If you want to know the answer to a question,
just try it out, like I am here.
So let me go ahead and run Python of type.py, Enter.
And there it is.
When you print out the type of the number 50, you'll see on the screen,
in this cryptic syntax, class 'int.'
This is not something that you probably want to show to the user.
But if you yourself just want to poke around and see what's going on
or maybe use that information somehow, it's
certainly at your disposal to use this type function for that.
Let's change it around a little bit.
Instead of passing as the argument to type 50, as an int,
let's type something also familiar, like "hello, world,"
in double or single quotes.
Let me go back to my terminal window, clear the screen,
and run Python of type.py again.
And now, voila, there it is.
All this time, a str is also a class.
We can do this a few more times, For.
Instance.
Let's go ahead and change "hello, world" to just an empty list--
open square bracket, closed square bracket.
And this is starting to look a little cryptic,
but, again, notice what I'm doing.
In square brackets is an empty list.
We've done that before.
That is the sole argument to this new type function.
And that's just being passed to the print function
so that the return value of type is the argument to print.
So if I now run this code, Python of type.py, there it is.
A list is a class, too.
You might recall that I said that you can also create an empty list
by literally doing list ().
This is a bit of an inconsistency, as we can now
identify that int and str and now list-- they're technically all lowercase.
And I went to great lengths of creating my student class to have that capital
S. That's a convention.
Because int and stir and list and others come with Python,
they decided to make their built-in data types-- even though they're classes--
all lowercase.
But the convention, the recommendation in the Python community when creating
your classes is to capitalize the first letter, as I did,
in something like Student, capital S. But list () is identical to really just
two empty square brackets.
If I clear my screen and run type.py again, you see the exact same thing.
The class is called list.
Let's do one more.
Let me change the list to be not square brackets but curly braces.
We've done this before.
Any time I've done two curly braces with nothing in between, this, of course,
is an empty dictionary, or a dict object in Python.
Well, we can see that now.
Let me clear my screen, run Python of type.py, Enter,
and there it is-- class 'dict."
It's been there this whole time.
We just didn't call it a class until today.
I can similarly do this one explicitly.
Instead of two curly braces, let's write out dict with two parentheses.
Now we have a lot of parentheses again, like with list.
But this is just making even more clear that the type of a dict object
is indeed the class, dict, itself.
So this is to say that, as new as a lot of today's idea and syntax,
might be you've actually been using it, perhaps unbeknownst to you,
for weeks now.
We now just have terminology to describe what
it is we've been doing all this time.
And you now have the expressiveness, with some practice,
to create your own classes, inside of which are your own instance variables,
perhaps wrapped with those properties and your own instance methods.
But it turns out there's other types of methods in the world.
Thus far, I've been deliberate in calling
all of our variables instance variables and all of our methods instance
methods.
It turns out there's other types of variables and methods out there,
and one of those is called class methods.
It turns out that sometimes it's not really necessary or sensible
to associate a function with objects of a class,
but rather with the class itself.
An instance, or an object of a class, is a very specific incarnation thereof.
Again, on that neighborhood that has a lot of identical looking buildings,
but they're all a little bit different because of different paint and such,
sometimes you might have functionality related
to each of those houses that isn't distinct or unique for any
of the houses.
It's functionality that's going to be exactly the same no
matter the house in question.
Same in the world of object-oriented programming.
Sometimes you want some functionality, some action
to be associated with the class itself, no matter what the specific object's
own values or instance variables are.
And for that, we have a keyword called @classmethod.
This is another decorator-- really, another
function-- that you can use to specify that this method is not,
by default, implicitly an instance method that
has access to self, the object itself.
This is a class method that's not going to have access to self,
but it does know what class it's inside.
So what do I mean by this?
Well, let me go back to VS Code here.
And let me propose that we create a new file this time implementing
the notion of a-- the sorting hat, from the world of Harry Potter as well,
to stay on theme.
I'm going to go ahead and run code of hat.py.
And in hat.py, let's implement the notion of the sorting hat.
If unfamiliar in the books and in the films
there is literally a pointy hat that, when
a student put it's on their head, that sorting hat, so to speak,
decides what house the student is in-- whether it's
Gryffindor or something else.
So let's implement, in code, this notion of a sorting hat such that,
when we pass to the sorting hat the name of a student, like, quote, unquote,
"Harry" this sorting hat, implemented in code,
will tell us what house that student should be in.
Well, let's go ahead and do this.
In hat.py, first, let's go ahead and define a class called hat,
and then let's get back to implementing it itself.
And I find this to be a helpful technique, not just with teaching
but when writing code.
I know I want a hat class.
I don't necessarily know what I want it to do yet,
so I'm going to create this placeholder, dot, dot, dot,
so I'll come back to that.
Let's now try to use this class as though it existed.
And from there, I perhaps can realize exactly what
functionality that class needs to have to support my use case.
Let me go ahead and create a variable called hat in all lowercase
and instantiate a hat object.
So no matter what the hat class ends up looking like,
this is the common syntax for instantiating
an object of a certain class.
In the past, we saw student, all lowercase,
equals capital Student, open parenthesis, close parentheses,
and then eventually, we added in things like name and house.
For now, let's assume that the hat is much simpler than a student,
and it only has sorting capabilities.
So I'm not going to even pass any arguments there, too.
Let me assume that the sorting hat has one function-- one method inside of it
called, sort.
And so if I do hat.sort ("Harry"), let's propose that that prints out what house
that student should be in.
So that's it.
I'm going to encapsulate--
that is tuck away inside of a hat class--
all of this requisite functionality, and I'm going to print out onto the screen
what hat--
what house Harry belongs in.
Now I think I need to get into the weeds of actually initializing this class.
Well, let me go ahead and do this.
If I don't care to parameterize hat--
I just want to, for instance sort values,
let's go ahead and define this function, sort, first.
So let's define sort, as taking a first argument, self,
which is always going to be the case when defining an instance method as
before.
But the sort method clearly takes one argument from the programmer, me--
namely the student's name.
And again, we've seen this dichotomy before.
Even though I'm trying to pass in one argument, when I define the method,
it's got to take that many arguments, plus one more--
self which is always going to be automatically passed in by Python
first.
What do I want to do?
Well, let's go ahead and do something like this.
Print, this name-- how about "is in," "some house."
I'm going to, again, use some placeholder code
for myself because I'm not quite sure how to finish implementing this sorting
hat.
But I think that's enough to just test where my code is at now.
Let me go ahead and run Python of hat.py and hit Enter.
And it looks like, indeed, Harry is in some house.
We're not done yet because it's clearly not doing anything interesting,
but it at least is running correctly with no errors.
Well, let's go ahead now and decide where--
what house Harry should actually be in by introducing a bit of randomness
and choosing a house randomly.
While I can do this in a few ways, Let.
Me go ahead and do this.
I need to have a list of houses somewhere.
So where can I put that?
I could solve this problem in different ways.
Let me propose that I do this.
Let me define a method called init, as I've done before,
that takes in self, but no other arguments.
And whenever the sorting hat is instantiated, let's do this.
Let's create a houses instance variable, plural, that equals this list--
Gryffindor, Hufflepuff, Ravenclaw, Slytherin,
so the exact same list that we've used before,
and I'm storing it in an instance variable inside of this class.
I'm not taking any arguments beyond self to init,
but I just need this list of values somewhere, for instance.
So what can I do here?
Well, let me go ahead and replace some house with the actual house.
Well, what could I do here?
Well, I want to put a house there.
Well, let's go ahead and create a variable called house.
And if you think back to our discussion of libraries, in the random module,
there is a function called choice that, if you pass in a list of choices,
like self.houses, that will pick a random house out of those four.
And then on line 7, I can pass it in.
If I want to tighten this up, let me just go ahead and highlight that code,
get rid of the variable.
It's technically unnecessary.
And because the line of code is still pretty short,
I'm OK with just putting it all in one line.
But I could certainly use the variable like I did a moment ago.
So what have I done?
In my init function, I have defined a initialization of the object
that stores in self.houses the list of four houses.
And then, in sort, I'm accessing that same list,
but I'm randomly choosing the set of houses there.
Now, why have I done it in this way?
This, too, is general convention.
Any time you have a list of things that-- who knows?
Maybe will change over time.
Places like Harvard have constructed new houses over the years,
so you might have to change the list of available houses.
It didn't happen in seven books or eight films of Harry Potter.
But you could imagine maybe Hogwarts eventually
has a fifth house, so there's generally some value in putting list of constants
toward the top of your file, toward the top of the class so it's just
obvious what the list of values is.
You don't want to necessarily tuck it away in some function,
like sort, especially if you might want to use that function--
sorry, especially if you want to use that list in multiple functions, not
just sort.
But if I kept adding to this class, you might
want to use that same list of houses in multiple functions.
So let's keep it in the object itself by storing it in self.houses.
All right, well, we're about to change the course of history here perhaps.
Let me do Python of hat.py, and I think we're about to assign Harry
to one of those four houses randomly.
Huh, NameError.
Name 'random' is not defined.
Well, wait a minute, where did I go wrong here?
Thinking back to our class on libraries, why did my code break and not tell me
where Harry is to be?
AUDIENCE: You did not import the random library.
DAVID J. MALAN: Exactly.
If the random library or module is something I want to use,
I need to tell Python that at the top of my file.
So let me go up here and do import random.
And then, below that, let me go ahead and clear my terminal window
and try again.
Python of hat.py, crossing my fingers, seeing where Harry is going to end up.
And, OK, Harry as of now is officially in Hufflepuff,
despite everything you've read or seen.
Well, let's run this again.
Let me clear my window and run Python of hat.py, and now he's in Ravenclaw.
That's consistent with using random.
Let's clear that and run it again.
He's still in Ravenclaw, but that could happen,
even though there's four choices.
Let's do it again.
Hufflepuff-- back in Hufflepuff.
We can't seem to get the right answer.
Now he's in Gryffindor, albeit randomly.
So we seem to have a program that, based on these limited tests,
seems to be assigning Harry to a house randomly.
Now I'm somewhat lazily just letting sort print out this value.
I could do something else, like return a string, and then let me, on line 13,
do the printing for me.
But for now, I think we have an example of a class called hat that,
nonetheless, applies some of our lessons learned thus far today,
where I've created a class-- because a sorting hat is, frankly--
well, I was about to say real world entity, but really
a fantasy world entity.
And indeed, that's a, perhaps, common heuristic or mental model to have.
When should you use a class to represent something in your code?
Very often, when you're trying to represent some real world entity
or fantasy world entity, like a student, which is something in the real world,
like a sorting hat, which, OK, doesn't exist,
but hat's certainly do, so quite reasonable to have a class for hat.
And that's not always the case that classes represent real world entities.
But we've seen thus far that int and stir and list and dict-- these
are all structures that you might have in the real world.
We have integers and strings of text and other things.
So it rather makes sense to represent even those things, more technically,
using a class as well.
You could use just a dictionary to represent a student or a hat.
But again, with classes come all this and even more functionality.
But I honestly am not using classes in, really, the "right way" here.
Why?
Well, in the world of Harry Potter there really is only,
to my knowledge, one sorting hat.
And yet, here I have gone and implemented a class called hat.
And again, a class is like a blueprint, a template,
a mold that allows you to create one or more objects thereof.
Now, most of my programs Thus far have been pretty simple,
and I've just created one student.
But certainly, if I spent more time and wrote more code,
you could imagine writing one program that
has a list of students-- many more students
than just the one we keep demonstrating.
Yet it would be a little weird--
it's a little inconsistent with the real or the fantasy
world of Harry Potter to instantiate one, two, three or more sorting hats.
There really is just one.
Really one singleton, if you will, which is
a term of art in a lot of contexts of programming.
So let me propose that we actually improve the design of the sorting hat
so that we don't have to instantiate a sorting hat because right now this
is kind of allowing me to do something like hat 1 = hat, hat 2 = hat, hat 3 =,
and so forth.
I don't really need that capability.
I really just need to represent the sorting hat with a class,
but I don't really need to instantiate it.
Why?
Because it already exists.
I need just one.
So it turns out, in Python, that, up until now,
we've been using, as I keep calling them, instance methods--
writing functions inside of classes that are automatically passed a reference
to self, the current object.
But sometimes you just don't need that.
Sometimes it suffices to just know what the class is
and assume that there might not even be any objects of that class.
So in this sense, you can use a class really as a container for data
and/or functionality that is just somehow conceptually related--
things related to a sorting hat.
And there's this other decorator or function called @classmethod
that allows us to do just this.
So let me go back to my code here.
And let me propose that, if I'm not going to instantiate multiple houses,
I don't really need this init method because that's really
meant to initialize specific objects from that blueprint, that template,
that mold.
So let me get rid of this.
But if I get rid of this, I no longer have access to self.
But that's OK because it turns out, in addition to their existing class
methods, there are also what we might call class variables.
And class variables exist within the class itself.
And there's just one copy of that variable
for all of the objects thereof.
They all share, if you will, the same variable-- be it an int or str
or, in this case, a list.
So what I've done here is define, inside of my hat class, in a class variable
called houses--
I don't say self because self is no longer relevant.
Self refers to specific objects.
I want a variable inside of this class, a.k.a.
A class variable that equals that list.
Because it's inside of this hat, now, class,
I can use that list in any of my functions.
I've only got one now, called sort.
But if I had more, it would be accessible to all of those methods
as well.
And with sort, it also doesn't really make sense
to sort within a specific sorting hat because, again, I
only want there to be one.
So I can actually specify that this is class method by saying @classmethod.
And I don't pass in self anymore.
I actually, by convention, pass in a reference to the class itself.
It's typically written as cls.
Why?
Well, if you wrote C-L-A-S-S, that would actually conflict with the keyword
"class" that we keep using up here.
So the world realized that, oops, we can't reuse that same phrase here.
So let's just call this class.
This is useful in some contexts including this one.
Why?
Well, notice what I can now do.
I can now change self to be just class.
Why?
Because houses now-- not an instance variable, accessible via self.houses.
It is now a class variable, accessible via class.houses,
or technically cls.houses in this case.
But now the final flourish is this.
Now, I don't have to instantiate any hat objects as I used to on here, line 13.
I can just use functionality that comes with this class.
So I'm going to delete that line altogether.
I'm going to capitalize the hat on this new line 13 and just say hat.sort,
("Harry").
So what have I done?
I've not bothered instantiating an object of type, hat.
I am just accessing a class method inside of the hat class
that-- you know what?
Is just going to work.
This is how class methods work.
You use the name of the class, capital letter and all, dot method name,
passing in any arguments you want.
Python is going to automatically pass in some variable via which
you can refer to that class in that function
that you've implemented inside of that class
so that I can do something like this.
It's not that I want a variable called houses locally in this function,
I want the variable called houses that's associated with this current class
so I can still access this same list that I defined on line 6.
And now, if I go back down here to my terminal and run Python of hat.py,
Enter, Harry is still in Hufflepuff once more.
Harry is still in Hufflepuff once more.
Harry is back in Gryffindor, at least randomly.
Questions, now, on these class variables or these class methods,
which are in contrast with instance variables and instance methods.
And the one thing, at least, that's a little strange
here is that, even though there's a decorator called @classmethod,
there is not one called @instancemethod.
A method is just automatically a so-called "instant method" when
you define it without any decorator.
AUDIENCE: Can you have a class inside another class?
DAVID J. MALAN: You can.
You can define one class inside of another.
Generally speaking, this isn't done, but there
are cases where it can be helpful, especially
for larger, more sophisticated programs.
So yes, it is possible.
Other questions.
AUDIENCE: The question was about the self.houses.
When we remove it and we pass data, variable is created itself,
s why we remove the self?
DAVID J. MALAN: So in the previous examples--
both of the hat demonstration and also all of the student
demonstrations-- we were creating a student
object by calling Student, capital S, open parenthesis, close parenthesis,
with, eventually, name and a house passed in.
And then we were using the double underscore init method
to initialize the self.name and the self.house instance variables
therein to those respective values.
In this latest version of the sorting hat,
I haven't bothered with self anywhere, only because, conceptually, I
don't need or want there to be multiple hats in the world.
I'm just using the class as a container to bundle up this list of houses,
this sorting functionality.
Maybe eventually all add more functionality to it.
But that's it.
And so sometimes you can use object-oriented programming
in this somewhat different way when you want there to be functionality
but it's not specific to any one specific hat.
It's specific to the sorting hat itself.
How about one other question now, on these class variables or methods-- just
another way of using object-oriented programming but to solve
a somewhat different problem?
AUDIENCE: Well, what's the difference between the class
hat and a function of hat?
DAVID J. MALAN: A good question.
So why are we using a class at all and not just
having a file called hat.py with a variable called
houses and a function called sort?
Why are we adding this complexity?
In this particular case, we don't necessarily need to.
I could absolutely go in here.
I could get rid of the class.
I could undo this indentation.
I could get rid of this decorator.
And I could get rid of hat dot.
And I could just do this and additionally
let's say, let's get rid of class here.
Let's get rid of class here.
And now run Python of hat.py, Enter, and it still works.
Put Harry in the wrong house, but that's what we have--
what happens randomly.
That's fine, too.
What we're introducing today, by way of object-oriented programming,
is just a different way of modeling the world.
It's not really compelling with an example like this,
frankly, that's relatively simple.
It's not very complex.
There's not much functionality.
Honestly, the version that we just typed up-- these 10 lines-- this is fine.
This solves this problem.
But as our code gets longer, as we start collaborating with other people,
as the problems we're trying to solve with code get more sophisticated,
you're going to find that your code gets messy quickly.
And you're going to find that you have a huge number of functions, for instance,
in one file.
And some of them are related to each other, but some of them are not.
Well, at that point, wouldn't it be nice to just organize them
a little differently?
And in the world of Harry Potter, let's have a class for student;
let's have a class for Professor; let's have a class for the sorting hat;
let's have a class for something else.
And so once your world gets much more complicated than some
of the demonstrations we do here in class when we want to focus
on individual ideas, object-oriented programming is just a way
of encapsulating related data--
that is, variables-- related functionality-- that is, methods--
inside of things that have names.
These things are called classes.
So it's just another way to solve problems.
And when we focused on libraries a couple of weeks back,
that, too, was another solution to the same problem.
You could define your own modules or packages, put some of your data
and/or functionality in there, and that's fine, too.
And sometimes which one you should use overlaps.
If you're familiar with Venn diagrams, the overlapping region
might mean that you could use a class; you could use a module or a package;
you could just use a single local file.
Over time, you'll develop an instinct and maybe even
a personal preference for which tool to use.
All right, let me propose, now, that we apply this same idea of a class method
to clean up one other thing as well.
Let me close that hat.py and reopen student.py as we left it earlier,
and let me go ahead and simplify it just a little bit.
I'm going to go ahead and get rid of the properties,
not because there's anything, wrong with them,
but just because I want us to focus on some of the key ideas
when we began with this program.
So I'm going to go ahead and keep main as well.
I'm not going to adversarially try to change Henry's address there.
I'm going to instead go ahead, though, and just print the student.
But this is the thing I want to focus on here.
This, in our previous student examples, was a missed opportunity
to clean up my code.
Well, what do I mean by that?
Well, up here at the top of this file-- even
though I've simplified it, but getting rid of the properties
and all of that error checking-- because I
want to focus on the essence of this class now-- just the student's name
and the house and the printing thereof.
This is, by nature of classes in object-oriented programming,
theoretically, all of my student-specific functionality.
That is to say, if I have functionality and data related to a student, you,
the programmer, my colleague, would assume
that it's all bundled up, encapsulated, so
to speak, inside of the student class.
And yet, if you scroll down further, what is this?
There's a function called get_student that just exists elsewhere
in this file that prompts the user for a name, prompts the user for a house,
creates the student object, and then returns.
That's not wrong.
It works.
And we saw many, many times it kept working.
But this is a little weird because, if this
is a function that helps you get a student,
helps you get the name of a student and the house of a student, why isn't
that functionality in the class itself?
After all, as my code gets more and more complicated and does more things,
I'm going to be looking at the student class
for all student-related functionality.
I'm not going to be scrolling down, expecting that, oh, maybe there's
some other student functionality just randomly later in this file.
So it's not wrong.
But this is, again, evidence of maybe bad design--
not so much with this small program.
But this is an example, again, of code smell.
Something smells a little off here.
This is probably going to get us in trouble
by separating related functionality.
So again it's a design principle, not a correctness concern.
But class methods allow us to address this, too.
Let me go ahead and do this.
I'm going to delete get_student all together, leaving
only main as my other function here.
And inside of my student class, I'm going to do this.
I'm going to define a function, even more simply called, get.
And by nature of how class methods work, it's
going to take in the name of the class itself
or a reference thereto as an argument.
And I'm going to move the functionality from get_student into the student
class.
And I'm going to do this-- name equals input, quote, unquote, name, house
equals input, quote, unquote, house.
And then what this function is going to do
is return a new student object by calling class, which, again, is just
an automatically passed-in reference to the class
itself, passing in name and house.
And I will admit this syntax seems a little strange that now I'm calling cls
and I'm passing in these arguments.
But let me do one final fix here.
Let me go to the top of this function and more
explicitly say this is a class method.
This solves a potential chicken and the egg problem, so to speak,
whereby one needs to come before the other, potentially.
So what am I doing here?
Inside of my student class, I now have a function called get.
It is, I shall claim, a class method what does that mean.
It just means I can call this method without instantiating a student
object first.
Therein lies the potential chicken and the egg problem.
And if unfamiliar, that's an expression, meaning, well, and did the world
have chickens first that laid eggs, or was there an egg
that then yielded the chickens, but how did the egg get there?
It's this weird, circular problem.
And that's what we're facing here.
It would be weird if you had to create a student object in order to call get,
in order to get another student object.
That sounds messy.
Let's just get a student via a class method
that, by definition, does not require you to create a student object first.
Just like the hat, in its final form, we use the hat class
to just say Hat, capital H, dot sort.
We didn't need to create a hat first.
We just used the class itself.
So what am I going to do here now?
Let me go down to main.
And instead of saying get_student, notice what I can now do.
Student.get, and everything else can stay the same.
All I've done now is I've migrated all of my logic
from get_student, which was this own standalone function,
but clearly related to students by name.
I've moved the same code, really, to inside
of the student class in a more simply named function called get.
But I could still call it get_student if I want.
It just seems a little redundant to call it get_student in a student class,
so I'm simplifying.
So I have a method called get, but I'm calling it a class method
to avoid that chicken and the egg problem.
I want to be able to call a get without having a student object in my universe
already.
And the syntax for that is @classmethod.
The convention is to give this method at least one argument,
by convention called cls for class, which is just going
to be a reference to the class itself.
Lines 11 and 12 are identical to what they've always been.
And get_student-- the only new syntax here is this,
but this, again, is one of the features of object-oriented programming.
You can now instantiate a student object by just using cls that's passed in.
I technically could use Student, capital S,
but it turns out I'm doing what's more conventional because this
will both solve and avoid problems down the line with more complicated code.
This line here, on line 13, just means create an object of the current class.
What class is that?
Well, whatever cls is.
Well, that, by definition of how it all works, is going to be student.
And I want you to initialize it, as always, with name and house.
So now, scrolling down, my code is this.
And this is just nice to read.
You perhaps have to acquire a taste for this-- and I sound a little odd saying,
this is nice to read.
But indeed, student.get just tells me what's going on.
I'm going to get a student.
I don't need a separate function written by me called get_student in the file
itself.
The get functionality is built into the class.
All my student-related code now is together.
So let me go down to my terminal window and run Python of student.py, Enter.
Let's type in Harry.
Let's type in Gryffindor.
And we're back to where we began.
But, but, but everything related to students, now, is in this here class.
The only other thing in the file is main and this conditional
that we always use to avoid accidentally executing main when we're making
a module or a package or the like.
So again, a solution to a problem--
not a big one in the case of a relatively small program, but one
that you will eventually encounter as your programs
get longer and longer, with more and more entities to represent.
Questions now on this use of a class method.
MICHAEL: Does the class have to be defined before the main function,
in terms of the order of the program?
DAVID J. MALAN: A really good question.
So when in doubt, let's try this.
So let's try to change the order.
Let's move main to the top, which I've often encouraged.
So let's go ahead and, above the class, do this.
And notice now that, technically, line two
is mentioning student, which does not exist until line 6 and below.
Let me go ahead and clear my terminal and run Python of student.py.
So far, so good.
Harry-- Gryffindor, OK.
Indeed, Harry's from Gryffindor.
The reason, Michael, it does not matter in this case
is because we're not actually calling main until the very end.
And just as in the past, that means that Python has a chance to read everything,
top to bottom, left to right.
So everything exists.
I would say, generally classes are defined at the top of the file.
However, it would be even maybe cleaner to move the Classes definition
to its own file and then import it, so essentially
to make reusable code by putting it into your own module or package
so that not just this program but many others
can use that definition of student as well.
Other questions now on classes, class methods, or the like.
AUDIENCE: I wanted to ask, is there a way to declare all the possible--
all the possible attributes of the class?
Because it looks so inconsistent.
DAVID J. MALAN: Well, so my takeaway there
is this is Python's approach to these principles.
Different languages, like Java, just take a different approach
but have very similar features.
The syntax just tends to vary.
And this is how the Python community chose to implement this idea.
The right mental model, ultimately, is that these instance variables,
instant methods belong to or operate on specific objects--
a specific student, a specific hat.
Class variables and class methods operate on the entire class
itself or, in turn, all objects of that class, which
we've not seen a demonstration of, but it's a higher level concept.
So it turns out, besides these class methods,
which are distinct from those instance methods, which, to be fair,
do not have their own decorator-- they just are, by default, instance method,
there's yet other types of Methods You can have in classes in Python.
They tend to be called static methods, and they, too,
come with another decorator called @static method, which
is a rabbit hole we won't go down.
But realize that there is yet other functionality
that you can leverage within object-oriented programming.
But what we thought we'd do is focus really on some final core features
that you see not just in Python but other languages as well.
And perhaps one of the most compelling features of object-oriented programming
that we haven't yet used explicitly-- though it turns out we've seen
implicitly over the past weeks--
is this notion of inheritance.
It turns out, via object-oriented programming,
there's actually an opportunity to design your classes
in a hierarchical fashion, whereby you can have one class inherit from
or borrow attributes-- that is, methods or variables from another class
if they all have those in common.
So what do I mean by this here?
Well, let me propose that we implement, over in VS Code here,
a brand new file called wizard.py.
Let me go ahead and run code of wizard.py.
And then let's start as before, defining a class called student.
And let's go ahead and first define the underscore underscore, init method,
which of course, is minimally going to take an argument traditionally
called self.
And in this case, let's also have it take as before a name and a house.
And then in this init method, let's go ahead
and assign the instance variables-- self.name = name,
and self.house = house.
Let's assume that there's some other functionality
in this class as well-- dot, dot, dot.
But let's move on now to implementing the notion of a professor
in the wizarding world as well.
So for this class, let's call it Professor.
And a professor, let's say, is also going
to have its own initialization method.
So __ init.
It's going to take self--
always as the first argument.
A professor also has a name.
So we'll pass that in second, too.
And even though some professors are heads of houses,
let's assume that a professor is really identified
by their name and their subject area-- the class that they teach.
So we'll call this third argument, subject.
Now, as before, let's go ahead and assign self.name = name,
and let's assign self.subject = subject here.
And as before, let's assume that there's some more functionality associated
with professors as well.
Well, what do you notice already here in my definitions of students
and professors?
Typically, we're a bit reluctant to allow for any redundancy in our code.
And here, I feel like my init method is taking a name for students;
my init method is also taking a name for a professor;
and I have these identical lines of code, like self.name = name.
And this is only going to get exacerbated if I now go and add
some error checking.
So for instance, how about if not name, we
should probably be in the habit of raising something
like a value error in an explanatory message, like "Missing name."
And you know what?
If a professor is missing their name, I should probably
copy, paste that code down here.
And that's where red flags should be going off,
whereby, as soon as you start copy pasting code,
there's probably a better way so that we can write the code once and perhaps
reuse it in some way.
And here, too, object-oriented programming offers a solution.
It turns out that object-oriented programming in Python
also supports inheritance, whereby you can define multiple classes that
somehow relate to one another.
They don't need to exist in parallel in this way.
There could actually be some hierarchy between them.
So for instance, in the wizarding world, we
could argue that both a student and a professor are, at the end of the day,
Wizards.
So maybe what we should really define is a third class,
for instance, called wizard, that has any
of the common attributes for students and professors alike.
And for now, we've kept it relatively simple.
The only thing they have in common is a name and a name,
in student and professor, respectively.
So why don't we minimally factor that out first?
All right, so let me go ahead here.
And just to keep things organized, at the top of my file, let's
define a third class called Wizard.
And a wizard will have its own initialization method.
So def __init__(self), as always.
And a wizard, let's say for now, is only going
to be initialized with their name in this way.
And now, I'm going to go ahead and do some of that error checking.
So if not name will raise a value error in the wizard class.
Otherwise, we'll go ahead and do self name equals name,
and, heck, dot, dot, dot, maybe some other functionality as well.
But not a subject, which is specific to professors, and not a house,
which I've claimed is specific to students.
Now, I think we can begin to maybe remove
some of the redundancies in our other classes here.
So for instance, down with student, why don't I
go ahead and remove this error checking here and remove this error--
this assignment of self.name = name because I'm already
doing that in Wizard.
And similarly, down here, in Professor, why don't I do the same?
Let's get rid of the error checking.
Let's get rid of self.name = name because, again, I'm doing that already
up there for Wizard as well.
But at the moment, even though they're all in the same file,
I haven't told Python that a student is a wizard and a professor is a wizard.
So I really need to link these two together.
And the way you can prescribe inheritance, whereby one class should
inherit from another, or conversely, one class
should descend from another-- we can do this.
I can say class Student.
But before the colon, I can go in and say in parentheses,
a student inherits from, or is a subclass of wizard, which, conversely,
is the superclass of the student class.
So this just means that, when I define a student class,
go ahead and inherit all of the characteristics of a wizard as well.
And I'm going to do the same thing for Professor.
So (Wizard) after the class name Professor,
and that's going to give me access to some of that same functionality.
But because my student class and my professor class
still have their same init methods, those
are the methods that are going to get called.
Whenever I create a student in code or I create a professor in code,
I need to somehow explicitly say that I also
want to use the functionality in the Wizard class's init method.
And the way to do this in Python is as follows.
Let me go into my init method for Student,
and let me call super, with no arguments, which
is a reference to the superclass of this class.
So if this class is Student, the superclass-- that is,
the parent class-- is Wizard.
So super() will have the effect of accessing the superclass.
And then I'm going to go ahead and explicitly call its init method,
and I'm going to pass to the Wizard's init method
the name that the student's init method was passed.
And I'm going to go ahead and do the same down here in Wizard.
This is one line of copy, paste.
But I think I'm OK with it here because it's still
allowing me to do all of the name assignment
and the error checking up in the Wizard class instead.
I think we're OK now by just calling super.init for both student
and Professor alike.
Now, admittedly, this syntax is definitely out there-- the fact
that we're calling super in parentheses and dots
and underscore underscore on the left and the right of init here,
but it's just a combination of these two ideas.
super() is a way of programmatically accessing a current class's parent
class, or superclass, and __init, of course, is just referring to, now,
that class's own initialization method.
Now, per the dot, dot, dot-- so there could be
a lot more going on in these classes.
But what's nice now is that Wizard as a class
is taking care of all of the assignment of a wizard's name,
whether that wizard is a student or a professor.
And it's even doing some error checking to make
sure the name was actually passed in.
Meanwhile, student is inheriting all of that functionality
and using it by calling the superclass's own init method.
But it's additionally taking the house, that's presumably
passed into the student constructor function,
and assigning it to its own instance variable-- self.house,
and similarly, professor, or restoring in self.subject
the subject that was passed into that one as well.
Now, how might we use these classes?
Well, we'll continue to wave our hands with a little bit of detail here.
But at the bottom of this file, or any other file that imports this one,
I could now write code like this.
I could create a student variable and assign
it the return value of the student constructor call.
and maybe that student is named Harry and that student's house,
for instance, might be Gryffindor.
And meanwhile, I might do something like this. professor = Professor over here.
And notice, the lowercase S on the left, capital S on the right.
Same for professor on the left-- lowercase and uppercase on the right
respectively.
Professor, quote, unquote, "Severus," and how
about Defense Against the Dark Arts will be his subject?
And meanwhile, if we want, more generically,
just a wizard, who, at the moment is neither student nor professor
teaching classes actively, we could even do that.
We could do wizard = Wizard in capital W on the right-hand side
of the equal sign, because it's the name of the class.
And someone like Albus--
passing in only Albus's name--
not a house, not a subject, because, in this case, he's known only as a wizard.
Meanwhile, with each of these calls, this line of code
here will ensure that the init method for the wizard class is called.
This line of code here will ensure that the init method of the student
class and, in turn, the init method of the superclass wizard is called.
And then lastly, on this final line of code,
will this syntax ensure that the init method of the professor class
is called, which, in turn, calls the init method of the superclass as well.
Any questions now on this idea of inheritance,
which is a key feature of a lot of object-oriented programming languages?
MICHAEL: From what I've seen so far, a lot of times, there's a lot of nesting.
If you do super, does it go one up?
Is there any situation where it's nested in another class as well, above Wizard,
let's say?
DAVID J. MALAN: A really good question.
If you were to have a super superclass-- so
your hierarchy is even taller than the two levels of hierarchy
that we currently have, absolutely.
What's nice about inheritance, as the name implies, is,
just as you might have inherited certain traits as a human
from your grandfather and grandmother or your great-grandfather
or great-grandmother, some of those properties
can actually trickle down to you in the context of code as well.
So when you descend from another class--
that is, when you subclass a superclass or a super superclass,
you actually do inherit all of the functionality,
not just from one level above you but from two or three,
so you can indeed access some of that functionality as well.
And you can even override it if you want some of these classes
to behave a little bit differently than others.
Other questions on inheritance.
AUDIENCE: So it's similar to the last one,
but can you have two parents on the same level?
DAVID J. MALAN: A really good question.
So there are ways to implement descendants from multiple parents.
And there's different ways to do this, not just in Python but other languages.
We've kept things simple here, though, by having a single inheritance path.
A good question.
How about one more question on inheritance?
AUDIENCE: Can we have multiple arguments in super.__init?
DAVID J. MALAN: Yes, but in this case, I'm only passing a name on line 18,
and I'm only passing in name on line 10.
Why?
Because, on line 2, when I define the init method for the Wizard class,
I only expect a single argument.
But I could absolutely have other common functionality.
I could add in a patronus.
If both students and professors have patronuses
that can come out of their wands, I could have two arguments instead.
We've been using this feature of object-oriented programming
now for quite some time in the form of exceptions.
Indeed, if you look at the official documentation for exceptions in Python,
you'll see that there's not even the ones we've seen in class,
like value error and others.
There's any number of others as well, but they are all, themselves,
hierarchical in nature.
This is just a subset of the available exceptions that come built into Python.
And you can actually, as a programmer, create your own exceptions as well.
But as this chart here captures hierarchically,
all exceptions we've seen thus far actually descend from
or inherit from superclasses already.
So for instance, at the bottom of this list
here is ValueError, which we've seen quite a bit.
And if you follow the line straight up on this ascii rendition of this chart,
you'll see that ValueError has a parent, class, or superclass, called exception.
And the exception class, meanwhile, has a parent class called base exception.
Why did the authors of Python do this?
Well, it turns out that, whether you have a value error or a key error
or an assertion error or any number of others,
there's a lot of functionality common to all of those types of errors
that you want--
that you want a programmer to be able to use.
And so it turns out that the authors of Python decided, you know what?
Let's not have a dozen or more different classes
that all just have copy, pasted similar functionality.
Let's create this hierarchy so that, even
though the exceptions toward the bottom of this list are very precise,
they at least inherit--
that is, borrow some very common functionality up above.
So it turns out that, when you use the Try and the Accept keyword in Python,
generally speaking, we've tried to catch very specific exceptions,
like ValueError.
But technically, you could capture the parents or even
the grandparent exception for a given exception,
especially if you're not necessarily sure which one is going to get raised.
Or, better yet, there could be many exceptions that get raised,
but you want to handle them all the same,
and you don't want to necessarily enumerate them
in parentheses, separated by commas.
You want to say you want to handle all exceptions of a certain superclass
in much the same way.
So this has been latent this whole time, any time we've
seen or used or caught or, now, raised exceptions, and built into Python
is this hierarchy.
And if you were to invent your own exception,
generally, you wouldn't want to start from scratch.
You would want to descend from-- that is, subclass, one of these existing
exceptions and add your own twist on it, your own functionality as well.
Well, there's one final feature of object oriented programming
that we'd like to share with you today, and then it
will perhaps be quite the eye opener as to what you can really do now
that you have classes at your disposal.
And this, too, surprise, has been a feature
you and I have been taking for granted for weeks now.
This has just worked, but it's been implemented in a way
that you can now leverage yourself.
It turns out that Python, and some other languages, too,
support this notion of operator overloading, whereby
you can take very common symbols, like plus or minus or other such syntax
on the keyboard, and you can implement your own interpretation thereof.
Plus does not have to equal addition.
And minus does not have to equal subtraction.
And in fact, you and I have already seen another context
in which plus means something else.
Plus has not always, in Python, meant addition, per se.
What else has Python used plus for?
AUDIENCE: Concatenation?
DAVID J. MALAN: For concatenation.
For joining two strings, for adding to a list can you use plus as well.
So plus has actually been, funny enough, overloaded by the authors of Python
for us.
And so we can use the same symbol in much the same way as addition
but with different data types to solve slightly different problems.
Well, let me propose that we go back over to VS Code here,
and let me go ahead and create a new final file called vault.py.
So code of vault.py.
And let me propose that we implement the idea of a vault
at Gringotts, keeping on theme, wherein there's
a bank in the world of Harry Potter.
And within this bank, families and individuals
have vaults containing all sorts of money in the wizarding world.
And the type of money that exists in the world of Harry Potter
are coins called galleons and sickles and Knuts,
and those are in descending order of value.
And so inside of a vault might be a whole bunch of coins--
gold, silver, and bronze, essentially, each in those denominations,
tucked away.
So how can I go about implementing, first of all, the idea of a vault
so that I can store, for instance, for Harry Potter, how much coinage
is in his family's vault, or for Ron Weasley the same?
Well, let me go ahead and vault.py and first
create a class called Vault, essentially meant to represent a bank vault.
Perfect, another real world, or fantasy world,
entity that I want to represent with code.
I could use a tuple or a list or a dictionary.
But again, I'm going to get a lot more functionality with classes,
and we'll see one final flourish with operators.
Inside of this vault class, let's go ahead and do this.
Let me define my init method, taking its first argument of self.
And let me define three arguments to this.
When you create a vault, in my code here,
I want to be able to initialize it with some number of galleons, some number
of sickles and, some number of Knuts.
I want the user, the programmer, to be able to pass in one or more
of those values ideally.
But they can be optional, so I'll give them defaults.
So let's go ahead and define a parameter called galleons,
whose default value will be 0; sickles, whose default value will also be 0;
and knuts, whose default value will be 0 as well.
So the programmer can pass in one or two or three or even none of those,
and they'll all have some implied defaults.
How do I want to remember those values that are passed in?
Well, let me do this.
self.galleons = galleons.
And self.sickles = sickles.
And self.knuts = knuts.
And so I could add some error checking, especially if you don't pass in.
A number I could turn these into properties to do even more validation.
But let's keep it simple and, as always, focus only on the new ideas.
So I'm just going to trust that these values were passed in,
and I'm going to immediately assign them to these instance variables.
What, now, do I want to do?
Well, let's come up with a way of printing out
what is in someone's vault, ultimately.
But first let's do this.
Let's create a vault for the Potters by creating, via assignment, a new vault.
And let's say that the potters have 100 galleons, 50 sickles, and 24 knuts.
And that's in that vault. And let's print out, for instance, potter.
All right, let's run this code and see how it works now.
Let me go ahead and run Python of vault.py, Enter.
Seems to work.
No syntax errors or anything else.
But this is not very enlightening.
How do I fix this, thinking back to what we've done before?
AUDIENCE: You have to use the __str.
DAVID J. MALAN: Exactly.
I need to use one of those special methods that comes with classes
and define for myself how I want a vault to be printed as a string.
So let me go ahead and do that.
Let me define the str method taking in self as its sole argument here.
And let's just return a very simple string
that just reveals what's in the vault.
So I'm going to return a formatted f string,
inside of which is self.galleons and then the word galleon,
so I know which those are.
Then let's do self.sickles, and let's output the word, sickles.
And then lastly let's output self.knuts, and then knuts here.
So I know, in this string, just how many of each of those coins
I have in this particular family's vault. All right, let me go ahead
and run Python of vault.py, changing nothing else except the str method.
And now, , we, see indeed that Harry has 100 galleons, 50 sickles, and 25 knuts.
All right, well, let's do one thing more here.
Below that, let's go ahead and define a Weasley variable.
And Ron never seemed to have quite as much money in the vault as did Harry.
So let's say that the Weasley vault will have 25, 50, and 100.
So I'll just reverse the order of those denominations,
rather than Harry's 100, 50, 25.
And now let me go ahead and print Weasley like this.
And let's go ahead and clear my terminal window, run Python of vault.py.
This time, that str method will be invoked twice, once
for each of those vault objects.
And we'll see, indeed, that the first one for Harry
has got 100, 50, and 25, respectively, versus Ron's 25, 50,
and 100, respectively.
But now let's do something interesting.
Suppose that you wanted to combine the contents of two vaults,
be it Harry's and Ron's or any other two people.
How would you go about doing this in code?
Well, if I wanted to combine the vaults for someone, I could do this.
Well, I could do galleons equals--
let's do potter.galleons + weasley.galleons.
That gives me a variable called galleons that has
the sum of Harry and Ron's galleons.
Let's next do sickles = potter.sickles + weasley.sickles.
And then lastly, let's do knuts = potter.knuts + weasley.knuts.
I've got three variables.
What can I now do with these values?
Well, let's create a third-- a new vault. Total will
be the name of this variable equals a new vault, Capital V, notice.
And now, let's pass in those three new variables--
galleons, sickles, and knuts.
And that's it, and let's print out this total vault.
So we should now see three vaults-- one for Harry, for Ron,
and the combination-- the addition of the two.
Let me go ahead and rerun Python of vault.py, and there we have it.
What was 100, 50, 25 and 25, 50, and 100, combined through addition now,
is 125, 100, 125.
So pretty straightforward, using techniques from weeks
ago, where we're just declaring a few new variables and doing some addition.
But wouldn't it be cool if I could do something like this?
Wouldn't it be cool if I could just somehow,
not manually create my own vault and do all of this annoying math up here--
what if I could just do potter + weasley and get rid of all of this logic here?
Wouldn't it be nice if I overload the operator--
we know as plus, just like str does, just
like list does-- to allow me to add two vaults together
on the left and the right.
Well, it turns out in Python and through operator overloading,
there is a way to do just this.
If you consult the documentation, there's
this and so many other special methods that come with classes.
The third one we'll see here is this one here--
__add__.
And you'll see that it very generically is described
in the documentation is working for any object, be it a vault or str
or a list or something else.
By convention, it's going to take a first argument called self,
and then it's going to take some other argument, by convention, called other.
self, in effect, is going to be referring to whatever
object is on the left of a plus sign.
other is going to be referring to whatever
is on the right-hand side of a plus sign,
thereby giving us a way of describing, in code, the operand
on the left and the operand on the right of the operator, plus, in between.
That is to say, if I go back to VS Code here,
what I'm trying to do is implement support for this.
Well, let me try, without writing any other code just yet--
Python of vault.py, Enter--
TypeError: unsupported operand type(s) for +: 'Vault' and 'vault.'
That is to say Python, at this moment, does not know what
it means to add two vaults together.
You and I might have an instinct.
Probably want to combine the galleons and the sickles and the knuts
respectively.
Python doesn't know that.
It just knows that you have a new class called Vault.
But let's teach Python to do this.
Let me clear my terminal window.
Let me scroll back up to the class itself, where, at the moment,
I only have two special methods-- init and str.
But let's add this third.
Let me go into the class here and define __add__ and then specify its first
parameter as self, as before, and then a second parameter for this particular
method called, by convention, other.
Now, as always, I could name those parameters anything
I want, but I'm going to stick with convention here.
And now, inside of this method, am I going
to have to now add together the contents of two vaults?
Well, what two vaults?
Well, if we scroll down to our goal at hand, the goal, of course,
is to add this vault plus this other vault-- potter
plus weasley, respectively.
Well, it turns out, in Python, that, when you do overload an operator like
plus, what's going to happen automatically,
as soon as Python sees that, is it's going to call that __add__ method,
and it's going to pass into it to arguments--
whatever the operand is on the left-- potter, in this case--
and whatever the operand is on the right-- weasley, in this case.
And those values are going to get passed in as self and other, respectively.
What that means is that we can access their contents up here
in our implementation of add as follows.
Let me go ahead and define a local variable called galleons and set that
equal to, for instance, the sum of self.galleons--
whatever's in Potter's vault in this case,
plus whatever is in Wesley's vault in this case, which
would be other.galleons.
Let me do the same for sickles.
self.sickles + other.sickles.
And let me lastly do that for knuts.
So self.knuts + other.knuts.
But at the end of the day, I'm going to need
to return a brand new bigger vault that contains all of those contents
together.
And if we ultimately want to assign that bigger vault to a variable like total
here, on the left, we'd better return a value from this add method.
So I'm going to go ahead and give myself a brand new vault, as by returning
capital Vault, which of course, is going to call my vault function into which
I can now pass some of those initialization arguments.
Well, how many galleon, sickles, and knuts do
I want this brand new vault to contain?
Well, I want it to contain this many galleons this many sickles,
and this many knuts.
So ultimately, what we're doing in this implementation
of add is adding together those galleons, sickles, and knuts, passing
them to the vault function so that we get a brand new bigger vault,
and return that altogether.
So now I've defined this new special method
called add that should now just make plus work for two vaults.
Let's see.
Let me run down to my terminal window, Python of vault.py and hit Enter.
And voila, and now we've implemented an overloaded operator, plus,
to do what you and I as humans would hope
would be the case when you add two vaults together.
But I've now written the code more specifically
to teach Python what it means concretely to add two vaults together.
And it's with very similar code in effect,
underneath the hood, that Python is doing this for two strings,
to concatenate them together, to joining two lists into a new list with list,
and so many other classes as well.
Any questions now on operator overloading or this example here.
AUDIENCE: How would you go about creating
a function for adding a student and a vault for two separate classes?
Would that be possible?
DAVID J. MALAN: Let me see what happens here.
I don't know offhand.
Let's do this.
Let's create a str and see what happens.
If I add Potter plus a str--
str object.
Yeah, so it would work.
I'm just figuring this out as I go here, Eric.
So just to be clear, what I did was I just
changed weasley to str just to see what would
happen when I add a vault plus a str, and it will work, theoretically.
Why?
Because so long as the type of value on the left has an add method implemented,
other can be any type that you want.
You just have to decide and code what it's
going to mean conceptually to add a vault plus a string, which,
in this case, probably doesn't make any sense at all, but it's possible.
It's going to be the operand on the left.
And I'm inferring that.
I did not know the answer a moment ago.
I'm inferring that because what I got was an attribute error here on line 11
because Python did not like this. other.galleons didn't work,
but I could make it work by figuring something out.
Really good question.
Didn't know that one myself.
Other questions on operator overloading?
AUDIENCE: Can you define new operators in Python?
DAVID J. MALAN: I don't think so.
There is a very long but precise list of operators that you can overload.
I do not believe you can assign arbitrary characters
to be operators in Python.
Let me defer to Carter in the chat to--
OK, I'm seeing two of my colleagues are saying, no, not possible.
So I'm going to go with my first instinct, no.
Otherwise, that'd be kind of cool.
You could make emoji do whatever you want to.
How about one final question on operator overloading?
AUDIENCE: Is that the only operation you can do as far as--
can you do a subtraction as well?
DAVID J. MALAN: You can.
You can do so many others let me.
If, Carter, you don't mind pulling up this URL here--
so this link here-- special method names and today's slides,
you'll see a long list of all of the operators that you can overload.
You can do less than, equals than, plus equals, minus equals.
Pretty much any symbol you've seen me type on the screen
can be overloaded in the context of classes.
So even though, today, we focused entirely
on object-oriented programming, this is a technique that we've been using,
really, since the first week of the class because those ints,
those strs, those floats, those lists, those dictionaries,
and so much more were already underneath the hood this whole time-- classes
and objects thereof.
But you now, as a programmer, have the ability
to create your own classes with your own instance or class variables,
with your own instance or class methods, with your own properties,
and even with your own custom behavior for operators.
So ultimately, you can absolutely continue
using those simple tuples or lists or those dictionaries or other structures
as well.
But object-oriented programming, and with it, classes and now these objects
is just another tool in your toolkit.
And daresay, as your code gets more sophisticated
and your problems get bigger, you'll find
that being able to model these real world or even fantasy world entities
with classes and related data and functionality
will ultimately just allow you to define code that's not just correct but ever
well-designed as well.
This was CS50.