Kristján Valur Jónsson wrote:
What is a class but a factory function? As you explain it, providing a factory function is merely a fancy way of saying: "Look, don't subclass this class, since we might change it." Wouldn't it be better to be explicit about it?
Isn't using a factory function instead of a class explicit enough ?
But even builtin classes are subclassable now, and people rely in internal features of all LIB classes at their peril, so I can't see that this matters.
I lost you there.
The key difference is that issubclass() or isinstance() checks are not possible with factory functions. On that's done on purpose, since either the implementation cannot guarantee that the used classes are singletons or it decides on the used implementation depending on what it finds installed on the system.
Cheers, Kristjan
-----Original Message----- From: python-ideas-bounces+kristjan=ccpgames.com@python.org [mailto:python-ideas-bounces+kristjan=ccpgames.com@python.org] On Behalf Of M.-A. Lemburg Sent: Wednesday, November 03, 2010 17:14 To: python-ideas@python.org Subject: Re: [Python-ideas] Factory functions (was: RE: time.wallclock() or other similar stuff)
Antoine Pitrou wrote:
On Wed, 3 Nov 2010 13:26:27 +0800 Kristján Valur Jónsson kristjan@ccpgames.com wrote:
And why are there factory functions in threading.py and not classes?
I'm not sure, but it looks like a poor man's way of discouraging subclassing.
You usually use factory functions if you only define an API that can then be implemented in many ways.
With a class hierarchy you are always bound to one implementation and moving from Python to C or providing different specifically optimized implementations can become cumbersome.