will

Where there is a Will

Will McGugan's Blog

I am a freelance software engineer living in Edinburgh.

I post mostly about tech (particularly Python) and photography.

Background: A code monkey

I recently added experimental support for Jupyter Notebooks to Rich. Here's an example of the kind of output it can generate:

This is the Rich test card you can generate in the terminal with python -m rich.

Part 2 of the Rich test card.

Rich is a library for fancy formatting to the terminal, where-as Jupyter supports HTML natively. So why integrate one with the other? I suspect it may be useful to render something like a table in the terminal which also displays nicely in Jupyter. continue reading…

I've added progress bar support to Rich.

If you haven't seen my earlier posts on the subject, Rich is a terminal rendering framework for Python. It lets you render styled text and a whole bunch of other things (markdown, syntax, tables, tracebacks, etc.) to the terminal.

This latest addition to the lib renders progress bars with additional information such as percentage completed, time remaining, data transfer speed etc. It's highly configurable, so you can customize it to show whatever information you like. And since it's implemented as a Rich renderable, you can easily add color and formatting. Here's what it looks like:

An example of Rich progress bars continue reading…

One of my goals in writing Rich was to render really nice Python tracebacks. And now that feature has landed.

I've never found Python tracebacks to be a great debugging aid beyond telling me what the exception was, and where it occurred. In a recent update to Rich, I've tried to refresh the humble traceback to give enough context to diagnose errors before switching back to the editor.

Here's an example of a rich traceback:

Rich traceback on OSX continue reading…

Pretty log output

If you are a Python developer you may spend a large part of your day reading log output that looks like this:

Ugly log output

Front end tools like the Chrome developer console have far superior rendering for logs, but in the back-end we're stuck with an ancient technology that is older than most of the readers of this blog. I'm talking of course of the terminal which is likely to be the primary interface to back-end development until I retire.

Still I think we can do a little better. I wanted to use my terminal rendering library, Rich to render log output that is easier on the eye. The results are promising:

Pretty log output continue reading…

Normally, wildlife is my subject of choice, but I was recently in China and I had the opportunity to take this city scape...

I revisited the Isle of May recently. This time at the beginning of the Puffin season.

My favorite shot of the day. I like the way the bokeh background is still recognizable enough to be a feature.

There is something quite comical about this bird, like he is explaining something to a skeptical audience.

I was reading a post by Trey Hunner on why pathlib is great, where he makes the case that pathlib is a better choice than the standard library alternatives that preceded it. I wouldn't actually disagree with a word of it. He's entirely correct. You should probably be using pathlib were it fits.

Personally, however, I rarely use pathlib, because I find that for the most part, PyFilesystem is a better choice. I'd like to take some of the code examples from Trey's post and re-write them using PyFilesystem, just so we can compare.

The first example from Trey's post, creates a folder then moves a file into it. Here it is:

The code above is straightforward, and hides the gory platform details which is a major benefit of pathlib over os.path. continue reading…

I recently added a number of examples on working with files and directories with Python and PyFilesystem.

The first example, is count_py.py which recursively sums up the number of bytes stored in a directory, and renders it in a "friendly" format.

This script takes a path or a URL. For instance python3 count_py.py ~/projects will sum up the bytes of Python in your projects folder.

For me, this gives the following output:

This script accepts a path, but it will also work with any supported filesystem. So you could sum the bytes of Python in an archive or cloud server. continue reading…

It occurred to me that Django's ORM could do with a bit of a revamp to make use of recent developments in the Python language.

The main area where I think Django's models are missing out is the lack of type hinting (hardly surprising since Django pre-dates type hints). Adding type hints allows Mypy to detect bugs before you even run your code. It may only save you minutes each time, but multiply that by the number of code + run iterations you do each day, and it can save hours of development time. Multiply that by the lifetime of your project, and it could save weeks or months. A clear win. continue reading…

I've released PyFilesystem 2.1.0.

This version is the accumulation of many minor revisions, with multiple fixes, enhancements and some interesting new features. We also have nicer doc strings and Mypy compatible typing information, thanks to Martin Larralde.

If you aren't familiar with PyFilesystem, it is a common Python API to filesystems, whether its your hard-drive, archives, memory, FTP servers, or cloud services. The API is easier to use than the standard library, but works just about everywhere. See the Pyfilesystem Wiki for more information. continue reading…