Skip to main content

Posts about python (old posts, page 1)

Study, Day 4

Back at it after a short personal break. Lots of stuff to catch up on!

MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

Learning about lists.

  • They are
  • iterable, i can run through its elements one by one and do stuff
  • mutable, i can change things inside them
  • append, will append stuff to the end
  • extend, will take another iterable (another list, for example) and then take those elements one by one, and tack them on the the end of this one
  • i can go back and forth, between lists and strings, converting one to the other and vice versa

  • i can sort and reverse sort the items in them.

  • sorted will return a new list
  • .sort will mutate and sort the list itself as will .reverse.
  • since i can change them at will, i need to be careful about things that might break.
  • 10 names pointing to the same list. changing something in one, changes them all.
  • consider cloning a list and making seperate copies. (this is how’d i’d naturally do it. but is it expensive with resource usage?)
  • one example is iterating over lists
    • if you modify them as you run over them, it can lead to all sorts of trouble and confusion, if items get added, removed or changed
    • best to clone the list, iterate over the clone and modify your original
  • i can nest lists. have lists of lists!

  • you’ll get confused and make mistakes. it’s ok.

Learnt about Functions as objects

do i still remember functions?

  • pieces of code (functionality, my customised shit) that i write that i can call from elsewhere.
  • first class objects in python
  • can be elements of data structures (i can have a function in a list)
  • can appear in expressions
  • i can assign a function to something (a variable for example)
  • can use it as an argument to another function.
    • (i have a function that does things to lists. this function could call a function that sorts and sanitises the list, first)
  • basically, i can use them the same way i’d use numbers, or strings or lists

this inceptive programming, using function as arguments to others and combining them with other elements like lists (or inside lists to do shady shit on other lists)? it’s fancily called higher order programming.

  • i could apply a series of functions to a list
  • i could apply a series of lists to a function

