[xahrepap]

> That would probably not trigger anyone’s midnight pager, but it would make it clear that relying on the deprecated functionality is a bug lurking in the code.

How do you know? This is a wild assertion. This idea is terrible. I thought it was common knowledge that difficult to reproduce, seemingly random bugs are much more difficult to find and fix than compiler errors.

If you're ready to break your api, break your api. Don't play games with me. If more people actually removed deprecated APIs in a timely manner, then people will start taking it more seriously.

[Certhas]

Last paragraph of the article:

> In case the sarcasm isn’t clear, it’s better to leave the warts. But it is also worthwhile to recognise that in terms of effectiveness for driving system change, signage and warnings are on the bottom of the tier list. We should not be surprised when they don’t work.

[xahrepap]

Yeah, totally a woosh moment for me. Read all the way up to the `* * *`. That's on me :)

[layer8]

Most HN visitors won’t read to the last paragraph, so it’s a good thing to emphasize.

[pavel_lishin]

Yeah, I agree - this sort of intermittent failure could be incredibly hard to track down, and will absolutely fuck with people's faith in their CI systems as well - a flappy test is the absolute worst kind of test.

[matthewkayin]

I agree, maintainers should just break the API if they're going to do it.

At the same time, it's crazy that urllib (the library mentioned in the article), broke their API on a minor version. Python packaging documentation[1] provides the sensible guideline that API breaks should be on major versions.

[1] https://packaging.python.org/en/latest/discussions/versionin...