Pythonoop on Janusworx

A Hundred Days of Code, Day 017 - Python, Advanced Objects, Done!

feedback@janusworx.com (Mario Jason Braganza) — Sat, 25 Jul 2020 18:10:46 +0530

And we are done with objects!
This course finally gave me what I was looking for all these months.
The ability to think of and reason about Python, so that I can then think of and reason about, how to build my own programs.

Notes
#

Abstract base classes
- Sounds all high and mighty, but does something pretty logical and simple
- Helps me test if my object is of a generic (of sorts) type. I don’t want to test if 5 is an integer or a float or any of the other various county types in Python. I just want to see if it’s a number, of some sort. The abstract base class numbers helps me do that.
- There are such classes for strings and files, I hear.
- Will go into learning more about them in detail later, as I actually write more Python. But at least I know what they are now.

** Part 3, Context Managers**

Again, Context Managers, sound like something really complex, but they are just a matter of writing and doing things in a certain manner.

It’s something like a Tiny Habit stack loop, I learnt in the Atomic Habits book, as I was building up new habits.
- When I do this,
- then I will do this immediately after.
- and when I am done, I will do that.
Context Managers have a similar paradigm.
- With this object (as this variable, optionally)
  - I will run the __enter__ method
  - then after, I will do stuff
  - and when I am done, I will run the __exit__ method
- I can add the context manager protocol to my objects too, by impletementing the __enter__ and __exit__ methods in my classes
- They are used in a particular context, where you want to turn something on and then turn something off, before and after that context, thus Context Manager.
  - I can set something up in my __enter__ method and then tear it down in my __exit__ method.
  - This could be, for example, a network connection, a file, a redefinition of some sort, etc.
  - The __enter__ method must return self if all has to work well.
  - The __exit__ block, takes four arguments, one for self, one for an error class, one for the object, and one for the address in memory, the traceback. I can use them to catch errors in the main body of my with block, and then decide what the appropriate way to deal with them is.
  - A good example is using redirecting the print function’s output to a file, using a context manager. (The print function can write to a file, when I specify it as an output device like so print ("Hello there", file=f)
  - While I might be able to catch errors in the body of the context manager, I cannot if something happens during __enter__. just something to be aware of.
Contextlib is a library of context managers, Python already provides us.
- import contextlib
- contextlib.redirect_stdout/err will redirect stuff from the default output (the screen) to whereever else you want it to.

** Part 4, Properties and Descriptors **

A property is an attribute, that acts like getters/setters in other languages. It uses methods to set other attributes in the class (within the bounds we set). For e.g. a .temp property that will let you set temperatures, but only in the range you specify. not below 18C and not above 25C.
set by putting @property atop a getter function (let’s say temp) and then defining the setter properties in an identically named temp function again but decorated with @function_name.setter; in our case @temp.setter
the whole actual way to do it is like a contortionist twisting into a pretzel shape. Getting fluent with this will take time and practice.
it basically (to my mind) is like me giving someone something, and that someone goes and magician like, does something marvellous with that something, instead of just storing it in their pocket. it looks like assigning data to an attribute, but behind the scenes there are methods, just waiting to weave spells on said data.
When I take a property out of a class and abstact it, so that it can be used by many classes, it’s called a descriptor. (kinda like abstracting functions out of program files and into modules)
To kinda formally state, a descriptor is a class whose instances are supposed to be class attributes in other classes.
- To fit the descriptor protocol, a descriptor class needs to implement…
  - a __get__(self, host_instance, host_class) method with a corresponding __set__(self, host_instance, new_value_to_set) method
- These are class specific. As in, the descriptor is shared amongst all the instances it is used in.
- To get instance specific descriptors, you set the value that you are changing to be assigned as a dictionary using the host instance as the key and the value, as the value. (More contorting!) and then return the value of the [host_instance] value.
- Definitely tons of practice needed with this.
- Not used much, in day to day work, but used heavily behind the scenes by Python itself for its object system. The methods, Python classes have, are plain old functions, with descriptors (in conjunction with weak referenced elements) applied to them.
- The more I dive into all of this, the more Python feels less magical and more like the work of thousands of hard working atomic elements. And I think, I like this better. That everything complex, is actually lots of simple pieces, working together in concert.

** Part 5, Advanced Topics **

The only thing I can write here, is that Reuven goes deep into hijacking how Python creates classes and then using them for our own customised ends. How to create my own custom __new__ method, my own custom __init__ method, my own custom type of object, create my own class with a metaclass…
Never going to use this, unless I am writing the next Django or something, and even then I doubt, these would be needed 😂
But this was so much fun to learn!

Read all about my Python Objects journey here

A Hundred Days of Code, Day 016 - Python, Advanced Objects.

feedback@janusworx.com (Mario Jason Braganza) — Fri, 24 Jul 2020 20:34:43 +0530

Started up with Python Objects today.
This seems like a long, hard one.
Here’s hoping I learn lots.
Knowing Reuven, I know I will.

Notes
#

Part 1, Advanced Methods.

This section focuses on the dunder methods in Python.

By default objects are not equal to other objects even they they are from the same class, with the same attributes and methods.
- We could implement our own equals method though.
- The point being, we need to be intentional and methodical, when we design and implement our classses
Static methods are plain old functions that I write in my class for use by both the class and the instance. Could be used to clean up input or similar such utility functions. I create them by putting a @staticmethod decorator atop my method.
Class methods are those that are meant for use by only the class. I can call them from my instances, but they act on the class. I create them by using the @classmethod atop my method. For clarity, the first variable is now written as cls instead of self.

Part 2, Inheritance.

MRO, Method Resolution Order. I can do an classname.__mro__ to see how Python goes about looking for methods upwards, specially if I’m inheriting from multiple objects. Running help on an object also lists the MRO of its methods.
Best to explicity inherit from all parent classes, when inheriting from multiple classes.
We can use the classname.__bases__ to check for the classes parents.
A mixin is a class, we can inherit from (probably in addition to and before our parent class), that just adds functionality to our class. Does nothing sematically / organizationally to our objects or classes.
- The mixin must come first.
Adding an __ before an attribute, signifies that it is not to be touched. A little security by obscurity too. Nothing’s stopping me from actually going and changing things up. It’s just a notifier to people with common sense that such stuff ought not to be tampered with.
- The main reason though is to prevent conflict between attribute names.

Learning / Feedback/ Experiences from doing exercises
#

This course feels like the O’Reilly cookbooks in video form.
The first section takes all the operators, I take for granted in Python and then shows me how to implement them with my own classes
- how do I get len to work on my object? or how do I implement the == operator in my classes? etc. etc.
Starting with the last one and this one, have given up on exercises and just taking notes for now. As soon as I finish the run, I will be then going on an exercise binge with these pending exercises as well as Reuven’s Python Workout.
- The execption being, if I run into a topic that is really confusing, then I will attempt the exercises to drill the idea immediately into my head.
Obligatory Reuven plug, since I started up a new course :)
- Reuven is an awesome teacher.
- He takes the time, to explain stuff in painstaking detail, leaving nothing as an “exercise to the reader”.
- All of these courses, so far have been worth every single penny I spent on them.

