At a minimum I consider it like an automatic "garbage collection" mechanism that prevents dead and abandoned things to remain "valid forever".

It also helps with things such as change of ownership so after a certain period of time you can have the peace of mind that certs potentially issued by the previous owners are not lingering around as active (I understand things such as revoking and pinning can help with this too but It's nice to have a plain time based expiry too).

No. People get to choose their words. Go be upset!

I'm deeply deeply against offering self-hosted SaaS. In summary because it takes you from a world where 1 instance of your application exists under your full control to a world where 1000 instances of your application exists all over the place outside of your control.

At that point you turn into a "classic" software vendor where you have to help people "operate" your software. After you have long moved on from something someone will still be on the version from 3 years ago and talking to you about "upgrade/migration path".

I firmly prefer a world where there is only "one operator" for the product and I fully manage 1 instance of the product as a total black box and the end users use it as a ... hello? ... "as a service".

My advice is unless someone cares enough to write you a life-changing check ... stay away from it.

Weird question, but would this work inside docker as "extra protection"?

well yeah maybe, if you like.

For those who may not know: "Retrieval-augmented generation"

Looking forward to a "havemyuuidsbeenpwned.com" service :))

> We’re launching with $1.25 million to be invested across 125 projects, backed through the kind support of Alfred P. Sloan Foundation, American Express, Chainguard, HeroDevs, Kraken, Mayfield Fund, Microsoft, 1Password, Shopify, Stripe, Superbloom, Vercel, Zerodha, and others.

Nice initiative, but don't go bankrupt guys!

It's quite logical to think that they have an incentive to get you as much money as possible but in reality it's often not quite correct. Their stronger incentive is to establish a relationship with a business and to continue feeding them candidates at an attractive price point for the business. The marginal amount of extra commission that they make on your increased salary is not that significant.

I think it depends on how motivated the attackers are.

If we are talking about the account creation form of Facebook, you bet you will need some CAPTCHA. If it's a random form with no obvious benefit of spamming then I'm not sure how many "attempts" will be done to begin with regardless of the protection mechanisms.

In those cases you may be enocuntering bots that "blast spam" and usually the slightest form of barrier stops them because they tend to be made for the common denominator, for example by targeting popular blog/forum software that have a predictable form structure that the bot can be programmed for.

I have seen some basic anti-spam features that are "home-made captcha".

For example it says something like "Pandas are black and:" and you have to enter "white".

Those can sometimes be made in a way that is more user-friendly compared to a "real captcha".

However it takes some careful consideration and knowing your audience to make sure that they understand what to do. Some users may not understand it due to language or cultural differences or due to people being used to the traditional captcha.

You may want to remove the protection mechanism to see if you get any spam at all or not (or at least log and measure success vs failure cases).

Without knowing anything about your use case, personally I'd remove the CAPTCHA and see how many spams come through. Then I'd put a very basic and gentle barrier just enough to remove those spams and gradually increase the barrier if required.

Another thing to consider is that if your users have to login you can have some kind of basic reputation metric so that "known good" users are not subject to the same restrictions.

> However it takes some careful consideration and knowing your audience to make sure that they understand what to do.

I fail reCAPTCHA at least 50% of the time so it would be hard to be worse.

(Not the author)

In large codebases you can have a problem where people randomly import things from different locations leading to a host of issues including circular import issues.

For example someone finds a convenient helper function in "my_thing.foo.bar.helpers" and imports it but you don't want that dependency between those modules and the helper function was not intended to be used outside of that module.

In Python this problem is especially severe because there is no native module encapsulation mechanism other than a weak conventio of using the underscore prefix.

A tool like this helps you enforce "intentional" module boundaries so modules can't randomly reach into each other to import things. You will be forced to consider an intentional modular design where the helpers that are needed by many things are separated out and other things are allowed to import from it.

Underscore prefix is slightly more than convention: even without an explicit `__all__`, a wildcard import excludes 'underscore-private'.

IMO it's unfortunate, especially because of that behaviour, that they're importable (explicitly) at all.

Yes but it's not enough.

Especially in a large codebase where lots of different modules are technically in the same package as each other.

It's easier when a library author is publishing a small package for external consumption by other parties.

Another issue is that in Python any name in a module is implicitly available to be imported from other places.

For example let's say you have "A.py" inside of "A.py" you have "from something import foo". Now "B.py" can do something like "from A import foo".

So now "B" has a dependency that nobody really wanted to create.

Later "foo" may not be needed in "A.py" anymore and it will look like a totally unused import to anyone. Except it is being used by "B.py" too behind your back.

Someone deletes the "unused import" and something else somewhere else breaks because it can no longer import "foo" from "A".

(I have seen variations of this issue happen many many times so don't think I'm making some theoretical scenario.)

It's a very contrived scenario, and practically never happens if you use a python IDE. I've worked on multi-million line python codebases and this kind of stuff only happened when the (junior) dev insisted on using something like VSCode and not bothering to do a casual check of where they're importing something from. Also happened when you got "senior" devs with the idea of "python is just a silly little scripting language, I can pick it up in a weekend", but even then they were stubborn and didn't use a Python IDE, instead resorting to using a barebone and barely-configured installation of VSCode.

I'm not sure what use-case this serves, as all my library "don't be naughty" needs are handled by my IDE.

I agree, I just meant given it's not mere community convention, it does have some meaning in the language, it's a shame it doesn't have more.

Yes, good call out - I actually wrote a bit more about this and how we arrived at our solution with `tach`.

[0] https://www.gauge.sh/blog/the-trouble-with-all

and a lot of people stopped using them _HelperClass just doesn't look nice ....