and all this stuff generalised and abstracted are called higher order procedures
python provides something like this, called map
very simply put, map

  • takes a function that expects a single argument. (len for example or abs)
  • and then runs them on a list (or it creates a list where it applies that function to each element in it.
  • what it returns is an iterable (think of it as the elements of the list, coming out one by one, but you get your grubby paws on them, before they go into some defined data structure like a list.)
  • you can then do what you want with those hot cross buns, er, elements. print them. put them in a list. whatever. it’s all good.
  • i can now amp this up to a 11. map can
    • take n functions and run them on n collections of arguments.
    • simple example, run through the elements of two lists, compare them, and pop out the lower number for each element. print or save or whatever.
    • mind fucking blown. insert Keanu going, ’I know Kung Fu!’

Common operations across strings, tuples, ranges and lists

if i assume seq is any of these data structures, i can,

  • seq[i] - get the ith element in that list or string or range or tuple
  • len(seq) - get its length
  • seq1 + seq2 - concatenate two of them (not range)
  • n*seq - repeat them (not range)
  • seq[start:end] - slice and dice them
  • e in seq - will return true if e exists in the sequence
  • e not in seq - will return true if it’s not
  • for e in seq - will iterate over each element in that sequence


Why? They save me time!
Instead of indexing on numbers, like I do with the 1st element or the 0th element of a list, i can just index on things, I define myself

  • Like there’s a list of names and I can then attach attributes to them. relationships, address, phone number, whatever.
  • works just like a real dictionary. i can look up a word and then see all the information related to that word.

In python you create dictionaries using braces. and store data using key value pairs. here’s a few

  • dictionary_of_names = {} creates an empty dictionary.
  • dictionary_of_ages = {'Jason':40, 'Tess':48; 'Leo':76} creates a dictionary of names (keys) with their related ages (values)
  • and now I can just ask for Tess’s age with a dictionary_of_ages['Tess'] without having to lookup where and at what location Tess is in the dictionary

  • dictionaries are mutable

  • I can add entries (dictionary_of_ages['Puppy'] = 4 will add the age of my stray doggo to the dictionary)
  • I can test for existence of entries ('Leo' in dictionary_of_ages)
  • I can delete entries with a del
  • i can list my keys by calling the dictionary like a function using the keys method like so (dictionary_of_ages.keys()) and similarly I can get at the values with a dictionary_name.values()
  • unlike a proper dictionary though, there is no order to the way things are stored in a software dictionary. mostly its the order you shoved stuff in; and that can change.
  • on keys and values
  • values
    • can be any type
    • can be duplicated (different people having the same age)
    • can actually be any data structure (lists, numbers, strings, other dictionaries)
  • keys, on the other hand
    • have to be unique (can't have two folks with the same name. if they do, then probably time to think of indexing on something else?)
    • need to be immutable (which restricts me to ints, floats, strings, tuples or booleans. can’t have strings in there)
      • actually according to Prof Grimson they need to be hashables, but I’ll cross that bridge when I come to it.
    • careful using floats as keys, because of accuracy issues.

So because of their flexibility on what they can store and index on, dictionaries are much more capable than other data types

Testing & Debugging

It’s like soup!
You’re making soup and there are bugs falling in, from the ceiling.
So how do you get good soup?
You could,

  • Check the soup and remove the crawlies if any. (that is testing your code)
  • Keep the soup pot covered. (defensive programming)
  • Clean the kitchen, so there are no bugs (eliminate the source of bugs. debug it. kill it.)

Defensive programming is,

  • how do you structure your code?
  • how do you write code that plans ahead?
  • it has three parts
    1. write specifications for the functions you write
      • use docstrings
      • mention what you expect as input and what you will provide in return
    2. Write modular programs
      • break up your program into obvious pieces.
      • something that collects data for e.g., and something else that works on it (could be one, or more pieces) and something elser that delivers it out.
      • help you while testing, because you can test each little piece seperately
    3. Check conditions on inputs and outputs.
      • i don’t know what this entails, will update this later

Testing code, basically boils down to checking inputs and outputs.

  • What did i expect to come in? What is my expected result?
  • If stuff’s not working, what do I do to debug it?
  • What can I do to stress test and break my program?

Yikes! I have a bug!
How do I kill it? What do I want to do to fix this?

  • Look at the events that led to the error
  • Ask yourself, “Why is it not working? What’s causing that?”
  • and then having found that, “How do I fix it, so all is right with the world again?”

Set yourself up, for easy testing and debugging

  • Design code so this part is easy!
  • Is your code modular?
  • Are docstrings in place? What are you expected inputs? Output?
  • Document your assumptions. Why did you write this piece of code the way you did?

When you test you can,

  1. Unit Test
    • validate each piece of your program
    • test each function seperately
  2. Regression Test
    • if you find bugs, test for them the next time around
    • catch reintroduced errors that were previously fixed
  3. Integration Test
    • Does the overall program work?
      It kind of feeds each other like a cycle, so don’t hesitate to go around and round the testing circle.

Testing Approaches

  • Intuition
    • what do you think you naturally need to test?
    • what makes sense?
    • just pick things at random
  • Black box testing
    • use you program like an appliance
    • it says it does this on the box. well does it do it? does it do it well?
  • Glass box testing
    • look at the code and then test each path in the code
    • can’t do this with every path properly sometimes
    • do the big branches


  • Overt
    • the program crashes
    • your computer hangs
  • Covert
    • the answers might not be expected
    • they might look ok, but are actually wrong. (off by 1?)
  • Persistent
    • happens every time you run the program
  • Intermittent
    • happens only some times

  • Overt & Persistent
    • Easy to detect
    • use defensive programming to try to steer bugs to fall into this category
  • Overt & Intermittent
    • if you can find what’s causing it, yay!
  • Covert

    • Really dangerous. you might be relying on wrong results and data that you wrongly trust!
    • could be a really long time before you catch something like this
  • Be Patient. this will take time to get good at

  • Use print statements liberally
    • when?
      • enter function
      • parameters
      • function results
    • use the bisection method
      • divide and conquer!
      • print halfway and then decide which half to focus on
  • Be systematic. Use your little grey cells.
  • Figure out the common errors (type errors, value errors, syntax errors)
  • Logic errors, the program does not work as expected
    • think of programming as a novel you write
    • dream up the path
    • explain your code
    • walk around trying to create the model in your head
    • how did i reach this place? this bug?
    • try explaining it to some one (or your rubber ducky)
  • Use the scientific method.
    • look at what you have,
    • figure out what could be causing the error,
    • think about what could fix it,
    • and then try it.
    • is it fixed? no? go back and try again :)

Work with small things.
Work in increments.
Test and debug it.
Use backups.
Have versions.
Test and compare across versions.
Feel free to work up and down the version tree

Professor Grimson is awesome, and teaches me the way, I imagined some one teaching me CS basics. So many aha moments!

Study, Day 3


Lets see what this day holds :)


  • Did a review session
  • Made 15 flashcards

MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

  • goofed off on twitter and read articles on blogs instead of studying
  • learnt about tuples.
  • it’s been an hour & a half and I am still terribly distracted.
  • doing the dishes to regain focus. be back in 30.

