Blake Ross wrote:
C++ ensures that virtual bases
are only constructed once,
As far as I remember, C++ ensures this by not calling
the base constructors automatically at all, leaving
you to explicitly call the constructors of all the
virtual bases that you inherit.
You could adopt the same
G == Guido van Rossum [EMAIL PROTECTED] writes:
G There are different philosophies about the correct style for
G cooperative super calls.
G The submitter of the bug report likes to remove consumed arguments
G and pass the others on, having something at the root that complains
G about any unused
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote:
super() has always felt strange to me.
When used in __init__? Or in general? If the former, that's because
it's a unique Python wart to even be able to use super for __init__.
Now, with PEP 3102 and the strict __init__, not so much.
Works for
On 3/22/07, Adam Olsen [EMAIL PROTECTED] wrote:
On 3/21/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote:
super() has always felt strange to me.
When used in __init__? Or in general? If the former, that's because
it's a unique Python wart to
Phillip J. Eby wrote:
The whole point of being co-operative in a metaclass is to allow other
metaclasses to be safely mixed in -- and they may be metaclasses from a
completely different library or framework.
Some of these use cases might now be addressable using
class decorators instead of
On 3/21/07, Blake Ross [EMAIL PROTECTED] wrote:
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
Also make a big distinction between super calls of __init__ (which are
a Pythonic wart and don't exist in other languages practicing multiple
inheritance AFAIK)
Since I filed the bug, I
Greg Ewing schrieb:
Blake Ross wrote:
C++ ensures that virtual bases
are only constructed once,
As far as I remember, C++ ensures this by not calling
the base constructors automatically at all, leaving
you to explicitly call the constructors of all the
virtual bases that you inherit.
Following up to myself, with some examples.
I probably haven't done this as cleanly as is possible, but below are a
bunch of classes and subclasses that cleanly deal with passing around
arguments, even when those args conflict in name, etc., as outlined in my
previous mail.
Here's the general
At 05:02 PM 3/22/2007 +1200, Greg Ewing wrote:
Phillip J. Eby wrote:
The whole point of being co-operative in a metaclass is to allow other
metaclasses to be safely mixed in -- and they may be metaclasses from a
completely different library or framework.
Some of these use cases might now
Can we move this to c.l.py or python-ideas? I don't think it has any
bearing on the decision on whether object.__init__() or
object.__new__() should reject excess arguments. Or if it does I've
lost the connection through the various long articles.
I also would like to ask Mr. Olsen to tone down
On 3/22/07, Thomas Wouters [EMAIL PROTECTED] wrote:
On 3/22/07, Adam Olsen [EMAIL PROTECTED] wrote:
In general. Too many things could fail without errors, so it wasn't
obvious how to use it correctly. None of the articles I've read
helped either.
I've been thinking about writing an
On 3/22/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Can we move this to c.l.py or python-ideas? I don't think it has any
bearing on the decision on whether object.__init__() or
object.__new__() should reject excess arguments. Or if it does I've
lost the connection through the various long
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED] wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument checking for object.__init__ and object.__new__. I
think it
Jean-Paul Calderone wrote:
Perhaps I misunderstand the patch, but it would appear to break not just
some inadvisable uses of super(), but an actual core feature of super().
Maybe someone can set me right. Is this correct?
class Base(object):
def __init__(self, important):
If so,
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED]
wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument
Guido van Rossum wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument checking for object.__init__
Personally I have never written code that relies on
being able to pass arbitrary
On Wed, Mar 21, 2007, Guido van Rossum wrote:
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think I understand the desire to pull keyword arguments out at each
step of the upcalling process, but I don't see how it can work, since
up calling isn't always what's going on - given a
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| There are different philosophies about the correct style for
| cooperative super calls.
|
| The submitter of the bug report likes to remove consumed arguments
| and pass the others on, having something at the root that
On 3/21/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote:
super() has always felt strange to me.
When used in __init__? Or in general? If the former, that's because
it's a unique Python wart to even be able to use super for __init__.
In general.
On 3/21/07, Adam Olsen [EMAIL PROTECTED] wrote:
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED]
wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount
On 3/21/07, Aahz [EMAIL PROTECTED] wrote:
Maybe so, but this would massively break my company's application, if we
were actually using new-style classes and the built-in super(). We have
a web application that commonly passes all form fields down as **kwargs;
the application uses lots of
At 09:41 PM 3/21/2007 -0700, Guido van Rossum wrote:
On 3/21/07, Greg Ewing [EMAIL PROTECTED] wrote:
Every time I've considered using super, I've eventually
decided against it for reasons like this. I've always
found a better way that doesn't introduce so may
strange interactions between
On 3/21/07, Greg Ewing [EMAIL PROTECTED] wrote:
Every time I've considered using super, I've eventually
decided against it for reasons like this. I've always
found a better way that doesn't introduce so may
strange interactions between the classes involved.
I end up feeling the same way, for
On 3/21/07, Terry Reedy [EMAIL PROTECTED] wrote:
It seems to me that to get the exact behavior one wants at the apex of a
diamond structure, one should subclass object and override .__init__ with
a function that does not call object.__init__ and use that subclass as the
apex instead of
On 3/21/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:45:16 -0700, Guido van Rossum [EMAIL PROTECTED]
wrote:
See python.org/sf/1683368. I'd like to invite opinions on whether it's
worth breaking an unknown amount of user code in 2.6 for the sake of
stricter argument
25 matches
Mail list logo
