Bruno's Blog

Why I don't like Python 3 Python 3 sucks.  I hate that they've made changes so that aren't backwards-compatible.  You can't run many Python 2 scripts using the Python 3 interpreter.  It's almost like they've gone out of their way to piss off developers. Here are some specific reasons why I hate Python 3: My biggest gripe: print is a function rather than a statement now.  I'm not saying it's not a good idea for print to be a function but why fuck with existing scripts?  Just keep the print statement as-is and create a new function with a distinct name. Data read from files comes back as bytes and you have to encode them.  More on this later but I think this is nonsense. You can't write a simple string to a file opened for binary.  Yes, I know about string.encode() but my point is I don't like having to use it. You can't turn off buffering when you open a text file for writing: open('foo', 'w', 0) throws  can...

Extra Cygwin packages I'm a big fan of Cygwin on Windoze to get the Unix/Linux look and feel. I can't stand the Windoze command prompt and their Power Shell is ridiculous. I don't want to get on another rant but I thought Power Shell was supposed to be their attempt at making Windoze more like Unix but it isn't. Yes, I have looked into WSL and it's ok but I'll stick with Cygwin. One of the things I don't like about Cygwin is that their default list of packages just isn't enough for me. After I install it on a new system, I often find myself adding additional packages one-at-a-time when I discover I need them. I finally decided to be a little proactive and keep track of packages I had to install. It looks like my beautiful formatting of this page has been trashed somehow and I apologize for that. I'll work on it. My extra packages Package Comments git Gotta have this! pip2 Yes, I'm still a proud Python2 guy! An...

I got into the habit of using Python unit tests in a job a few about a year ago. I eventually created the jsonhunt.py unit test in my Toys repository but it stopped working. I haven't even used the jsonhunt script in a while and am no longer certain of its usefulness but I don't like the idea of not being able to do unit tests if I wanted to. Simple working example So I sat down and got a simple unit test working. Here's the test script: Notes I wish I had found a way to see options or arguments in the test but I couldn't find a way to do that. I had to settle for an environment variable to control the logging level. From the job I mentioned, I remembered we had a way of specifying the log level through some sort of option but I couldn't find a opportunity to get such an option, even through the superclass. At first I was trying to use a zero-argument constructor method but that wasn't working so I added *args, **vargs . From the command line...

I had this idea of generating version information for a Python script that uses ArgParse . The code is a little more than I was expecting but I think it works well. Here is the code: Usage Here is an example of its usage if the script is part of a git repository: $ ./version-example --version b92798, master, 2019-01-18 10:35:02, ['origin:https://github.com/pfuntner/gists.git'] $ It contains: The SHA1 of last git commit that changed the script The current branch of the repository The date of the commit - I think the timezone element is present in this but I didn't want to deal with timezones so I'm ignoring it A list of the remote repositories This is printed on two lines but that's something that ArgParse is doing, not me. Here is an example of its usage if the script is not part of a git repository - we don't have much information to work from but we can at least get the timestamp of the script: $ ~/tmp/version-example --version 2019-01-...

The native logging class in Python can be a little cumbersome and daunting to use. I've combined the use of ArgParse along with some simple use of logging as an example that solves a lot of problems I often want to solve: I figure I'll refer to this example when I want to make use of logging in scripts in the future. This example does the following: Default logging level is to print warning, error, and fatal/critical error messages. Debugging and warning messages are not printed Using one -v option prints all of the messages above including informational messages Using two -v options prints all of the messages above including debugging messages Using three or more -v options does not change the behavior from using two options. There is no error but there is no benefit to additional options either You can specify an explicit log level and even reduce messages using -loglevel LEVEL where LEVEL must be one of: DEBUG INFO WARNING ERROR CRITICAL The scri...

Maybe it's my use of the getopt() function in C/C++ but in my Python scripts, I've always just made do with the native getopt package and it's served me well. Over time, people have encouraged me to look at using ArgParse but I've always been kind of resistant because it was a little mysterious to me. I finally sat down and figured out how to do basic things I do a lot in scripts using getopt and worked up a simple script using ArgParse to do the same thing. There are definitely some advantages to ArgParse ! Here's the gist with this sample: I've made a few updates to the gist as I discover new features of which I want to take advantage: Mutually-exclusive options Script description etc. I will admit that since I've created this gist, I've been using ArgParse for new scripts. I can't whip out a script using ArgParse from memory yet (which I can do when I use getopt !) but it's becoming easier. I haven't gone back and...