I've read a few articles here and there but this was the motivation I needed to properly subscribe.
3,857 karma · joined December 16, 2012
Former Django core developer.
josh.smeaton@kraken.tech
I've read a few articles here and there but this was the motivation I needed to properly subscribe.
To be honest, I think a lot of Python [or arbitrary dynamic language] developers can be quite sloppy, throwing dictionaries around everywhere because it's easy and leading to some really hard to read code. Type hints guide people away from that sloppiness while still allowing access to most of the features that make dynamic languages so useful and expressive.
It's a best-of-both-worlds situation and I'm here for it.
git diff -U0 --relative origin/master... | flake8 --diff --select <custom-codes>
I'll leave the flake8 plugin as an exercise to the reader as ours is intertwined with code I can't share right now.
The editor experience only increases that factor as you can navigate a lot more freely. Even for small code bases type hints are a revelation. Knowing if something is nullable or not, alone, has caught 100's of bugs in waiting.
Most of the complaints here feel like attacking a strawman, particularly the ones arguing what's the point if you're not running mypy. Run mypy! It's like saying what's the point of writing unit tests if you don't run the test suite. For any sufficiently large code base you absolutely should be running mypy with any plugins for your framework of choice added.
For heterogeneous dictionaries use `dict[str, object]` and then you're forced to use the existing duck-typing mechanisms you're used to. Or, you refactor into better types and/or structures.
Is there friction? Sometimes. You don't have to annotate everything. If the cost is too prohibitive for a particular structure or function, ignore it. Sometimes there are mypy bugs that make writing correct code impossible. # type: ignore[reason] that sucker. Don't throw the baby out with the bath water.
We use a flake8 linter to enforce that all new or modified functions at least annotate their return type which makes interacting with functions quite a bit nicer, and encourages all devs to at least do the minimum. Usually you find that most args are appropriately typed at the same time.
Of course, knowing about specific algorithms is handy, and adjusting the question to find an appropriate spec to implement for a given problem could be a nice touch.
I think that either approach above is strictly better than implementing algorithms from memory and would produce a far better signal.
I believe the content that is indexed is the content you can see. Sites used to be penalised, heavily, for returning different content to google. Hiding the paywall for google falls into that bucket.
At a minimum the search results should display if they’re paywalled and provide tools to exclude that content from results.
The motivation is correct. You run a search on google and get mostly paywalled content. I'm fine with news sites requiring subscriptions to view their articles but they shouldn't also get the benefit of being listed at the top of search results for key terms.
Alternatively, the search list should show if content is paywalled or give you search options to remove paywalled content.
How about simply stating that any firm paying dividends to shareholders or bonuses to execs could not have the loan forgiven? It wouldn't be perfect but it'd cut out the most egregious snakes. Hindsight yadda yadda.
The same thing happened in Australia. Cash to businesses who could show an impact by Covid, but a lot of that money went towards bonuses and dividends. Crazy.
I also always hated single quote docstrings even in single quote code bases.
If you're going to write a program to optimise your guesses then why not just go to the source and pull the answer straight from the encoded answer list? I know people derive fun from these things in different ways but that's kind of where I landed.
Are there any other blogs similar to this one in content that people are enjoying?
https://github.com/jarshwah/advent-of-code/blob/main/sql/202...
Though now I know you can ignore the window and just compare against the 3rd offset, the first solution just needs a `LEAD(depth, 3)` to complete the second question.
Still - I learned about `RANGE BETWEEN` so I'm calling it a win.
And it sounds like the maintainers, rightfully, are wary about continuing with the DNF particularly because they haven't been consulted in years.
Wow. They filed a ticket and then secretly used an admin bot user to accept the change? That sounds incredibly dishonest - not just an oops situation there.
> what proceeds should be stripped if you get cash in exchange for drugs and use that cash to buy GME calls which skyrocket?
> but the actual proceeds at the time of the crime have a specific value
The specific value at the time is, in nearly every other situation, irrelevant. The mistake was putting a claim to a monetary value of *asset* rather than the *asset* itself.
The house is then auctioned off. It's not valued at the time of arrest and any additional value returned to the person arrested.
I don't understand why it could, or should, be any different for electronic stores of value (stock, options, crypto).
I had déjà vu reading the section on bind parameters in aggregate queries. The oracle backend had a similar issue that was fixed/hacked by comparing values and grouping them into named parameters. https://code.djangoproject.com/ticket/27632