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 ou
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
> actuall
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
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.
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 inte
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: factory functions with names that
> start with a capital letter so they
On Tue, Sep 2, 2008 at 10:03 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Antoine Pitrou wrote:
>> Nick Coghlan 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
Antoine Pitrou wrote:
> Nick Coghlan 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 cour
Nick Coghlan 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 module,
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. o
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
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 reas
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 p
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)
>>> isinstance(e, type(threading.Event()))
True
(but pretty OT)
Jean-Paul Calderone 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, it's
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.
___
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 hav
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 gmail.com> writes:
Is this just intended to discourage subclassing? If so, why give the
misleading impression that these thing
On Mon, Sep 1, 2008 at 9:36 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Nick Coghlan 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 s
19 matches
Mail list logo
