This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zaneb
Recipients vinay.sajip, zaneb
Date 2019-09-20.21:17:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1569014222.97.0.779130855354.issue37857@roundup.psfhosted.org>
In-reply-to
Content
In turns out that setting the level directly is used in the standard library, so we definitely have a bug here that needs fixing in 3.7 & 3.8.

Obviously the fix could be just to stop doing that in the standard library, but I'd argue that this is even stronger evidence that it can happen to anyone, and that we should fix it for Python users in general.

> But it's not a priority to support situations where people don't follow published APIs and still expect things to work the way they would like.

That's fair, of course. This isn't and shouldn't be anyone's number 1 priority, but that doesn't mean we can't do it.

> I would prefer people to use setLevel(), as it helps to have consistent usage.

Me too. I added a new patch to the PR that deprecates the setter so that anyone doing it wrong will get a warning. (In fact that's how I discovered it was being set directly in the standard library.)

> The philosophy is that of not breaking userspace code *which follows published APIs*. If you use unpublished APIs or rely on implementation details, you're generally on your own.

I was referring to stuff like https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42163 (I won't link to a famous equivalent in Linux because it involves Linus swearing at people), where the users are clearly wrong but they have a policy of not breaking them anyway.
History
Date User Action Args
2019-09-20 21:17:03zanebsetrecipients: + zaneb, vinay.sajip
2019-09-20 21:17:02zanebsetmessageid: <1569014222.97.0.779130855354.issue37857@roundup.psfhosted.org>
2019-09-20 21:17:02zaneblinkissue37857 messages
2019-09-20 21:17:02zanebcreate