That's true, but that's just one model that has some easier setup in the ecosystem. It's not easy to get a consumer gpu that has 128Gb of vram, so while the Halo chip isn't as performant, the ceiling for running larger models is higher.
> simple chart specs can be reliable, but generated charts are often of low quality due to reliance on system defaults; - complex chart specs with explicit details can produce good-looking charts, but they are verbose and agents can struggle with reliability
N of only a few of us working on an analytics agent, I don't think we've been finding this to be the case. We've been impressed with just how good LLMs (even smaller open weight models) are at using Python and R for visualization. Often any shortcomings go away if we iterate a bit to about ambiguity. Are there any threads of research that could better support this claim or highlight where issues might be?
I no longer keep my dotenv files in plaintext. I use `sops` to keep an encrypted env around and you can use tools like direnv to make them available to your shell while you're working. Obviously the LLM could print any of these secrets, but it's less likely. Additionally I find that at least claude seems to avoid reading the dotenv. And lastly, don't make any local secrets that important. Limited scope, dev accounts, etc.
Yeah, that's cool, but it would be almost completely unnecessary if python just had actual private methods/classes/properties. It's a lot like pydantic, which is completely unnecessary if you had strong typing.
Yes, but:
a) they're a second class citizen, not guaranteed to be used in whatever niche of the python ecosystem you find yourself in and there's already an n+1 problem with multiple type checker written by third parties, rather than having 1st class language support tool that's consistent. You're not going to get it by default, you're usually going to have to do some configuration (and maybe bike shedding) to get it working;
b) they completely negate the idea of python being "easy to read", your code is now littered with `if TYPE_CHECKING:`, `Literal`, `TypeAliasType` and any number of workarounds needed to make your hints work out. Unfortunately the syntax was just not designed with typing in mind, and I think it shows;
c) the idea of "hinting" rather than enforced type checking means you have no guarantees that a type is what you need it to be, you have to do a lot of boundary work to make sure the edges of your code are coercing things to the right type. While I love pydantic and find it to be an excellent library, to me it's the kind of code smell you get in languages without strong typing. Also you're going to get a lot of spurious type errors along this path as well;
I will gladly use python's type hints, it's a whole lot better than nothing (IMHO better than typescript), but in it's current form it will always fall short of a language that was designed with strong typing in mind.
- strong typing
- real concurrency (heaven forbid you want a background task without having to spool up an external message queue and worker)
- immutability
- limitations in error handling (sort of just typing really)
- limitations in nullability (also typing)
- memory layout is usually hidden or abstracted away
- no actual private methods or classes
That's far from a complete list, but maybe you're taking for granted the typical pythonic conventions that many practice. It requires a ton of work to design and architect python systems of any non-trivial size for maintainability and understanding. No language is perfect, but there are plenty of languages that make supporting complex systems easier than python.