bpartridge

# https://stackoverflow.com/questions/39068998/reading-connect-headers
# updated for Python 3
# WARNING: barely tested

import socket
import requests

from urllib3.connection import HTTPSConnection
from urllib3.connectionpool import HTTPSConnectionPool
from urllib3.poolmanager import ProxyManager

bpartridge

# This file extends and overrides parts of the ActiveAdmin DSL and internals
# in order to provide support for automatically displaying and editing images,
# which in our infrastructure are stored as URLs whose column names end in "img".
# Since this file will be reloaded frequently in the development environment,
# all operations done at load time (class_eval's, etc.) MUST be idempotent.

ActiveAdmin::Views::TableFor.class_eval do

  def img_column(col_sym=:img, title="Image")
    column title, sortable: false do |obj|

bpartridge

So Hooks finally started to "click" for me when I realized they're very similar to Python decorators. In fact, they're essentially Python-like decorators, curried against the renderer, in an alternate syntax that reduces duplicate typing.

To be clear: I'm NOT advocating for Hooks moving towards decorator syntax, and I agree with the reasons why this suggestion isn't the right direction to move. But I think that the comparison with decorators is useful nonetheless, and perhaps could guide some of the ways in which we introduce Hooks to skeptical stakeholders.

Consider, for a moment, that Python almost adopted this syntax: https://www.python.org/dev/peps/pep-0318/#community-consensus ...

using:
    classmethod
 synchronized(lock)

bpartridge

def patch_geos_signatures():
    """
    Patch GEOS to function on macOS arm64 and presumably
    other odd architectures by ensuring that call signatures
    are explicit, and that Django 4 bugfixes are backported.

    Should work on Django 2.2+, minimally tested, caveat emptor.
    """
    import logging