Dane Hillard

Selfie with a group of people each holding an ice cream cup with various ice cream flavors, inside a candy store. Left to right: Carol Willing, Mariatta, Dane Hillard, Dawn Wages

Thanks for a great conference @pytexas.org
I had fun. All the talks are really good, I learned many new things.
Closing it with an #IceCreamSelfie with @willingc.bsky.social , @dane.dev, and @bajoran.engineer
At Yummi Joy. I had the Pandan and Squid Ink ice cream (vegan)
#PyTexas

Today on our Speaker 📣 Spotlight 💡 we're highlighting @dane.dev who will be presenting Place-making and Productivity: Build Maintainable Broad-scale Tools With a Small Team.

Join us April 13 either in-person or virtually to watch. Get your tickets today pytexas.org/2025

Authors, if you see this, it's a sign to post the first line of your book.

"Python, like me, was born in December of 1989."

-- Practices of the Python Pro

pydantic.run

Meet pydantic.run - a python sandbox for writing, sharing and running Python code in the browser.

For example, here's sandbox with examples of @logfire.pydantic.dev instrumenting an HTTPX request and a @fastapi.tiangolo.com server using a sqlite database.

pydantic.run/store/c81c32...

We’re building a new static type checker for Python, from scratch, in Rust.

From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep!

Oof, this is my signal to book my PyTexas travel…

Happy to be included alongside both new and familiar faces talking about some great things at @pytexas.org 2025! I see APIs, WASM, embedded, testing, observability, security, and more on the docket!

See you in Austin 🐍

It seems like I could grab every command iteratively from the Click app and do something with it in Typer, but I think I’d have to manage all the argument and option type mappings too, which breaks down when an app uses custom types. Because then I have knowledge of the app, again.

For Typer-in-Click you can get Typer’s generated Click app through some utilities available in `typer.main` and add it to another Click app as usual as well.

It’s tantalizing because Typer uses Click under the hood, but it’s creating the Click app on the fly. So wrapping an existing Click app is a different beast.

For Typer-in-Typer, you can “just”install the package, import its main app, and `typer.add_typer` it to your own app as a subcommand.

Namely I’m trying to channel @simonwillison.net’s `llm` to devs through our internal CLI and I want to avoid cloning all the option and subcommand names and so on in my own code. This makes more work for me, but also makes the code brittle to new releases of `llm`.

Has anyone successfully wrapped an existing Click app as a subcommand of a Typer app in a generic way? Typer-in-Typer is easy, Typer-in-Click is easy, but Click-in-Typer has proven nigh impossible without the Typer app knowing details of the Click app.

This project is also a monorepo of AWS Lambda functions alongside some packages, but none of them are particularly isolated from each other, proving quite challenging. I feel that in a monorepo the projects need to be readily extractable at any time, with a management tooling layer on top.

This was also at the tail end of a pairing session on a code base that has some challenging dependency injection patterns that we already gave up on during the session. We couldn’t for the life of us get a particular call site to behave how we wanted. More to fix soon…

Yesterday I learned something new about pytest! When using `with pytest.raises`, the line that raises the expected exception must come last in the block. Lines after it won’t be executed. This makes sense in retrospect (context managers) but cost me a few minutes of being befuddled.

I noticed this from my ballroom dance coaches; they’d often start you off with incorrect but ballpark mental models, and when you were finally ready they’d say “well so it isn’t *quite* like that after all…it’s more like this.”

Inquisitive me got occasionally frustrated, but it worked well overall.

The cumin lamb ones are pretty good. Have purchased multiple times 🙈

The building having a hard time adjusting to the current temperatures and being a stiff 67 degrees or so has little charm to it.

This Dane is quite vulnerable to cheese

All good here, on a project using py311/12/13 + pytest + pytest-cov with branch coverage reporting!

A photograph of an office desk with a Kalita Wave pour over coffee brewing setup, a Picasso ceramic mug, a MacBook Pro with jazz playing on Spotify, and an external monitor with a fireplace YouTube video playing.

Being on an absolutely empty floor of an NYC office on Christmas Eve making pour over coffee and working on self-directed things has a certain charm to it.

Are you an open source maintainer? Comment below 👇 and find others in the community on 🦋

This was an enthralling talk indeed. Thank you for sharing 🙂

There’s no gap on *my* machine 🤷🏼‍♂️

How do you catch a unique beaver?
Unique up on it.

Hope do you catch a tame beaver?
Tame way.

Thank you to our 12 candidates for the Django 6.x Steering Council elections! www.djangoproject.com/weblog/2024... We’re elated to see so many stellar contributors rise to the challenge 🚀 Now time to vote! #python #django

A great many WHATs aren't that special, and creating a service for a WHO that is really just doing a WHAT but naming it as if the WHO is very special and deserving of bespoke treatment means you may not be thinking about all the aspects of the WHAT and WHO ELSE might need to do that WHAT.

When e.g. merging platforms or products or businesses you'll maybe want to extract the lowest common denominators and rename them WHAT they do. You might still need layers that serve the different WHOs, but only if they are specializations. Much like an inheritance tree.

If you have something that's already named after WHO it serves, it's probably already doing things it doesn't say it does, and should be avoided for use by others, because now both the WHO and the WHAT in the name are wrong.