Sorry to pipe in so late, but this is actually the default behaviour of
my C implementation (which I call KIO (Key Insertion Order), there is an
option to change this to KVIO (Key (or) Value Insertion Order), which
moves the pair to the end.
Anthon
Armin Ronacher wrote:
> Steven D'Aprano pearwoo
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
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 should this be handled when it comes to the addition of PEP 8
> compliant aliases
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
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 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
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.
___
libpython2.5.a contains quite a lot of .data that doesn't look like it
needs to be writable (my minimal interpreter binary has 105KB of
writable allocated data). A lot of these symbols look like they could
just be tagged const with no other changes to the interpreter; some of
them would require a p
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
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)
On Mon, Sep 01, 2008, Torne Wuff wrote:
>
> Attached is a patch which adds const to the easy ones:
> * Docstrings for extension functions (PyDoc_VAR in Python.h)
> * ascii->digit lookup table (_PyLong_DigitValue in longobject.c)
> * The copyright notice (cprt in getcopyright.c)
If you want
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:
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
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
It seems that the frustration with super revolves around how Python
currently conflates (as well as many users) two very different types
of inheritance, both "is-a" and "has-a" (or compositional)
inheritance. Unfortunately, Python assists this confusion because the
language doesn't provide a disti
15 matches
Mail list logo