Greg Ewing wrote:
Steven D'Aprano wrote:
Why not expose the class directly, instead of making it private and
then exposing it via a factory function that does nothing else?
This option would also have the advantage of not
changing the API (unless there's code out there that
actually
2008/9/2 Greg Ewing [EMAIL PROTECTED]:
Steven D'Aprano wrote:
Why not expose the class directly, instead of making it private and then
exposing it via a factory function that does nothing else?
This option would also have the advantage of not
changing the API (unless there's code out there
Tony Nelson wrote:
I suppose the question is what a capitalized name promises. If it means
only Class, then how should Returns a new object, either from a Class
or a Factory, be shown? Perhaps a new convention is needed for Factories?
Any function can always return a new object (e.g.
Nick Coghlan ncoghlan at gmail.com writes:
Given the proximity of RC1, Antoine's option 3 (leaving the capitalised
factory functions in both multiprocessing and threading APIs) is
actually sounding pretty appealing to me at the moment.
I was actually suggesting this course for the threading
On Tue, Sep 2, 2008 at 10:03 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Given the proximity of RC1, Antoine's option 3 (leaving the capitalised
factory functions in both multiprocessing and threading APIs) is
actually sounding
On Tue, Sep 2, 2008 at 9:36 AM, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Mon, 1 Sep 2008 11:24:02 pm Nick Coghlan wrote:
I've been taking a close look at the API for multiprocessing and
threading, and have discovered a somewhat strange pattern that occurs
multiple times in both interfaces:
Tony Nelson wrote:
I suppose the question is what a capitalized name promises. If it means
only Class, then how should Returns a new object, either from a Class
or a Factory, be shown?
Is there really a strong need to show that? There are
many ways in which functions could be categorized.
Is
Steven D'Aprano wrote:
Why not expose the class directly, instead of
making it private and then exposing it via a factory function that does
nothing else?
This option would also have the advantage of not
changing the API (unless there's code out there that
actually depends on them *not* being
I've been taking a close look at the API for multiprocessing and
threading, and have discovered a somewhat strange pattern that occurs
multiple times in both interfaces: factory functions with names that
start with a capital letter so they look like they're actually a class.
At first I thought it
On Mon, Sep 1, 2008 at 9:36 AM, Antoine Pitrou [EMAIL PROTECTED] wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Is this just intended to discourage subclassing? If so, why give the
misleading impression that these things can be subclassed by naming them
as if they were classes?
How
On Mon, 1 Sep 2008 09:42:06 -0500, Benjamin Peterson [EMAIL PROTECTED] wrote:
On Mon, Sep 1, 2008 at 9:36 AM, Antoine Pitrou [EMAIL PROTECTED] wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Is this just intended to discourage subclassing? If so, why give the
misleading impression that
On Mon, Sep 1, 2008 at 10:00 AM, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 1 Sep 2008 09:42:06 -0500, Benjamin Peterson
Yes, I believe that pretending that functions are classes is a fairly
common idiom in the stdlib and out, so I see no problem leaving them
alone. We haven't had
Benjamin Peterson wrote:
Does anybody ever complain about not being able to use isinstance on
twisted.application.Application? (At least it's documented as a
function there.)
the threading non-classes are documented to be factory functions on
the module page.
/F
Jean-Paul Calderone exarkun at divmod.com writes:
Here's a complaint. It's surprising that you can't use Event et al with
isinstance. This is something I'm sure a lot of people run into (I did,
many years ago) when they start to use these APIs. Once you do figure
out why it doesn't work,
Antoine Pitrou wrote:
event_class = Event().__class__ ?
Not pretty I know :-)
somewhat prettier, assuming 2.3 or newer:
import threading
e = threading.Event()
type(e)
class 'threading._Event'
isinstance(e, type(threading.Event()))
True
(but pretty OT)
/F
Fredrik Lundh wrote:
Benjamin Peterson wrote:
Does anybody ever complain about not being able to use isinstance on
twisted.application.Application? (At least it's documented as a
function there.)
the threading non-classes are documented to be factory functions on
the module page.
Given
Antoine Pitrou wrote:
I don't see a problem for trivial functional wrappers to classes to be
capitalized like classes.
The problem is that the capitalization makes you
think it's a class, suggesting you can do things
with it that you actually can't, e.g. subclassing.
I can't think of any
At 1:04 PM +1200 9/2/08, Greg Ewing wrote:
Antoine Pitrou wrote:
I don't see a problem for trivial functional wrappers to classes to be
capitalized like classes.
The problem is that the capitalization makes you
think it's a class, suggesting you can do things
with it that you actually can't,
18 matches
Mail list logo
