Skip to main content

Dedicated time for learning Python at work

In the spring of 2019 I had the opportunity to use some paid work time for learning something new.
I decided to spend the given time to brush up on my Python knowledge. I had some experience in programming with Python but not much and I didn't have a understanding of Python conventions or ecosystem.

Limited time frame

I had a limited time frame that was split to four sessions. In addition to the time given for each session I spent at least the same amount of time on preparing each session.

First session, the basics

It was quite hard to find a resource that summarised Python basics on a sufficient level but I managed to find Alex Martinelli's slides Python for Programmers from 2007 that contained exactly what I was looking for.
Even though the slides are from over a decade ago and the Python version was 2.x at that time all the information is still applicable to current Python 3.x version as is or with minor changes.

Second session, testing in Python

Python has a good support for automated tests and it wasn't too hard to find two good resources where to learn. First I read a short introduction to Python's unit testing libraries from the Hitchhiker's guide to Python. After that I went through a longer, more profound, tutorial from Real Python.

Third session, functional programming in Python

I knew that Python supported functional programming concepts and the best resource that I could find was Python's own documentation that also explained some of the gotchas I ran into in my earlier Python programming experiments e.g. map function returns a iterator not a list or set or what ever was the input's type.

Fourth and final session, asynchronous programming in Python

With the rise of FRP and the Reactive Manifesto I thought that introducing myself to Python's async IO would be a good idea. For me the Real Python's tutorial on async IO was the easiest to understand and I think it's quite comprehensive.

Syllabus for Python for programmers

  1. Basics, Alex Martinelli's slides http://www.aleax.it/goo_py4prog.pdf 
  2. Testing, the Hitchhiker's guide to Python https://docs.python-guide.org/writing/tests/ and Real Python's getting started with testing in Python https://realpython.com/python-testing/ 
  3. Functional programming, Python's own documentation https://docs.python.org/3.7/howto/functional.html 
  4. Async IO, Real Python's tutorial on async IO https://realpython.com/async-io-python/

Conclusion

It took me around 6 hours to read and somewhat understand the contents of all the resources of the sessions. I already knew Python's syntax and had a solid understanding of other programming languages and I knew all the concepts that were covered.

I haven't worked with Python since the sessions but next time that I will, I'll first browse through these resorces.
Labels:

Popular posts from this blog

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does...
Read more

Simple code: Integration tests

Integration test is something that tests a functionality that is dependant on a external system e.g. a database, HTTP API or message queue. Integration vs unit tests The line is thin in my opinion. The integration part can be faked or a embedded services can be used in place of the actual integration point and with these solutions the interaction with the external system is bounded in the test context and the tests can be executed in isolation so they are very much like unit tests. The only difference with this type of integration test and unit test is that the startup time of the embedded or faked system usually takes some seconds and that adds total execution time of the tests. Even though the total test exection time is longer all the tests need to pass and all the cases need to be covered whether there's external systems involved or not so the importance is equal between the test types. This is why I wouldn't separate unit and integration tests from each other within the co...
Read more

Simple code: Simplicity

Simplest solutions are usually the best solutions. We as software developers work with hard problems and solve a lot of small problems every day. Solving a hard problem itself is a hard job. Though in my opinion it's not enough to solve a hard problem in any possible way but a hard problem should be solved with a simple solution. When a developer comes up with a simple solution to a hard problem then they can declare the problem solved. First a disclaimer. Coming up with a simple solution to a hard problems is itself a very hard problem and takes a lot of time, effort and practice. I've seen my share of "clever" solutions for hard problems and the problem with those is that usually the solution itself is so hard to understand that depending on the size of the problem it may take a developer from hours to days or even weeks to understand how that "clever" solution works. It's a rare occasion when a developer has come up with a simple solution to a hard pr...
Read more