Mailman 3 Factory functions (was: RE: time.wallclock() or other similar stuff) - Python-ideas

Factory functions (was: RE: time.wallclock() or other similar stuff)

older
Re: [Python-ideas] Possible PEP...

Kristján Valur Jónsson

3 Nov 2010 3 Nov '10

5:26 a.m.

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.

Show replies by date

Antoine Pitrou

3 Nov 3 Nov

8:58 a.m.

On Wed, 3 Nov 2010 13:26:27 +0800 Kristján Valur Jónsson 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. Regards Antoine.

M.-A. Lemburg

9:13 a.m.

Antoine Pitrou wrote:

...

On Wed, 3 Nov 2010 13:26:27 +0800 Kristján Valur Jónsson 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. ElementTree is another example that uses factory functions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 03 2010)

...

...
...
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: 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/

Kristján Valur Jónsson

11:14 a.m.

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:

...

On Wed, 3 Nov 2010 13:26:27 +0800 Kristján Valur Jónsson 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.

M.-A. Lemburg

11:44 a.m.

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 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.

-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 03 2010)

...

...
...
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

Guido van Rossum

3:08 p.m.

On Wed, Nov 3, 2010 at 1:58 AM, Antoine Pitrou wrote:

...

On Wed, 3 Nov 2010 13:26:27 +0800 Kristján Valur Jónsson 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.

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)

Antoine Pitrou

3:19 p.m.

Le mercredi 03 novembre 2010 à 08:08 -0700, Guido van Rossum a écrit :

...

On Wed, Nov 3, 2010 at 1:58 AM, Antoine Pitrou wrote:

...
On Wed, 3 Nov 2010 13:26:27 +0800 Kristján Valur Jónsson 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.

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...

Actually, it has (with both Lock and RLock); but I don't think subclassing would have been an issue anyway. Regards Antoine.

Nick Coghlan

10:04 p.m.

On Thu, Nov 4, 2010 at 1:08 AM, Guido van Rossum 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...

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

4922

Age (days ago)

4922

Last active (days ago)

List overview

Download

7 comments

5 participants

participants (5)

Antoine Pitrou
Guido van Rossum
Kristján Valur Jónsson
M.-A. Lemburg
Nick Coghlan

Factory functions (was: RE: time.wallclock() or other similar stuff)

Kristján Valur Jónsson

Antoine Pitrou

M.-A. Lemburg

Kristján Valur Jónsson

M.-A. Lemburg

Guido van Rossum

Antoine Pitrou

Nick Coghlan

tags

participants (5)