Read all about my Python Objects journey here

A Hundred Days of Code, Day 005 - Magic Methods and Winding Up OOP

feedback@janusworx.com (Mario Jason Braganza) — Sun, 12 Jul 2020 19:23:05 +0530

Done with Reuven Lerner’s OOP basics

Notes
#

len does the right thing across multiple types of objects.
- it counts characters in a string, elements in a list, and key-value pairs in a dictionary. how does it know how to do that?
that is because len uses a magic method (methods that have a __ for a prefix and suffix)
- len uses the __len__ method which i can use in my own classes, to implement a len method for my classes
If I choose to do so, I need to realise what those underlying methods expect to return and return the same type in my classes. __len__ expects to return integers, so when I implement it in my classes, I ought not to return a string. Once again Reuven strongly suggests using common sense :)
same thing when i try to print something. it calls the magic method __str__ to do stuff. or if i try to do repr to check for raw representations, the __repr__ method is called.
Python is filled with these methods which I can use to allow my classes to have standard Python like functionality. like a print(doggie) should give me details about the cute pup object i just created, if I have taken the time and attention to implement the __str__ or __repr__ methods
most of these methods come with the base primitive class object which every class inherits from. so i get them for free. and then i can override them and customise them to what I want to show.
people try standard methods on new objects. implementing them is much better than creating my own and asking people to use ’em.
if both are equal or really similar, ok to just use only __repr__. later when I have experience and other needs, i can implement __str__ too

learning / feedback/ experiences from doing exercises
#

