Re: [Python-Dev] Things to Know About Super

[average]

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 distinct enough way to differentiate
between them.

For the former (i.e. is-a inheritance), users should not have to
explicitly make a call to the super class (via super() or
otherwise)--this should be automatic for every method held in common
so as to guarantee the invariants of the simpler class.  For this type
of inheritance it makes more sense to be explicit about *bypassing* a
call to the parent class--IF necessary (perhaps to take advantage of
an optimization available only in the subclass)--rather than explicit
about *making* one.  This would remove many of the bugs, misuses, and
frustrations with super().  No more ambiguity and confusion because
the language now guarantees certain behavior.  Super() would then be
limited to cooperative mixin classes; for all others, explicit naming
of the class would be required.  But perhaps that there is some
language abstraction that has yet to be fully invented that would tie
it all together nicely.

By the way, regarding your trait implementation, it may be worthwhile
revisiting the discussion surrounding the Prothon language discussed a
few years ago on comp.lang.python which got rid of classes and
metaclasses and replaced them with prototypes.

Regards,

zipher
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Tony Nelson]

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, e.g. subclassing.

Or that it returns a new object of that kind.


>I can't think of any reason to do this. If you
>don't want to promise that something is a class,
>what possible reason is there for naming it like
>one?
 ...

Lower-case names return something about an object.  Capitalized names
return a new object of the named type (more or less), either via a Class
constructor or a Factory object.  That's /a/ reason, anyway.

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

TonyN.:'   
  '  
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Greg Ewing]

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 reason to do this. If you
don't want to promise that something is a class,
what possible reason is there for naming it like
one?

I can see a reason for doing the opposite, though:
if something happens to be a class, but you don't
want to promise that, you could expose it under
a lower-case name, that can be replaced with a
factory function later.

In this case, the thing to decide is whether
Event will always be a direct class instantiation.
If so, rename _Event to Event and expose it
directly. If not, rename Event to event.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Nick Coghlan]

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

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] constness of interpreter data

[Aahz]

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 this patch considered, please post it to bugs.python.org --
patches posted to the mailing list can't be tracked.  Thanks!
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Fredrik Lundh]

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)



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Antoine Pitrou]

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 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] constness of interpreter data

[Torne Wuff]

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)

There's probably other things, but I didn't go through the entire symbol
table, just started with the big ones :)

So, er, is this a remotely sane thing to be doing, and does anyone have
suggestions? :)

-- 
Torne Wuff
[EMAIL PROTECTED]
Index: quilted/Include/Python.h
===
--- quilted.orig/Include/Python.h	2008-09-01 16:00:58.0 +0100
+++ quilted/Include/Python.h	2008-09-01 16:01:57.0 +0100
@@ -162,7 +162,7 @@
 #endif
 
 /* Define macros for inline documentation. */
-#define PyDoc_VAR(name) static char name[]
+#define PyDoc_VAR(name) static const char name[]
 #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str)
 #ifdef WITH_DOC_STRINGS
 #define PyDoc_STR(str) str
Index: quilted/Objects/longobject.c
===
--- quilted.orig/Objects/longobject.c	2008-09-01 16:00:58.0 +0100
+++ quilted/Objects/longobject.c	2008-09-01 16:01:57.0 +0100
@@ -1340,7 +1340,7 @@
  * Note that when converting a base B string, a char c is a legitimate
  * base B digit iff _PyLong_DigitValue[Py_CHARMASK(c)] < B.
  */
-int _PyLong_DigitValue[256] = {
+const int _PyLong_DigitValue[256] = {
 	37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37,
 	37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37,
 	37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37, 37,
Index: quilted/Python/getcopyright.c
===
--- quilted.orig/Python/getcopyright.c	2008-09-01 16:00:58.0 +0100
+++ quilted/Python/getcopyright.c	2008-09-01 16:01:57.0 +0100
@@ -2,7 +2,7 @@
 
 #include "Python.h"
 
-static char cprt[] = 
+static const char cprt[] = 
 "\
 Copyright (c) 2001-2008 Python Software Foundation.\n\
 All Rights Reserved.\n\
Index: quilted/Include/longobject.h
===
--- quilted.orig/Include/longobject.h	2008-09-01 16:00:58.0 +0100
+++ quilted/Include/longobject.h	2008-09-01 16:01:57.0 +0100
@@ -25,7 +25,7 @@
 PyAPI_FUNC(Py_ssize_t) _PyLong_AsSsize_t(PyObject *);
 PyAPI_FUNC(PyObject *) _PyLong_FromSize_t(size_t);
 PyAPI_FUNC(PyObject *) _PyLong_FromSsize_t(Py_ssize_t);
-PyAPI_DATA(int) _PyLong_DigitValue[256];
+PyAPI_DATA(const int) _PyLong_DigitValue[256];
 
 /* _PyLong_AsScaledDouble returns a double x and an exponent e such that
the true value is approximately equal to x * 2**(SHIFT*e).  e is >= 0.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Fredrik Lundh]

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.




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Benjamin Peterson]

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 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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Jean-Paul Calderone]

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 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Benjamin Peterson]

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 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Further PEP 8 compliance issues in threadi ng and multiprocessing

[Antoine Pitrou]

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?

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Nick Coghlan]

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.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: add odict to collections

[Anthon van der Neut]

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  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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/anthon%40mnt.org
> 
> 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com