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 lo
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 wri
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 hi
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 mi
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 cla
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 inhe
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 t
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 o
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
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
> "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> a
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 sol
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
> >strict
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, 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,
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
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
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
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 g
"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
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
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 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
> >strict
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):
>
>
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
25 matches
Mail list logo