Despite warning myself above, I went ahead and made the mistake of returning a whole lovely string, instead of an integer, when I tried to implement the len method on my class XD
and then I forgot to add the f prefix to an f-string and wondered why it was not interpolating for nearly 30 mins
Reuven has a wry sense of humour. In one of my exercises I get to create classes of animals for a zoo, with various attributes such as colour and legs and so forth. Then he has me put them in cages. After making me put 2 sheep in a cage with a wolf, he wonders if the legs of the sheep ought to be reduced or not XD
The number of typos I am making is staggering. Missing colons, missing quotes, missing brackets. If this is Python, I shudder to think how I’d fare if I picked up a static language to learn XD
Wasted another half an hour because I spelt colours with capitals like Black and then later looked for black and was tearing my hair out, because I knew there were black animals and why in tarnation, would Python not show me them XD
Saw Reuven do nested comprehensions and now I want to do that too! it took him one well thought out line to do what I did in 2 multiline functions

Final Words
#

This was amazing!
I learnt so much about classes and the way they work.
Reuven has a very joyful pedagogy.
I love him go hahahaha like Santa Claus.
I love the fact that he makes mistakes.
I love that for every problem, he poses, he has various approaches.
His fluency shines through every lesson.
I got lucky with the Pycharm Humble Bundle.
But I loved this so much, that I am going to sign up for all the Lerner courses, I possibly can.
Beginning with the basics.
If OOP is any indicator, the journey is going to be lots of fun.

Read all about my OOP journey here

A Hundred Days of Code, Day 004 - Class Attributes and Inheritance

feedback@janusworx.com (Mario Jason Braganza) — Sat, 11 Jul 2020 17:47:49 +0530

Learnt about Class Attributes and Inheritance, today.

Notes
#

The way we write functions/methods and define classes might look similar,
class CrazyTalk(object): and def how_now_brown_cow():
The way they behave/execute, though is wildly different.
Classes run / spring to life as soon as the program launches.
Functions don’t, unless they are called.
Realised that objects are containers.
What you can do with the object depends on what is in it.
Does it hold a dictionary with various methods to modify it?
Does it just hold a bunch of text?
Reminds me of media formats as containers.
A mp4 file is not just an mp4 file.
The video resolution could vary from one file to another.
The type of audio encoding could be different.
It could carry multiple streams of audio or video or other metadata.
What you can do with the file or where you can play it, depends on what is inside it.
Same with classes and objects.
Any thing that we define inside a class, is an attribute. (methods, variables etc.) Reuven made a point of stressing this, so writing this down.
If I just define a variable and try to use it, I’ll get an UnboundLocalError. I need to use className.variable when I call it.
So I can just write a variable like so

class SomeClass():
	crazy_var = 'Muahahahaha'
	def __init__(self):
		print(SomeClass.crazy_var)

and then call it with SomeClass.crazy_var or when I do it after I define __init__ then I can just directly define it as SomeClass.crazy_var (which sounds more logical to me), like so

class SomeClass():
	def __init__(self):
		print(SomeClass.crazy_var)
SomeClass.crazy_var= 'Muahahahaha'

A class attribute is associated with the class itself, while object attributes are associated with the objects that are created from the class.
So with car.wheels, the wheels are associated with the car class, but when I use car to create a Ferrari object, and it has Ferrari.white_wall_rims the rims are an instance attribute that belong to the Ferrari object / instance and not the car class it was made of.
If I ask for an object’s attribute and it isn’t there, then Python goes looking upwards to check if the class has it. In the previous point, if I go Ferrari.wheels it’ll work, because Python will check the Ferrari object and if there are no wheels in there, it’ll go check cars.
Name your attributes carefully.
Don’t have the same names between class attributes and object attributes.
Use your head!
Don’t do that!
When we create a class, that is identical to another with one or two teeny exceptions, when they are so similar that I base the new one on the old one — those new classe are said to be inheriting from the old one. They have an is-a relationship.
For e.g. a doggie is-a floofy animal.
A teddy bear is-a floofy animal too.
Both of them inherit their floofiness from the floofy animal class.
I can write that as class Doggie(FloofyAnimal):
Note: Methods are attributes on a class. They are not attributes of the instance object.
Note: If you have an __init__ method in your inherited class, the instance will not look for __init__ variables/details in the parent class.
(it’s like this in Python, Java/C++ can get stuff from the parent / grandparent. this is so, because with Python, everything is a live object whereas with the other languages, the __init__ stuff are declarative rules with orders of precedence (a la CSS) and the class comes alive only after all the rules are parsed.)
If you do want to inherit something from the parents __init__, then you explictly get it by using super(). as in get it from the supervisor above, i guess? I’d add a line like this to my doggie class

