You should not be using Python types without a type checker in use to enforce them.

With a type checker on, types are fantastic for catching missed cases early.

I intentionally avoid using us-east-1 for anything, since I’ve seen so many outages.

us-east-1 is often a lynchpin for services worldwide. Something hinky happening to dns or dynamodb in us-east-1 will probably wreck your day regardless of where you set up shop.

> If you didn't know, you can embed JavaScript into an SVG file.

Oh yikes. I did not know.

I’ve been meaning to write this article for a long time @flexdinesh . Thanks for taking the time to share this technique for managing stacked diffs using vanilla git rebase!

I have to take special effort to tamp down on duplication in AI generated code.

For me it's not uncommon for AI to draft an initial solution in X minutes, which I then spend 3*X minutes refactoring. Here's a specific example for a recent feature I coded: https://www.youtube.com/watch?v=E25R2JgQb5c

mypy is compiled using mypyc. It does not run as Python code.

The semantics of Python makes it problematic to run at speed, it is not just about interpreted vs compiled code. Give the high levels of dynamic behaviors that are allowed, a Jit (like pypy) has a higher chance of getting decent performance if the code has an underlying behavior that can be extracted.

mypy is also written in a style conducive to speed ups when compiling with mypyc

For HTML-in-HTML natively I use iframes and still remember how to use Frames & framesets.

I find it amusing that the motivation for creating a complex font program that supports syntax highlighting internally is the desire to avoid a complex syntax highlighter JavaScript library. The complexity is still there; it's just been moved around.

Edit: Perhaps this is a reminder that custom fonts are a potential attack vector for security-sensitive websites since font rendering runs highly-complex programs, probably in a language that isn't memory safe.

This makes me curious; have there ever been security exploits that utilized the font rendering as an actual attack vector? To me it feels like font rendering should be pure (in the functional sense) and thus have no side-effects, but of course that doesn't mean anything in practice.

Yes, pretty disastrously: https://kb.cert.org/vuls/id/354840/

As you have guessed, this used a rendering feature that was not pure.

Tesler's Law

Looks like this library is serious. Most of what I see can be written more succinctly using existing Python functionality:

  1. Maybe -> Optional[T]
  2. Result -> Union[SuccessT, FailureT]
  3. Future, FutureResult -> concurrent.futures.Future[T]
  4. IO ->  don't use this; none of the standard library I/O supports it

I do appreciate the use of "container" as a term instead of "monad".

I also appreciate the typechecker enhancements being put forward by their custom plugins.

None of these has the functionality that the library offers, i.e. providing an interface to compose functions that consume and produce these types.

I believe the recent idiomatic recommendation for the first two is to use the union type expression:

  1. T | None
  2. SuccessT | FailureT

This is potentially quite helpful, but would you happen to have a source for that?

The Union Type PEP[0] suggests that the "bitwise or" syntax is equivalent, but cleaner than typing.Union

[0]: https://docs.python.org/3/library/stdtypes.html#types-union

Thanks! I missed that.

They're both perfectly valid; but the expression style [0] is shorter and more obvious, especially compared to Optional. Even the documentation for Optional states [1]:

  Note that this is not the same concept as an optional argument, which is one that has a default.

[0] https://docs.python.org/3.11/library/stdtypes.html#types-uni...

[1] https://docs.python.org/3.11/library/typing.html#typing.Opti...

WhatsApp is owned by Meta/Facebook