Nope. cannot focus.
Annnnnd now there is no power. This day is done!
Will just sit at the window and enjoy the rain :)
Hopefully tomorrow is a better day.

Study, Day 2

Just did the MIT course all day today, because my next problem set is due tonight and I did not want to fall behind again.
Got distracted a bit, but a lot less than yesterday with the way Nikola renders headers, and youtube videos of sausage making :P
Now that I am going through the class, I realise programming is not what I imagined.
It is at once, much simpler and a bit more complex than I thought it to be.
More than that, I realise I can do this. :)

The day isn’t over yet. Will attempt to solve the problem set at night.


  • Did a review session
  • Made 25 flashcards

MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

  • Good programming
    • More code is not necessarily a good thing
    • A good measure is the amount of functionality, the utility, your program provides
  • The notion of abstraction
    • like a thing you know how to use.
    • the details of how it is internally are irrelevant to you
    • the box provides utility and you know how to use the controls to get what you want. that is all that matters.
    • like a phone. or a tv. or a scooter.
  • The notion of decomposition
    • i can take all those dumb black boxes that I know how to use
    • and mcgyver them together to do something I want.
    • use independent pieces of codey things that each do something and then glue them all together to get the program I want
    • or to invert, can i break my big problem down into small independent pieces that I can write, or use other folks’, that I can stitch into my own little frankenstein?
  • Decomposable Code, divide code into modules that
    • are self contained
    • are reusable
    • keeps you and the code organised
    • keeps things coherent
    • can be done with functions or classes
  • Abstractable Code, build a black box that
    • cannot see details
    • does not need to see details
    • does not want to see details
    • hides the gory details from you. or just the fact that your magical thing is made of small boring pieces :)
    • can be done with function specifications or docstrings
  • One new aspect of functions I learnt was that they have specifications.
    • Thinking back, it’s a well, duh! point, but I’m glad I learnt it explicitly.
    • there’s a contract between me, the author of the function, and its users
    • there’s a set of assumptions that the function has. this is what I expect, this is what I want, these are the values you need to pass, this is what the environment needs to look like, what is the phase of the moon?, yadda, yadda
    • and if those assumptions are met, there are guarantees I can make about the output.
      • pass these numbers in, in this sequence, and you will always get this output. put the dough in the oven, when the new moon is rising, and you will always get delicious pizza
    • in python, a docstring documents what the function assumes and guarantees. good programmers do this to help other folk using the function and to save their own future dumb selves
  • I learnt recursion
    • from what i understand, this means that i take something i know and then use it to repeatedly tackle a complicated problem, if said problem, lends itself to being broken down that way.
    • break it down until i reach a step where i know i can do all of the operations on my own.
    • multiplication is a good example.
      • I know that if when a*b when b is 1 is just a.
      • so I can write a function that keeps adding a to itself while decrementing b until b reaches one and et voilà, that value of a is my answer
      • I got that backwards. I know that i need to repeatedly add until b is 1. so i just keep adding a to a function that just asks if the value of b is 1. if not just add a to that same function where the else states that I reduce b by 1. when b is 1, i just return a which will be the first of the added as and the function then begins looping outwards and backwards adding a. I realise I have horribly explained it, but it’s somehow more intuitive and more elegant to my mind and fun to watch, so I’ll let Professor Grimson do it much better than I can
      • I still don’t totally get it, but I get that this is cool and makes tackling hard problems easier. Hopfully more understanding will come with time.

P.S. A note to student planet readers, if you miss some posts in that feed, check the site to see if I wrote anything (or manually subscribe to the main feed.) I might be uncomfortable pushing certain language or frustrations of mine to other learners at large.

Study, Day 1

Day 1 is an disaster of fantastical proportions.
I did lots of stuff.
But I got nothing of consequence done.
Save one big thing.
I managed to buckle down and study for six hours.
That counts as a win, a big one in my book.
Will hopefully get more done tomorrow.
If you are following this blog, the days might soon seem out of sync.
That’s because I’ve decided that Wednesday, Thursday and Friday are my days of study. Monday & Tuesday are for work, while Satuday and Sunday are for home and family.
I need to practice what I preach and have margins and boundaries in my life.


  • Created cards and a review sesion

Python Problem

  • I decide to tackle this first thing in the morn and sank like a stone.
  • I yak shaved for 2 hours (git issues, setting up a dedicated desktop space for study, rsync issues, syncthing issues, crontab issues, more git issues)and then took nearly another hour trying to remember things and then by the time I had some idea of how to tackle the issue, it was lunch time. Hopefully better luck tomorrow

The MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python course

  • I am hopelessly behind and playing catch up.
  • Already missed the deadline for the week one exercises.
  • Hopefully will be all caught up by this time next week.

I learnt

  • that iterables are things that can be counted. like beads in a string, or on a rosary.
  • strings are a form of iterable.
  • Bisection searches to find square roots are much more efficient than having to go slowly guessing our way up.
  • I should not compare floating point numbers (e.g. test for equality). Their internal representations might just be subtly different. Instead use the absolute value of the difference of the two floats. abs(x-y) instead of x==y
  • Start with a basic set of code, check to see what it runs on, and then see if small changes to the code can solve other similar problems or improve the efficacy of existing ones. (Newton-Rhapson better to find roots than Bisection guess better than incremental exhaustive guessing)

A Week of Python

Ok. Time to be a bit honest.
As you folks know, I have been trying to learn programming using Python since June 2017, when I joined the 10th cohort of DGPLUG’s Summer Training.
And time and again, I have failed.
Not just with programming, but with most other projects I tried to do.

At the end of my rope, I decided to just quit everything and considered (very seriously) a return to my old stressful career, thinking maybe that is all there is for me.

Two people saved me.

The first one was Kushal Das.
The man was absolutely bull headed about me being in the right place and that if anybody could do this, it was me.

The other was my better half.
Everyday I count my blessings and am thankful that I that she chose to share her life with mine.
She patiently listens to my frustrated rants and then tells me to just dust myself up and do it again.
That failure is not the end of the world.
And then she told me to do my physio.
And that I really could do this.

Just because you failed doesn’t mean you can’t succeed.
We all fail. Mentally resilient people realize that its not failure that defines your identity but how you respond.

Shane Parrish

So towards the end of last year I decided to focus only on one or two things at once.
And at that time it meant my 12th exams.
I studied really hard for three months.
And I did not finish studying.
And I am pretty sure I am going to bomb my exam results.

Then why do I sound so chirpy?

Because I realised Kushal and Abby were right.
That I can in fact learn.
The past four months have been an exercise in frustration.
But I learnt something new everyday.
I could test myself on what I learnt and realise that I did in fact know stuff.

Which led me to my lightbulb moment.
That I cannot do all my learning like those montages they show in movies.
All my learning came from stretching just a tiny bit, every day.
I learnt the basics of Accounts, and lots of Maths.

The difficulty of a task is irrelevant, if it’s vital to your success.

— Ed Latimore

And now that exams are done, I decided to turn my attention back to programming.
And so I made a big ask of Kushal.1
I decided to go to Pune, and try to pick up the basics of programming in Python all over again.
And he graciously volunteered to mentor me for a week.

And here I am a week later, writing all sorts of tiny little programs that do whimsical things and bringing me joy.
I obviously have miles to go before I can even grasp at fluency.
But this time, I am filled with hope and a good measure of confidence. It’s been a little nerve wracking and there’s been tonnes of head scratching and back stretching.
Kushal has been extremely patient with me, guiding me these past few days, making sure I stretch just the right amount.
And for that I owe him a mountain of gratitude.
Thank you so much Kushal! I hope to pay it forward someday!

I go back home now, and I’ll keep up the momentum with small incremental, regular periods of work.
I will log progress on the dtw blog where I can rant and rave to my hearts content.
My main focus will not be on results though.
Just to stretch myself everyday.
Improve myself just that little bit every day.
And then look back one day and be amazed at how far I’ve travelled.

The way you train reflects the way you fight.
People say I’m not going to train too hard, I’m going to do this in training, but when it’s time to fight I’m going to step up.

There is no step up. You’re just going to do what you did every day.”

— Georges St. Pierre

William Vincent’s list of programming books for 2019

Will Vincent, author of Django for Beginners and Rest APIs with Django has his list of book recommendations for the year.
Read the latest posts on his website to get at them.

If you are a learner like me and wanted a professionally filtered list, (as in too lazy to go hunt them down), this is a godsend.
He covers books on Django, React, Flask, & JavaScript and tutorials for Python, Django & React.

Also check out his year in review.

Thank you muchly, Will.

On Starting Summer Training at #dgplug

I started out with a very vague idea, of learning programming last year.

I went to Pycon India, fell in love with the community, decided to learn software, and came home all charged up. (Btw, I was so intimidated, I did not speak to a single soul.)

The plan was to sort personal issues, tackle a couple of major work projects so that I could then focus on learning, clear the decks and go full steam ahead come April.