class Doggie(FloofyAnimal):
	def __init__(self, name):
		super().__init__(name)

And then it will pull the name from the Floofy Animal class if it’s in there.

Use inheritance only when it makes sense. No need to go hog wild.

learning / feedback/ experiences from doing exercises
#

Slowly getting the hang of list comprehensions. I should practice them more.
Because they are very easy to read later.
Just that, I get very confused while writing them.
Doing the exercises is slowly getting easier
Reuven is very hands on, has tons of jokes, and makes tons of typos.
I’ve gone from eyes glazed, looking at the his code and struggling to understand to yelling at the screen when he mistypes something :)
Shows that I am learning :)
Python Tutor is very handy to see the the thousands of mistakes I make.
Even that interface does not quite make me understand, but it gets me 80% of the way there.
(like when a return statement of mine was nested in a loop instead of being out at the end of the for statement.)

Read all about my OOP journey here

A Hundred Days of Code, Day 003 - Methods

feedback@janusworx.com (Mario Jason Braganza) — Fri, 10 Jul 2020 19:44:34 +0530

Learnt about methods today.
Notes follow …

My understanding about methods? They are functions in classes that help me manipulate the data the objects contain when they are created.

I have been using something them subconsciously all along.
The __init__ method, that is called/run automatically every time an object is created.

Aha
A nice way to unpack the .notation i use

Let’s say I have a class SquareNumbers that has a function (method) — x2 — that will, you know, square a number.
And then I create an object f with a number and call the square method on it.

f = SquareNumbers(10)
f.x2()

What I am actually doing, when I call f.x2() can also be written as SquareNumbers.x2(f).
I am sending a message x2 to the f object, and it will respond with however/whatever it is programmed to.

When I define object variables in a class, I should refer to them with a self.variable when I define methods.
I figure because each object can have it’s own set of values for those variables and I want Python to find them properly.

Also learnt this is not the case in most other languages.
With some languages, you set and get values of variables of the object, using even more explicit methods, call getters (accessors) and setters (mutators).
These are just fancy names for explicit methods to assign and then read data from the variables of a class.
In our example above, I would probably have a set_x function defined to set the value of x like f.set_x(20) (along with a corresponding get_x to read it)

This could also be because other programs have different categories of data (private, public) in classes, while Python does not.
Just differences in language design philosophies, I guess.

I can create an class, that can use objects created by other other classes.
For example, I can create a book class and then have several book objects.
And then create a new bookshelf class, whose objects can take all my books and put them in a list/library of sorts
This kind of relationship is called a has-a relationship in programming parlance.
(like my bookshelf has-a book on it)
It’s also called composition. I am composing a new class from other classes.
I can do what I want with the list in the bookshelf.
I could take their prices (if i added them) and then sum them up.
I could take the titles and list them alphabetically, or by author.

Aha

So what is becoming clearer to me is that classes can take user needs, and express them naturally, while leaving the creation of these calculations and listings and sortings with the programming language primitives behind the scenes.
For my book shelf i could just go shelf.sort.title.alphabetical()
Or if I have a new need tomorrow, hmm, like finding the total prices of all my books, I could just add a sum method to my bookshelf and I could go shelf.sum().

It basically makes my code, more human. More easy to understand. More natural.

Another thing that just occured is that I could swap out the primitives beneath the classes. If I find a faster, better way to sum up prices, I could just use that. While the way I would sum the books would still remain shelf.sum()

Doing the exercises, I realise that I need to learn a lot more Python vocabulary.
I somehow managed to gather a number of variables into a list.
But when I attempted to do it again, it threw an error.
And that’s when I learnt I could extend a list.
Lots more practice needed!

The self thing bit me hard!
I spent at least a 45 minutes trying to find out why my method could not find a variable, despite me defining it correctly. I should’ve obviously referred to it with self.variable!

Time to call it a day.

Read all about my OOP journey here

A Hundred Days of Code, Day 002 - Basic Exercises

feedback@janusworx.com (Mario Jason Braganza) — Thu, 09 Jul 2020 19:15:05 +0530

Did a few exercises today.
They were simple.
Create a few classes, change them, modify them, use a list as an attribute and so on.

