The other day I stumbled upon Python __debug__ and I thought I would share some interesting things I learned about it.
What is python __debug__?
It is a constant that Python uses to determine if calls to assert should result in code being generated. If you have the -O optimization flag set, then assert calls will not be “triggered” in your code, even if the condition it is testing is true.
Interesting fact: according to the documentation it is one of two constants that will raise a SyntaxError exception if you attempt to assign something to it. (The other constant that does this is None.)
For example, in python you can do this:
Totally legal. Not smart, but legal.
And that is totally legal in Python 2.x. (Python 3 wisely does not allow this!) I would not recommend doing this, as your co-workers will hunt you down to express their “displeasure”. But if you try that with __debug__ or None, you’ll get an error:
The only two “true” constants in python
Normally I’m not a fan of these types of language tricks, but this looked pretty cool to me and I thought I would share. I do find it interesting that in Python 3 they have True and False locked down to be true constants. Honestly, I thought there would be more language keywords that would be protected like that.
In a previous post I mentioned an issue I had with some python code that failed in a way I hadn’t expected.
Long story short, I was in the wrong which does happen from time to time. Aside from the actual bug, there was another failure: I thought my tools were checking my work. It turned out this was not the case!
I’ve been a big fan of flake8 for some time. Its ability to find PEP8 issues is a big help, and most of the time I find that it tends to root out problem code before it gets too bad. When I was dealing with that bug I was using PyCharm. I’ve since started using emacs, but would that have made a difference?
It turns out if I had been using pylint I might have caught this issue. I’m placing the emphasis on might there because there’s a bit of overlap between flake8 and pylint that I wasn’t aware of. Let’s explore them a little bit more. Continue reading
Navy SEALs jump from the ramp of a C-17 Globemaster III over Fort Picket Maneuver Training Center, Va. (Air Force photo by Staff Sgt. Brian Ferguson)
In the Navy SEALs they have a saying: Everyday you have to earn your trident. The trident is the symbol that sailors earn as they complete the training that makes them part of the elite SEALs. It is possible to lose one’s trident however. To prevent a behavior that might cause this, the SEALs remind themselves that everyday they have to “earn (the right to wear) their trident”.
As I spend more time in the programming world I have come to realize there is great wisdom in this approach. A good friend of mine once told me that “Experience and skills are expiring assets.” In other words, if you don’t use them, you loose them. Just because your job title has the word “Senior” in it, you don’t automatically get a pass. You need to earn that title every day.
So as a programmer, how can you earn your place? How can you improve who you were yesterday? What does it take to make sure you are becoming a better programmer? Here’s what I’ve been doing. Continue reading
I’ve become the Johnny Appleseed of Continuous Integration servers.
After I was bit by the testing bug, I quickly developed an interest in CI and began setting up servers at the places I worked. The benefits of letting a computer run the test automatically are so appealing. It cuts down the number of “dumb” bugs that are generated. It also helps ensure that the code is still working the way it used to.
What is a “dumb” bug? It is one of those bugs that is very simple (like a missing parens) and is found as soon as another person takes a look at your code. The discovery usually leads to a facepalm by the developer who did it.
Over the years as I’ve traveled to different companies I’ve been able to help introduce various Continuous Integration servers to other developers. If you would like to learn more about why CI is important, I will to point you to THE resource that I learned from, Continuous Delivery by Jez Humble. Its a big read, but it really covers the topic well and offers a lot of useful strategies.
Here’s a run down of my experiences with 4 different Continuous Integration servers. Continue reading
Before coming to Python, I did a lot of work in Java. Java is pretty good language and environment, but it is different than Python. Beyond the language syntax there’s a ton little differences to be aware of. Sometimes when we move from Java into Python it shows by some of the things that we do.
Here’s some things I’ve learned over the years, (or things that I’ve stubbed my toes on recently). Continue reading
Debugging with real bugs
Recently at work I discovered that everyone on my team had different approaches and tools they used for python debugging. Here’s a quick run down of some of the favorite tips and techniques that we came up with. This list is ordered from simplest to more advanced. Continue reading
Mindset is everything
To software developers, the word “agile” usually conjures up thoughts of project tracking, story points, and team velocity. To truly be the most effective developer that you can be, the word agile should also remind you that change is constant and that you must adapt. An agile mindset is the greatest tool a software developer can possess.
Too many software developers fall into the routine of their process. We work our stories, finish our sprints, and move on to the next iteration. While this does allow software to be produced in a predictable manner, it also can shackle developers. When facing a new challenge that challenges their existing mindset, these shackles can hold a developer back. Continue reading
Every time I think I’m doing pretty good with my projects, I take look over and see what Elon Musk is doing. Then I instantly feel like I’m wasting my life. That guy does such huge things and he does them so quickly it is mind boggling. What is his secret? Can I be like that?
The answers is yes, if you use “First Principles” reasoning. I have found that when you apply first principles to debugging software that you will get to better solutions. So what is first principles? Here’s Elon explaining the how and what of it:
So here’s the take away:
In most workplaces, software developers have someone who tells them what to do and when to do it. Managing projects usually is the responsibility of a Project Manager, Scrum master, team lead, or even just “the boss”. But what happens when you don’t have that guidance? Or of you are working on side project by yourself? Here’s how I manage my projects.
If you are going to succeed on a project you’ve got to have a plan. A plan has a start, an objective, and the series of steps that have to be taken to get to the objective. Continue reading
In the world of software development there’s always something new popping up. New languages, frameworks, operating systems, databases, you name it. The challenge for a developer is to stay on top and ahead of these new technologies. It can be very tempting to give up and not learn anything new, but I want to propose that learning new things like a new language or framework can be very helpful!
Learning begets learning
The more you practice the art of learning something new, the easier it is to learn new things. This sounds like tautology, but it is true. Continue reading