While I made headway, I was also missing the hum and bustle of Pycon that had so charged me, but I did remember one session I attended, that had left me smiling was a sponsored talk of all things, by a certain Mr. Das. Off the cuff, naturally, warmly delivered.

So as I was looking for … someone to talk to, somewhere to belong, who comes along but Santa Das.

While that trip didn't quite happen due to personal reasons, we still kept in touch. (Why he would do that with a newbie-know-nothing like me, I don’t know. The man has a large heart.)

And when the new session of #dgplug was announced, I jumped at the chance!

To those not part of the dgplug summer training, read all about it here. The brave1 souls at the Linux Users’ Group of Durgapur take in a bunch of kids (and adults) who want to learn all about the magical world of software programming and give them tools with which they can paint on that vast canvas.

Our goal is to bring in more upstream contributors to various FOSS projects.
Through this training we show the path of becoming an upstream contributor.

— from the DGPLUG summer training page

Communication skills, free software projects, documentation, system administration, source code management, time management, conference proposals and obviously basic programming – the whole gamut is covered here.

So while any odd duck can learn on their own, the DGPLUG summer sessions will help you become a well rounded individual who can code and contribute to the world. A software finishing school, if you will :)

Kushal and the training and it’s successes have been featured in time and time again.

A look at the guest speakers (including the all father of Python and the cream of the Indian Developer community) should be enough to convince you to come join.

It’s only been a week, and I’ve been having a ball! We covered communication skills, touch typing and the vi editor this week! If you hurry, you can catch up and work with us.

And for my new #dgplug family, here’s a little something, something2 about me to close this post with …

  1. Yes, I am obviously hiding my big, fat tummy in the pic. :) 3
  2. I’m like a poor man’s, still failing James Altucher.
  3. Yes, I’m a lot older than most of you. :) 4
  4. I’ve been at this IT thing a long time. (since 1997, in fact.) 5
  5. And yes, only now do I get the bright idea to learn software.
  6. I love the fact, that I get you to be my plus-minus-equal.
  7. You folks make me feel all warm and enthusiastic and welcoming and make me feel like I found my tribe!
  8. I’m still head over heels in love with my better half, and live with her in a cozy li’l Thane (Mumbai) home, not far from my parents :)

I look to learn so much from you and know so much more of you over the coming months. I wish you all make good art!

  1. (& foolhardy, dare I say :P ) 

  2. My grandma says that :) 

  3. dropped 7 kgs to 89. Only another 20 to go! 

  4. not necessarily wiser :P 

  5. land line telephone fixer boy, hardware tech support at small firm, hardware tech support at huge firm, freelance engineer, consulting engineer, consulting manager. 

Why Choosing an Appropriate License for Your Project Is Important, Anwesha Das’ Talk at PyCon India, 2016

Anwesha Das, over at Law Explained India, was one of the speakers at PyCon India 2016.

(Update: Anwesha rocked Pycon 2017 in Portland. The awesome folks there, seem to have put up the talks in near real time! Anwesha’s talk is here. Check out the rest, here. End update)

And she to me, is a shining beacon of hope, when it comes to actually making it as programmer in this community. All she does, and the way the community responds is heartwarming

A lawyer by trade and a nerd at heart, she along with her team of bravehearts rocked PyLadies at Pycon India. From what (admittedly little) I’ve seen, this fearless group seems to be the only active PyLadies group in the country.

More power to them! And I really, really pray, may their tribe grow! India could do with lots more women, who in my opinion are better at programming than us lads. (And were in fact the first members and drivers of the profession)

Anwesha Das.

Her talk involved around generating awareness about the various software licenses in existence and their application to out software projects.

Being well aware of the ignorance, apathy and/or the strong dislike programmers have towards anything that is not coding, she walked through the various licenses that we could use, illustrating each one with examples.

Notable, was the amount of work she put into a project, where she grabbed and sorted the various licenses for the top few thousand packages on PyPI and used that map to make her points regarding licensing. You can go have a look-see here. Not just that, she’s been filing bugs to push developers to adopt a license, in case they did not have one :)

The last third of the talk, (in fact, the meat and potatoes) was on Best Practices for Developers when it came to choosing licenses for the project.

You can actually go read all about it here

Her point, in summary, (besides the how to) was to be intentional about what license you’d choose, to be aware of it’s ramifications, not just on you, but on the users as well.

I hope, PyCon India puts her video (and also the others) online soon.

Thank you, Anwesha. You were awesome!