Factory functions (was: RE: time.wallclock() or other similar stuff)
Completely off topic. What's with factory functions? Why not a class? And why are there factory functions in threading.py and not classes? K -----Original Message----- From: python-ideas-bounces+kristjan=ccpgames.com@python.org [mailto:python-ideas-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Greg Ewing Sent: Wednesday, November 03, 2010 6:19 To: python-ideas@python.org Subject: Re: [Python-ideas] time.wallclock() or other similar stuff However, it suggests a factory function that returns some kind of object that performs timing, rather than simply returning a time.
Antoine Pitrou wrote:
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. ElementTree is another example that uses factory functions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 03 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
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? 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. 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:
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.
Kristján Valur Jónsson wrote:
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.
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 03 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Nov 3, 2010 at 1:58 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Indeed; the intention was that it should be possible to replace the various lock classes with built-in objects without having to worry about continuing subclasses. While this was done before built-in objects could be subclassed, even today I still like to prevent subclassing the lock classes since the ability to subclass still constrains the implementation of the built-in type somewhat. I think it's more important to have the possibility to switch in a faster platform-specific lock implementation. I do admit that so far this hasn't happened... -- --Guido van Rossum (python.org/~guido)
On Thu, Nov 4, 2010 at 1:08 AM, Guido van Rossum <guido@python.org> wrote:
I think the adventures with dict() over the years show pretty clearly the kind of care the superclass has to take to properly allow subclassing (i.e. frequently checking the actual class before taking shortcuts that bypass potential overrides in subclasses). It's not impossible, obviously, but it does require extra care and attention in the superclass. Using a factory function instead is a very clear way to say "no, I'm not making any promises about your ability to inherit useful functionality from this implementation". Historically, you could have your cake and eat it too by providing a Mixin class to help implementation of alternative approaches, as well as the original factory function. These days, ABCs are probably a better choice for the niche previously occupied by the Mixin classes. The cases that mildly irritate me are the factory functions that are *named* with CamelCase as if they were classes, just because they're surprising when I find out the name gives the wrong impression of the metaclass involved (i.e. a function rather than a type). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Antoine Pitrou wrote:
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. ElementTree is another example that uses factory functions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 03 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
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? 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. 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:
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.
Kristján Valur Jónsson wrote:
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.
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 03 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Nov 3, 2010 at 1:58 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Indeed; the intention was that it should be possible to replace the various lock classes with built-in objects without having to worry about continuing subclasses. While this was done before built-in objects could be subclassed, even today I still like to prevent subclassing the lock classes since the ability to subclass still constrains the implementation of the built-in type somewhat. I think it's more important to have the possibility to switch in a faster platform-specific lock implementation. I do admit that so far this hasn't happened... -- --Guido van Rossum (python.org/~guido)
On Thu, Nov 4, 2010 at 1:08 AM, Guido van Rossum <guido@python.org> wrote:
I think the adventures with dict() over the years show pretty clearly the kind of care the superclass has to take to properly allow subclassing (i.e. frequently checking the actual class before taking shortcuts that bypass potential overrides in subclasses). It's not impossible, obviously, but it does require extra care and attention in the superclass. Using a factory function instead is a very clear way to say "no, I'm not making any promises about your ability to inherit useful functionality from this implementation". Historically, you could have your cake and eat it too by providing a Mixin class to help implementation of alternative approaches, as well as the original factory function. These days, ABCs are probably a better choice for the niche previously occupied by the Mixin classes. The cases that mildly irritate me are the factory functions that are *named* with CamelCase as if they were classes, just because they're surprising when I find out the name gives the wrong impression of the metaclass involved (i.e. a function rather than a type). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Antoine Pitrou -
Guido van Rossum -
Kristján Valur Jónsson -
M.-A. Lemburg -
Nick Coghlan