In a couple of ways, this was just what I needed.
One, I had an extremely busy day at work, and so I did not have the brain power to do anything complex, so I needed the bar really low any way.
And two, I’ve realised, that I have always tried to just read a book and then leap mountains. I don’t know why. I must be a sucker for pain. And then when stuff does not work, I sulk and get frustrated.
Easing into hard topics like this, makes it more enjoyable for me and I learn better.
This is a meta skill, I should remember to use.
Come to think of it, everything I have learnt recently, actually learnt, has been this way.
I learnt Dvorak and touch typing, slowly, key by single key.
I learnt to diet and lose weight, by tens of grammes in the beginning.

So, note to self.
Start small.
Do the work.
Show up daily.

Read all about my OOP journey here

A Hundred Days of Code, Day 001 - Beginning With Classes

feedback@janusworx.com (Mario Jason Braganza) — Wed, 08 Jul 2020 18:08:05 +0530

Notes I’ve taken from the videos I watched, today. This is my attempt at Feynman-ing (below), what I learnt so far.

Classes and Object Oriented Programming started to come together for me, when I saw Kushal using them.

To use my father’s carpentry analogy, I could in theory just hammer nails into wood to join them.
But to make a really strong joint, I could use other methods.
I could screw pieces of wood together, which is markedly better than just nailing them.
I could chisel wood and create a dovetail or mortise joint.

So it all comes down to understanding what I want to do and figuring out the best technique to get it done.

Like I mentioned in the toot, I could in theory just kludge together all my primitives and create something.
But, if I want to create something beautiful and something that I (and others) can understand, I need to use a different method.
Object Oriented Programming, is a popular one.

Objects and Types (In Python)
#

We have objects and types/classes.
We can think of them like we do about cells in our body.
Python for the most part is natively made of objects.
Nearly every primitive I have come across in Python is an object.
Strings are objects and work a certain way / Skin cells work a certain way.
Dictionaries work a certain weay / Optical cells in the eye, work in an very specific manner.
Integers are objects and have their own ways of doing things, as do white blood corpuscles.

Objects are a special type of something.

A class makes objects.
An int class makes integers. A string class makes strings. And so on and so forth.

With Python even classes (the constructors) are objects.
So, there must be some kind of God / Creator thing that makes these primitives / originator classes.
And there is.
It’s the type class.
It’s the base class, the bottom turtle, if you will.
The type class creates all these primitive classes, which we then use to create other objects for our use.
The type of the int (integer) class is type as is the type of the str (string) class.
They are all objects of type type.

Which basically, again to use a physical analogy means that type is the iron forge, which i then use to create factories, which i then use to fashion usable things.
The forge lets me create lug nuts and chassis’ and then I take all these, to create a car factory, which lets me make cars of different types and sizes, with varying amounts of power.
The forge lets me create some mixer, which i can then choose to setup different sorts of mixer factories. Some can make ice cream, some can make porridge.
type (the forge), creates the int class (the factory), which lets me create all sorts of integer numbers to play around with.
type (the forge), creates the dictionary class (the factory), which lets me store and sling data about in various ways.

Note: This might not be true of other programming languages (for e.g. int might be a base primitive.)

Attributes
#

Every class can have attributes (data, or methods to manipulate data).
Those attribute themselves could be classes, having their own attributes.

Now each of those takes memory.
Python doesn’t gobble up all our memory however, because some (most?) objects share memory.

Run dir on an object to get it’s attributes.
For example, I could do this on the str class to see what it has.

