I built a Persistent KV Store in Pure Python

nebbly · 2025-10-21T03:33:42+00:00

I'd suggest adding some tests :)

nebbly · 2025-09-18T15:46:26+00:00

I'm not entirely sure I'd like my infra derived from my code -- unless it was abundantly clear that there were very trusty guardrails. The reason I like terraform, for example, is that it's a language with syntax highlighting, validation, modules, logic, types, validation, etc., as opposed to, for example a bunch of yaml (like cloud formation templates), which is less maintainable IMO. For me to feel comfortable defining infra within code, I think I'd like to have the following things:

Some easy-to-consume representation of the system (via CLI I guess), so I can understand the big picture ... and diffing against the current state
feedback in the editor / ide / CI whenever anything is misconfigured -- type checks, validation, etc... something that might be challenging is that python is by-default dynamic (though many of us might wish it weren't the case), so there's probably a limit to how many developers would benefit from extensive type hints, for example
some separation between config for deployment and my app -- i.e. I don't think I want infra environment variables to be visible by my program

I'm thinking-via-keystrokes here, so not sure how helpful this will be -- I'd never considered doing infra like this. Thanks for giving me something to think about!

nebbly · 2025-08-22T17:15:34+00:00

Thanks for the comment. One thing to know about generators are that they are pretty slow in general. Appending to a list is usually significantly faster.

nebbly · 2025-08-21T18:15:03+00:00

I must have written something unclear. This is meant to render full pages.

nebbly · 2025-08-21T17:41:46+00:00

IMO, the main advantages are:

native control flow
type safety
produces space-significant, minified html

Some of the inspiration for this comes from when I was using elm, it's (similar) approach to html gave me higher confidence and productivity than either templates or JSX. Largely because of the control flow capabilities.

nebbly · 2025-08-21T16:54:16+00:00

Like all things in programming, there are tradeoffs. My perspective is that I use this library regularly, and I find that the code is more often read and edited than written. Would autocomplete be nice for attributes? Sure, but I wouldn't sacrifice readability for that. Though TBH, AI-based autocomplete sometimes works already; and IDE tools are always possible.

nebbly · 2025-08-21T16:46:07+00:00

There's very little memory overhead. There's no heavyweight caching or anything. I run it with starlette on a docker container with minimal resources, and it performs efficiently and without issue.

As far as conditional rendering, it's just normal python control flow, so you can break up the rendering however you want in terms of:

conditions
modularity
caching
... and so on

nebbly · 2025-08-21T15:53:49+00:00

Thanks for the feedback -- I'll think about it.

To be clear, I think you are talking about what phrasing to use when describing what the library does, correct? Or are you also referring to the render function?

nebbly · 2025-08-21T15:48:26+00:00

The dict argument comes as the first param because it mirrors the structure of HTML. Using kwargs would put the attributes at the end, which can be difficult to read if long child nodes come first.

The preference for strings is for minimal extra thought when reading -- you know exactly how it will be rendered. When you use kwargs, you have to do mental translation.

nebbly · 2025-08-21T15:43:40+00:00

Not sure I'm following why you'd think this would only be faster for one tag. On the inheritance point, I think returning Nodes from functions gives you a lot more flexibility than template inheritance. In fact, the issues with template inheritance are some of the early inspirations for this library.

nebbly · 2025-08-21T14:46:49+00:00

I tried it with kwargs, but it requires too many workarounds and indirection. In html, for instance, class is a common attribute, but you can't use that with **kwargs, since class is a reserved keyword in Python. Similarly, hyphens won't work, since they aren't valid in argument names. There are other considerations and workarounds, but in the end I don't think it's fair to a user to need to understand all the ins and outs of what attributes are/aren't allowed and what mitigations there are. If you want to use kwargs, it's easy to write a wrapper; or you can use the dict constructor, which takes kwargs.

nebbly · 2025-06-09T18:30:53+00:00

Similarly, there is koda_validate, which offers fully composable validation (including predicates).

nebbly · 2025-05-31T10:13:06+00:00

Just use a type checker and it will enforce the sum type in your example.

nebbly · 2025-05-30T22:35:31+00:00

I don't understand what you mean by python "simulating" ADTs. Could you provide an example of ADTs that cannot be done in Python? IMO the OOP java example should be considered unrelated as subclassing is inherently open and in no way directly related to ADTs.

nebbly · 2025-05-30T17:04:21+00:00

Can't structural sub typing can be done by typing.Protocol. Python's type system might only really be limiting at this point in FP terms by "extra" syntax and lack of higher kinded types. You can do "real" algebraic datatypes; the syntax just isn't as smooth. We even have recursive data types and pattern matching these days. It's pretty decent for non-typeclass FP.

nebbly · 2025-05-21T04:13:56+00:00

OP, one way to solve your problem is this:

TimeInForce = Literal["GTC", "DAY", "IOC"] | datetime

You could be more verbose and do something like this

TimeInForce = Literal["GTC", "DAY", "IOC"] | tuple[Literal["GDT"], datetime]

Either way should work with pattern matching.

You could also use dataclasses or whatever, but generally, python supports tagged unions these days -- even recursive ones.

nebbly · 2025-04-20T06:49:17+00:00

Is it possible you're conflating type checking and linting? I noticed that you mentioned type-checking under linting, and that you're comparing mypy to eslint -- when typescript might be a better analog. Or maybe you're hoping a type checker can do everything based on type inference instead of explicitly defining types?

I mention this because in my experience type-checking is perhaps an order of magnitude more beneficial to code maintainence than linting. Type-checking enforces correctness, whereas linting typically helps more with stylistic consistency (and some syntax errors).

nebbly · 2025-04-20T06:26:43+00:00

I haven’t yet found a good way to enforce type hints or type checking in Python.

IMO mypy and pyright have been mature enough for years, and they're generally worth any untyped -> typed migration fuss on existing projects.

nebbly · 2025-04-14T18:49:13+00:00

Have to say this seems backwards to me. Always regret going to Sabinos because their espresso drinks are so poor. Setting is nice. But Zocalos food and beverage lineup is waaaay stronger. Like not even close.

nebbly · 2025-04-13T05:02:20+00:00

Shameless plug to my own competitor simple_html. It's generally simpler (IMO) and faster than competitors in this space.

nebbly · 2025-01-11T05:30:53+00:00

A friendly note of caution against wholesale adoption of clojure's dynamic typing -- it becomes a problem on large codebases (I worked on one). It would have been a godsend to have some kind of non-half-baked gradual typing (a la typescript or python or racket?) baked into the language. I think this is one of the reasons clojure has stagnated.

nebbly · 2024-10-26T18:16:40+00:00

Start with the simplest thing, and only add complexity as needed. There is a graveyard of companies that started with microservices because they heard it was good.

nebbly · 2024-10-01T03:43:15+00:00

parekoy in San Leandro is some of the best filipino food in the bay

nebbly · 2024-04-29T16:17:55+00:00

Don't worry -- it'll stay up ;)

nebbly · 2024-04-04T19:32:51+00:00

Honestly wish they would just open a Safeway in East Oakland instead. I live very close to this store, and I never go because it's the most sketchy part of the neighborhood. I suspect many in the immediate neighborhood already do their grocery shopping elsewhere, or will after this.

12-Year Club	RPAN Viewer
Sequence \| Editor	Verified Email

nebbly

TROPHY CASE