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 ncoghlan
Recipients YoSTEALTH, eric.snow, gregory.p.smith, josh.r, lisroach, ncoghlan, ned.deily, pablogsal, pitrou, rhettinger, serhiy.storchaka, yselivanov
Date 2018-02-01.03:55:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1517457353.0.0.467229070634.issue31356@psf.upfronthosting.co.za>
In-reply-to
Content
A useful heuristic is that if something is named with CapWords, then class-like *usage* is explicitly supported (inheritance, isinstance checks, etc).

If it's named with snake_case or wordsruntogether, then calling it is OK, but you may run into quirky behaviour in class-style usage (e.g. it may not be a class at all in some implementations, or it may not be friendly to subclassing even when it is a full class).

So for something like this, snake_case is appropriate - you're meant to just use it, not subclass it. The fact that it's a type instance is an implementation detail.

(In other cases like contextlib.contextmanager we've made that implementation details status completely explicit in the code by having the public API be a wrapper function that returns an instance of a private class)
History
Date User Action Args
2018-02-01 03:55:53ncoghlansetrecipients: + ncoghlan, rhettinger, gregory.p.smith, pitrou, ned.deily, eric.snow, serhiy.storchaka, yselivanov, josh.r, YoSTEALTH, lisroach, pablogsal
2018-02-01 03:55:53ncoghlansetmessageid: <1517457353.0.0.467229070634.issue31356@psf.upfronthosting.co.za>
2018-02-01 03:55:52ncoghlanlinkissue31356 messages
2018-02-01 03:55:52ncoghlancreate