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
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
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:
With every web app there comes a time when you will need to serve up some static files. Maybe it is the JS or image files, or maybe you are just trying something out. Let’s talk about how to handle this in Flask.
Too many choices! https://flic.kr/p/5zVmy5
Over the last few years I have wound up using mongo as my data store on several projects. In fact, it has been a while since I have written any SQL! For my latest project I again reached for mongo to hold my data, but this time I decided to use the Python minimongo project as my ODM (Object Document Mapper).
What is minimongo?
An ODM is to no-SQL what an ORM (Object Relation Model) is to a SQL database. For Python, minimongo is a small lightweight wrapper around mongo. Minimongo is built on Continue reading
“Why flask? Why not Django?”
Recently I was asked this after introducing a new subsystem at work. Originally part of a monolithic Django app, this was new micro-service was one of the first pieces to be split out on its own. I had chosen Flask to be the web framework, and now it was time to explain why…
I’m not anti-Django, but…
While doing some performance test on a new flask microservice, I noticed it was not handling very very many connections per second. Additionally, nginx (which we are using as our front end webserver) was reporting a ton of errors. WTF?!? I thought flask was fast. I need a faster flask!
Racing to make a faster flask