Ontowhee's Newsletter

Subscribe
Archives
August 13, 2025

Custom ticket fields, casting to boolean, and numbers module

This week, I learned a few new things about Python, Trac, and SQL as I continue iterating on the contributions data in Trac.

Django Contributions Weekly - Y25 W32 - Aug 4 - 10

These metrics are generated using the tickets that were modified during last week's time frame. I've removed the "End Of Week Queues" and "Turnaround" metrics, because they are not very meaningful. I'll want to backfill the data that is missing in the database and redo the queries to get more meaningful results.

The metrics included below are not too useful with their current method of analysis and presentation, so take them with a grain of salt, but it is fun to see who has contributed recently.

Overview

There was a total of 42 modified tickets last week. 21 of those were open, and 20 were closed, and 1 was Someday/Maybe.

Components

  • contrib.admin: 13
  • Database layer (models, ORM): 10
  • contrib.auth: 3
  • contrib.staticfiles: 3
  • HTTP handling: 2
  • GIS: 2
  • Core (Management commands): 2
  • Utilities: 2
  • Documentation: 2
  • Internationalization: 1
  • Testing framework: 1
  • contrib.admindocs: 1

Activities

These are counts of activities that happened last week.

  • Assigned: 5
  • Reviewed: 9
  • Coded: 10
  • Discussions: 56

Contributors

There were 19 contributors.

  • Drew Winstel (drewbrew): 1
  • Olivier Dalang (olivierdalang): 1
  • Colleen Dunlap (colleen85052): 1
  • Carlton Gibson (carltongibson): 1
  • Chaitanya (XChaitanyaX): 1
  • Xdynix (Xdynix): 1
  • shrutisachan08 (shrutisachan08): 1
  • Michał Górny (mgorny): 1
  • Adam Johnson (adamchainz): 1
  • Mridul (mriduldhall): 1
  • David Smith (smithdc1): 1
  • OutOfFocus4 (OutOfFocus4): 1
  • Leandro de Souza (leandrodesouzadev): 1
  • Jason Hall (Jkhall81): 2
  • Jacob Walls (jacobtylerwalls): 2
  • blighj (blighj): 2
  • Antoliny (Antoliny0919): 4
  • Natalia Bidart (nessita): 17
  • Sarah Boyce (sarahboyce): 23

Fun Facts From Trac - Custom Ticket Fields

The ticket_custom table allows Trac to be extended with custom fields. For example, Triage Stage, Has patch, and Needs tests are custom fields, because they were added specifically for the Django project. The ticket_custom table consists of the columns ticket (int), name (text), and value (text). For the flags mentioned earlier, the name column stores the field names as "stage", "has_patch", and "needs_tests", respectively.

There are 42 tickets that exist in ticket_custom but do not exist in ticket or ticket_change. They are likely spam or security reports that were deleted, but the data in ticket_custom are now orphaned.

Fun With SQL - Casting To Bool

In PostgreSQL, the expression ''::bool is not allowed. The empty string is not a valid input for casting to bool. Valid text inputs are the following: (case insensitive) '0', '1', 't', 'f', 'true', 'false', and surprisingly NULL. Yes, you can run NULL::bool in PostgreSQL, and it returns NULL.

I found out about the empty string because some of the ticket flags in Trac were stored as the empty string. It's not certain why the value is an empty string. It occurs on two tickets (9085, 13882) over the course of 20 years, so this is trivial enough assume they are false.

There are also tickets that are missing some of the flags. This occurs for at least 734 tickets, as recent as 9 years ago. It's not clear why this happens, but I converted these values to be false, because that is how they are rendered on the ticket page on the website.

Fun With Python - numbers Module

Python has a numbers module which defines 4 classes for different types of numerical representations, Real, Complex, Integral, and Rational, along with operations allowed for that type of number. The base class is Numeric, and it can be used for checking if a value is a numeric type.

import numbers

isinstance(1, numbers.Number)
>>> True

I came upon this module because I was returning a string "N/A" for some of the metric values, and ran into the error when calculating an average: TypeError: unsupported operand type(s) for /: 'str' and 'int'. A quick search led me to stackoverflow. With the numbers.Numbers class, I can check if a value is a numeric type before running a calculation.

In Brief

  • PyLadies Con 2025 takes place Dec 5-7. The Call for Proposal has been extended until Aug 22.
  • Djangonaut Space Session 5 will take place Sep 29 to Nov 23. Applications are open now until Sep 14.
Don't miss what's next. Subscribe to Ontowhee's Newsletter:
Powered by Buttondown, the easiest way to start and grow your newsletter.