Bruno's Blog

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...

Disclaimer I will be upfront and say I think Python 3 made a terrible mistake by making is so that Python 2 scripts would no longer work. Most of my experience has been with Python 2 and I'm used to using the print statement to print a line to stdout . I hate that Python 3 makes you call print as a function. Yes, I know there are other differences and they're threatening to stop supporting Python 2 starting 2020/01/01. I don't know what I'll do after that point. I suppose Python 2 will still be around but it won't be improved and bugs will not be fixed and I may be ok with that. What can you deduce from print(expression) ? I've started a new job, looking at new code, and was without knowing much about the execution environment, I was beginning to believe that they must be using Python 3 because I saw something like the following in a Python script: print(expression) This seemed to be a reasonable conclusion. However, I also found code in the P...