Anthon van der Neut | 1 Sep 14:24 2008

Re: Proposal: add odict to collections

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 <steve <at> pearwood.info> writes:
> 
>> Conceptually, I would expect the following behaviour:
>>
>>>>> od = odict()
>>>>> od[1] = 'spam'  # insert a new key
>>>>> od[2] = 'parrot'  # insert a new key
>>>>> od[1] = 'ham'  # modify existing key
>>>>> od.items()
>> [(1, 'ham'), (2, 'parrot')]
> That behavior is different to any ordered-dict implementation
> out there ;-)
> 
> Regards,
> Armin
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev <at> python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/anthon%40mnt.org
> 
(Continue reading)

Nick Coghlan | 1 Sep 15:24 2008
Picon

Further PEP 8 compliance issues in threading and multiprocessing

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 was a quirk of the multiprocessing implementation,
but then I discovered that the threading module also does it for all of
the synchronisation objects as well as threading.Timer, with examples like:

  def Event(*args, **kwds):
    return _Event(*args, **kwds)

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? Add aliases for the factory functions that start with
a lower case letter, but otherwise leave the structure of the modules
unchanged? Or should the trivial functions like the one above be dropped
and made direct aliases for the classes they are currently wrapping?

Option 1 has the virtue of being perfectly backwards compatible in the
threading case, while option 2 is a little riskier, so I'm inclined to
go with option 1 (keeping the factory functions, but giving them
non-class like names in the case of multiprocessing, or aliases in the
case of threading).

Cheers,
Nick.
(Continue reading)

Antoine Pitrou | 1 Sep 16:36 2008
Picon

Re: Further PEP 8 compliance issues in threading and multiprocessing

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 should this be handled when it comes to the addition of PEP 8
> compliant aliases?

I don't see a problem for trivial functional wrappers to classes to be
capitalized like classes. So I'd suggest option 3: leave it as-is. Otherwise
option 2 (replace the wrappers with the actual classes) has my preference.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Benjamin Peterson | 1 Sep 16:42 2008
Picon

Re: Further PEP 8 compliance issues in threading and multiprocessing

On Mon, Sep 1, 2008 at 9:36 AM, Antoine Pitrou <solipsis <at> pitrou.net> 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 should this be handled when it comes to the addition of PEP 8
>> compliant aliases?
>
> I don't see a problem for trivial functional wrappers to classes to be
> capitalized like classes. So I'd suggest option 3: leave it as-is. Otherwise
> option 2 (replace the wrappers with the actual classes) has my preference.

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 any complaints about the threading Event
function yet either. :)

--

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

(Continue reading)

Jean-Paul Calderone | 1 Sep 17:00 2008

Re: Further PEP 8 compliance issues in threading and multiprocessing

On Mon, 1 Sep 2008 09:42:06 -0500, Benjamin Peterson <musiccomposition <at> gmail.com> wrote:
>On Mon, Sep 1, 2008 at 9:36 AM, Antoine Pitrou <solipsis <at> pitrou.net> 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 should this be handled when it comes to the addition of PEP 8
>>> compliant aliases?
>>
>> I don't see a problem for trivial functional wrappers to classes to be
>> capitalized like classes. So I'd suggest option 3: leave it as-is. Otherwise
>> option 2 (replace the wrappers with the actual classes) has my preference.
>
>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 any complaints about the threading Event
>function yet either. :)

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 not clear how to do what you want, since
_Event is private.

Jean-Paul
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
(Continue reading)

Benjamin Peterson | 1 Sep 17:50 2008
Picon

Re: Further PEP 8 compliance issues in threading and multiprocessing

On Mon, Sep 1, 2008 at 10:00 AM, Jean-Paul Calderone <exarkun <at> divmod.com> 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 any complaints about the threading Event
>> function yet either. :)
>
> 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 not clear how to do what you want, since
> _Event is private.

Does anybody ever complain about not being able to use isinstance on
twisted.application.Application? (At least it's documented as a
function there.)

>
> Jean-Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev <at> python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>

--

-- 
Cheers,
(Continue reading)

Fredrik Lundh | 1 Sep 17:54 2008

Re: Further PEP 8 compliance issues in threading and multiprocessing

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>

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Torne Wuff | 1 Sep 17:38 2008
Picon

constness of interpreter data

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 proliferation of constness. I'm a bit new at this,
though, and it's possible that I'm wrong about some/most/all of these,
so I'm wondering what people think.

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)

There are no errors or new warnings introduced in my build by this
patch, but I'm only compiling the interpreter itself. If anyone can
suggest a reason why any of those shouldn't be const, please do :)

Things that take up space that might be const-able with more effort, or
might not, I can't tell:
  * Token names (_PyParser_TokenNames in tokenizer.c)
  * Module function tables (and ensuing propagation of constness into
    PyModule_Init etc)
  * All the type and exception objects

Things that take up space but probably aren't const-able unless someone
who knows more than me has an idea:
  * Standard slot definitions (slotdefs in typeobject.c, but the
    interned string pointers get added at runtime)
  * The generated tables for the grammar (but the accelerator seems to
    want to change these at init time)
(Continue reading)

Antoine Pitrou | 1 Sep 17:39 2008
Picon

Re: Further PEP 8 compliance issues in threading and multiprocessing

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, it's not clear how to do what you want, since
> _Event is private.

event_class = Event().__class__ ?

Not pretty I know :-)

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Fredrik Lundh | 1 Sep 18:28 2008

Re: Further PEP 8 compliance issues in threading and multiprocessing

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>

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org


Gmane