I agree with everything Eric Traut has said so far in this thread.In particular, "it doesn't feel right" isn't a strong enough justification for a deprecation period that could force people to change existing, working code just to avoid deprecation warnings at runtime. Since this is now established behaviour in Python 3.11 (and it's much too late to change it in Python 3.12), you don't just need to explain why you disagree with the previous change — you need to justify this change in behaviour independently, as a change in its own right. See PEP 387 for the full details on CPython's backwards-compatibility policy at runtime.I also still don't understand why "I have quibbles with the fact that static type checkers allow `Any` to be subclassed" has really any bearing on whether we allow it to be subclassed at runtime. We made the runtime change because all major static type checkers allow `Any` to be subclassed at "typing time", and it's best to avoid inconsistencies between runtime and typing time where possible. But that doesn't force any type checker to permit `Any` to be subclassed at typing time. Most major type checkers still provide an option which, when enabled, means they will emit an error when `Any` is subclassed. It's best for the runtime behaviour to be no more restrictive than static type checkers, but the reverse doesn't hold — there are many situations in which things are allowed at runtime but banned by type checkers, and that's perfectly fine.Lastly — yes, strictly speaking, behaviour specified in a PEP should usually not be changed unless a new PEP has been written and accepted, and the new PEP specifies that the behaviour should be changed. If you like, I _suppose_ you could bring this to the attention of the Python Steering Council, who have the power to demand that the change be reverted if they feel like the proper process wasn't followed. However, this honestly seems like a pretty minor detail of PEP 484, and the proposed change was advertised on this mailing list before being made, in order to check whether anybody disagreed with the change. (Nobody did.) I think it's unlikely that the Steering Council would be sympathetic to your case, especially since it's been a while since the change was made.Best,Alex -------- Original message --------From: Paul Bryan <pbryan@anode.ca> Date: 13/08/2023 18:57 (GMT+00:00) To: typing-sig@python.org Subject: [Typing-sig] Re: typing.Any subclasses I had posed the questions:1. What does subclassing `Any` even mean, given everything type matches `Any`?2. Is there a valid use case for a subclass of `Any`?If neither of these can be reasonably answered, I certainly wouldn't feel bad about breaking backward compatibility with a nonsensical construct.On Sun, Aug 13, 2023, at 10:36, Eric Traut wrote:I don't think there is consensus. I don't think there has been a compelling argument made here. Just because something "doesn't feel right" to a few people doesn't mean that it should be changed. Deprecating functionality and breaking backward compatibility requires a solid justification, and I don't think anyone has presented one yet.As I pointed out above, type checkers already need to deal with the case where a base class is unknown (and therefore has an `Any` type). Disallowing `Any` as an explicit base class won't change that.If you feel that there's a need to standardize the behavior of type checkers when the type of a base class is unknown, then let's talk about what form that specification might take (e.g. PEP or official Python documentation). I personally don't think there's a strong need here because I don't recall any issue arising from this in the pyright or mypy issue trackers. If you are aware of any real problems caused by inconsistencies between type checkers in this regard, please let us know._______________________________________________Typing-sig mailing list -- typing-sig@python.orgTo unsubscribe send an email to typing-sig-leave@python.orghttps://mail.python.org/mailman3/lists/typing-sig.python.org/Member address: pbryan@anode.ca