People who are interested in this may also be interested in Cooklang, a simple plain-text markdown format for recipes: https://cooklang.org/ -- doesn't get much easier than that.
Thanks for sharing, I never heard of Cooklang. It feels like a DSL (Domain Specific Language). I'll study their implementation to get started on a niche ETL markup language.
It assume it depends on how things are structured. If you are effectively running everything from Russia and are just using a EU corporate entity on the "frontend" with no actual business operations within the EU, that type of setup would likely be illegal in most countries.
But if you have two separate entities with clear split responsibilities things should work just fine. For example the EU-based company takes care of running the the product and contracts development services from a Russian company.
It's fairly common to have multiple businesses to reduce the blast radius. Often staff are employed by one company which has zero assets in case an employee tries to sue.
They have like 100 people in Prague, another 100 in Munich and then 1000 in Russia. Safe to say they are a Russian company with an EU "presence" for tax purposes.
It's amazing how much people will close an eye if they like the product!
Another fun github hack: if you browse the repo for a particular file, the URL will be something like
github.com/user/repo/blob/master/foo/bar/baz.py
But this file can change, meaning this url might not have the same content a week or month down the road. This is particularly troublesome when you have lines selected. To fix this, press `y` and your url will get expanded to include the current commit hash:
I did a blind survey of YAPF vs Black at my work. The results came back as 70% in favour of Black.
Black gives generally nicer output, and also more predictable output because its folding algorithm is simpler. YAPF uses a global optimisation which makes it make very strange decisions sometimes. Black does too, but much less often.
There are also non-style problems with YAPF. It occasionally fails to produce stable output, i.e. yapf(yapf(x)) != yapf(x). In some cases it never stabilises - flip flopping between alternatives forever!
Finally it seems to have very bad worst case performance. On some long files it takes so long that we have to exclude them from formatting. Black has no issue.
In conclusion, don't use YAPF! Black is better in almost every way!
Yeah exactly. I had 20 samples from our codebase that showed some representative differences and you had to click on which one you liked more. The order (Black/YAPF or YAPF/Black) was randomised.
I also had to turn off Black's quote normalisation otherwise it is really obvious which is which. Quote normalisation is another point in Black's favour.
I could put the survey up somewhere if anyone is interested.
YAPF is slower than Black for many degenerate cases, a fact I notice most strongly since I use an "auto-format file on file save" extension in my editor. The case I found in particular was editing large JSON schema definitions in Python, as they're represented as deeply nested dictionaries. Black seems to format them in linear time based on the number of bytes in the file, while YAPF seems to get exponentially slower based on the complexity of the hard-coded data structure. It was a niche case, and the maximum slowdown was only ~1-2 seconds, but that editing freeze was quite annoying.
What's wrong with configurable? Too much opportunity to bikeshed?
I figured yapf was not "new" which is why black won.
Starting about 5-6 years ago there was a push in the Python community to replace solved problems with new ones in what appears to me as chasing the JavaScript community.
Instead of consolidating on existing tools that worked well but had some rough edges to smooth out, numerous projects came about to reinvent the wheel.
There is no "best format". It's a matter of opinion.
Taste is something we cannot objectively agree, and in fact, people will end up arguing even about this very statement, offering what they think is an objective measure.
Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration. To be redone for each project, team, etc. Worse even in FOSS where everybody will come in a ticket and complain. And after while, you do it again, because the debate is never settle even in the same team or project.
There is not way to take a team of 3 people, choose a style, and make it so that they are all 100% happy with it.
Black took the road of gofmt: you can't chose. And it won because of that: it saved people time and energy.
People realize the cost was not worth the satisfaction, which you are unlikely to get anyway. Let's just move on to what matters, it's good enough. Pareto.
> Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration
Sounds like a team problem, I've been on plenty of teams that use clang-format for c/c++ and there have never been any issues like this. Team players know that (almost all) arguing over formatting is not a good use of time. (edit: in case not clear, clang-format is extremely configurable. Set a default config and live with it forever, that's how those teams work.)
> Black took the road of gofmt: you can't chose. And it won because of that: it saved people time and energy.
I don't see how this follows, if a team was dysfunctional enough to be wasting hours and hours of time before, I can't imagine why that wouldn't continue. It just shifts from "let's change this flag in yapf" to "let's switch to yapf because black looks ugly and gives us no options".
Well if it helps your team out then that's great, I just wouldn't expect that to generalize well. But who knows, people are weird, maybe more would give up fighting about style because of a tool change than I expect.
Yes, and also too hard to set up. It's extremely dumb, but I'm much more likely to use something I can't configure, because if I can configure it, I'm going to want to, and it'll take forever to make all those choices.
I agree. With the current state of Django admin, it is better not to build complex stuff on top of it. A few tweaks and customization here and there are fine, but anything more will likely break on Django and/or third-party package updates.
I'd like to see Django gradually redesigning parts of the Admin to allow for more modular extensibility in future versions.
Whats the deal with they large number of open issues an pull requests on FastAPI and SQLModel?
SQLModel 100 issues, 54 open PRs
FastAPI 903 issues, 448(!!) open PRs
I recently had to choose between Flask and FastAPI for a fresh project and went with Flask in the end, partly due to long term maintenance concerns with FastAPI.
Having given SqlModel a very proper go a few months back, I have to say that it's not worth using it just yet. There are too many outstanding issues and the documentation is also incomplete. Maybe in a year's time, the situation could be different.
