Fredrik Sjöstrand
@fronkan.bsky.social
Software engineering, ML and data in general, but python in particular! very occasional blogging at: http://fronkan.hashnode.dev. Storing code at: http://github.com/Fronkan.
I'm currently trying to internalise this:
Oh, I forgot to mention: lower your standards! Waiting until a piece feels as good as you can get it is a recipe for an empty blog and a huge folder full of drafts
I try to hit publish while I am still unhappy with what I've written
I try to hit publish while I am still unhappy with what I've written
June 2, 2025 at 11:22 PM
I'm currently trying to internalise this:
"follow and pin" might be the bluesky equivalent of YouTubes "subscribe and ring the bell". Likeing it will put it in your liked list, but if really want to see it you should pin it as well.
March 14, 2025 at 8:32 AM
"follow and pin" might be the bluesky equivalent of YouTubes "subscribe and ring the bell". Likeing it will put it in your liked list, but if really want to see it you should pin it as well.
Not doing much serveless stuff, but it sounds interesting. I have been playing around with duckdb for some larger than memory data and it's been pretty great.
Was running queries over piles of parquet files 😁
Was running queries over piles of parquet files 😁
March 14, 2025 at 7:06 AM
Not doing much serveless stuff, but it sounds interesting. I have been playing around with duckdb for some larger than memory data and it's been pretty great.
Was running queries over piles of parquet files 😁
Was running queries over piles of parquet files 😁
I checked out the repo and I would say that pyproject.toml or setup.cfg is the preferred way to configure setuptools now a days. Generally, using static information instead of a build script makes packages safer and more easily introspected. Personaly, I prefer pyproject.toml as it's standardized
March 14, 2025 at 6:54 AM
I checked out the repo and I would say that pyproject.toml or setup.cfg is the preferred way to configure setuptools now a days. Generally, using static information instead of a build script makes packages safer and more easily introspected. Personaly, I prefer pyproject.toml as it's standardized
I would for example use `pyproject.toml` for the package information rather than `setup.cfg` and defently avoid `setup.py`. `setup.py` is powerful but we try to use static information now a days. Pyproject.toml is the latest and most standardised way, making it easier to try other build systems.
March 14, 2025 at 6:47 AM
I would for example use `pyproject.toml` for the package information rather than `setup.cfg` and defently avoid `setup.py`. `setup.py` is powerful but we try to use static information now a days. Pyproject.toml is the latest and most standardised way, making it easier to try other build systems.
Now a day's we have a lot of options for building packages, but, for a long time setuptools was more or less the only option. It's been around for a long time and things has changed quite a bit during that time. So if you use it, just make sure to see what current practice is.
March 14, 2025 at 6:47 AM
Now a day's we have a lot of options for building packages, but, for a long time setuptools was more or less the only option. It's been around for a long time and things has changed quite a bit during that time. So if you use it, just make sure to see what current practice is.