Bruno Desthuilliers wrote:
> Jonathan Gardner a écrit :
>> On Dec 18, 7:08 am, "[EMAIL PROTECTED]"
> (snip)
>> Monkey patching is definitely unpythonic. You must be a Ruby guy.
>
> Strange enough, I learned monkey-patching with Python, years before I
> first heard of a language named Ruby.
Inde
Jonathan Gardner a écrit :
> On Dec 18, 7:08 am, "[EMAIL PROTECTED]"
(snip)
> Monkey patching is definitely unpythonic. You must be a Ruby guy.
Strange enough, I learned monkey-patching with Python, years before I
first heard of a language named Ruby.
> Why
> don't you try doing something else
On Dec 19, 12:01 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> They should have converted the
> old-style to new when they decided to derive from both types (it's not
> like that's terribly difficult).
Unless perhaps the old-style class is part of an stdlib or 3rd party
(or rather 4th party since
On Dec 19, 10:55 am, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Dec 18, 3:16 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > On Dec 18, 10:08 am, "[EMAIL PROTECTED]"
>
> > <[EMAIL PROTECTED]> wrote:
> > > We are trying to monkey-patch a third-party library that mixes new and
> > > old-style clas
On Dec 18, 3:16 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Dec 18, 10:08 am, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > We are trying to monkey-patch a third-party library that mixes new and
> > old-style classes with multiple inheritance.
>
> New library? Geez, if people are dumb
On Dec 18, 9:25 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> A well-considered, timely monkey-patch can sometimes save all kinds of
> workarounds and other headaches.
>
> Carl Banks
+1
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Thank Gabriel,
|
| That sounds exactly right and your work-around provides confirmation.
| This code is an expedient solution for us so I expect we'll go with
| forcing a slot update. Hopefully the library concerned is going to
| fix
ot;
> > else:
> > print "false"
> >
>
> > Produces this output:
>
> > doing the test on Baz(Foo,Bar). Should return false
> > true
>
> > With some experimentation it is clear that this behaviour only occurs
> > when you com
On Dec 18, 8:25 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2:09 pm, Jonathan Gardner
>
>
>
> <[EMAIL PROTECTED]> wrote:
> > On Dec 18, 7:08 am, "[EMAIL PROTECTED]"
>
> > <[EMAIL PROTECTED]> wrote:
> > > We are trying to monkey-patch a third-party library that mixes new and
> > > old-sty
On Dec 18, 2:09 pm, Jonathan Gardner
<[EMAIL PROTECTED]> wrote:
> On Dec 18, 7:08 am, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > We are trying to monkey-patch a third-party library that mixes new and
> > old-style classes with multiple inheritance. In so doing we have
> > uncovered som
On Dec 18, 10:08 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> We are trying to monkey-patch a third-party library that mixes new and
> old-style classes with multiple inheritance.
New library? Geez, if people are dumb enough to do this, are you sure
you want your application to depend on
az()
>
> print "doing the test on Baz(Foo,Bar). Should return false"
> if b:
> print "true"
> else:
> print "false"
>
>
> Produces this output:
>
> doing the test on Baz(Foo,Bar). Should return false
> true
>
> W
On Dec 18, 7:08 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> We are trying to monkey-patch a third-party library that mixes new and
> old-style classes with multiple inheritance. In so doing we have
> uncovered some unexpected behaviour:
>
>
> I know this level of messing with python inte
st on Baz(Foo,Bar). Should return false
true
With some experimentation it is clear that this behaviour only occurs
when you combine new+old-style multiple inheritance, monkey-patching
and special methods. If Foo and Bar are either old or new-style it
works. calling b.__nonzero__() directly works
14 matches
Mail list logo