>>> dir(str)
['__add__', '__class__', '__contains__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'capitalize', 'casefold', 'center', 'count', 'encode', 'endswith', 'expandtabs', 'find', 'format', 'format_map', 'index', 'isalnum', 'isalpha', 'isascii', 'isdecimal', 'isdigit', 'isidentifier', 'islower', 'isnumeric', 'isprintable', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'maketrans', 'partition', 'replace', 'rfind', 'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']

I spy with my little eye, that any string object lets itself be split or joined or lets its case be altered and much, much more!

I can go into any object I want (with few exceptions) and change its attributes!
For example, I type os.sep to get the path separator. (on a linux machine it’s / and on windows it’d be \ and if python ever ran on classic Mac os I guess it’d be :
I can just change os.sep to be ! or hahaha or whatever i want!
Or I could just add whatever attribute I want to any object!
In short, I can set and get attributes on any object I want!
Sounds pretty free-ing! Will have to see what this means in practice!

Aha
The inbuilt functions that I have learnt are not the norm.
Most code is written in classes and functions are available as methods of those classes.
Ruby natively works this way.
Python pragmatically, has created some functions as primitives.
(One possible reason could be, for example, rather than have a len method on every in built class, they musta thought it easier to create a primitive len function that worked on different classes and data types)
In real life (and across programming languages) I should mostly be looking at object.method(), for e.g. some_list.pop()
If I want to look at how to manipulate something, the general heuristic is to look at methods first. Does an object support manipulating itself through itself? After all, it knows itself best! :)

If I want to know what methods an object supports, I can of course call dir on it, but a better cleaner way is to call help on it. (help(list)). It shows, more clearly, the methods an object supports.

Why Classes
#

Do I need to create classes?
Of course not, I have been creating programs without them all these months.
A couple of reasons I’d create a class,

To stop kludginess. I don’t to expose a list of dictionaries, that contain more dictionaries that have lists as their values. better to abstract them away from the user (future me) and present simpler interfaces.
I love to write well crafted prose. Classes represent complete sentences in human language. Nouns and verbs amounting to a sentence that makes sense and is well crafted.

How do i create a class
#

Aha
Just realised that when I create a class, I am creating a new type of primitive for myself.
My own data type!
I can create my own numbering system if i want to!
Muahahahahahahaha
(comes back to reality)

class somethingsomething(object):
	pass

That is all I need. Just to say class, create a class with this here name! And *Abracadabra-Alakazoom*, Python goes ahead and creates a new class for us!

As I wrote above, this is a factory, to create new somethingsomething objects.
I can do that by just assigning it a name. Like Iron man summoning his suit out of thin air.

somethingblue = somethingsomething()

And boom! The object `somethingblue` materialises!

This is just a blank template, of course.
I cannot do much with this. (Right now, I don’t even know, what I can imbue this with, or use it for :P)
So I guess, the rest of the course will probably deal with how to make classes work and function the way I want them to.

I can add attributes to my classes just by declaring them.

somethingblue.color='sky'

somethingblue.liquid='ocean'

somethingblue.code=0x0000FF

And then i could `dir(somethingblue)` and it will give me them attributes, along with a list of everything it has inherited from the parent class (here the `type` class)

A neater way of looking at only what I defined, is to do vars(somethingblue)

Aha
Heuristic - While i can add attributes willy-nilly to any object I want to, it’s bad form.
The idea being that the factory (the class) should ideally provide a set of default attributes and values, so that not too much monkeying is required.
This process/template of assigning sane attributes is called a constructor.

The way we create a class is two fold (very Smalltalk-esque)

I create a class.
I add its attributes.

So when Python goes to create an object of the class, it does it like quite similarly

it creates as new object when i say object = class_whatever(), using the __new__ method
it then goes looking to see if there is an __init__ method in the class, and if it exists, then to use that to setup the default attributes
it uses the self (by convention) argument, to assign those attributes to the object. (I am applying shampoo to mine own self)
and then assigns it to the variable that’s supposed to catch the instance.
(I always somehow assumed it was the other way around. A variable in memory was assigned and then created like a building. This is more nature like. Stuff grows and then is assigned a name)
I can absolutely go do what I want, assign attributes however, but if I want to stay sane, I’d rather follow convention

And that’s about all I studied today.
Follow along the my Python OOP train here.

P.S. The Feynman Method.

Pythonoop on Janusworx

A Hundred Days of Code, Day 017 - Python, Advanced Objects, Done!

Notes #

A Hundred Days of Code, Day 016 - Python, Advanced Objects.

Notes #

Learning / Feedback/ Experiences from doing exercises #

A Hundred Days of Code, Day 005 - Magic Methods and Winding Up OOP

Notes #

learning / feedback/ experiences from doing exercises #

Final Words #

A Hundred Days of Code, Day 004 - Class Attributes and Inheritance

Notes #

learning / feedback/ experiences from doing exercises #

A Hundred Days of Code, Day 003 - Methods

A Hundred Days of Code, Day 002 - Basic Exercises

A Hundred Days of Code, Day 001 - Beginning With Classes

Objects and Types (In Python) #

Attributes #

Why Classes #

How do i create a class #

Notes
#

Notes
#

Learning / Feedback/ Experiences from doing exercises
#

Notes
#

learning / feedback/ experiences from doing exercises
#

Final Words
#

Notes
#

learning / feedback/ experiences from doing exercises
#

Objects and Types (In Python)
#

Attributes
#

Why Classes
#

How do i create a class
#