On Wednesday, March 28, 2018 at 2:25:42 AM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > The only difference is when you want to make a call from a
> > _reference_, which, as you and i well know, is not the
> > most common way func/meths are called (these are rare).
>
> No, but it's the ca
On Thu, Mar 29, 2018 at 12:28 AM, Steven D'Aprano
wrote:
> On Tue, 27 Mar 2018 11:34:17 +1100, Chris Angelico wrote:
>
>> Question: How do you get a reference to a Ruby function? Or are they not
>> first-class objects?
>
> https://stackoverflow.com/questions/4294485/how-do-i-reference-a-function-
On Tue, 27 Mar 2018 11:34:17 +1100, Chris Angelico wrote:
> Question: How do you get a reference to a Ruby function? Or are they not
> first-class objects?
https://stackoverflow.com/questions/4294485/how-do-i-reference-a-function-
in-ruby
Especially this answer, which is worth reading:
https://
Rick Johnson wrote:
The only difference is when you want to make a call from a
_reference_, which, as you and i well know, is not the most
common way func/meths are called (these are rare).
No, but it's the case we're talking about here. If
functions don't behave the same way in all circumstanc
On Wed, Mar 28, 2018 at 1:22 PM, Rick Johnson
wrote:
> On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
>> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
> [...]
>> > Since when did utilizing a method to request a specific
>> > value become some sort of magic?
>>
>>
On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
[...]
> > Since when did utilizing a method to request a specific
> > value become some sort of magic?
>
> Since it requires a special method that has super powers no
> m
On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
> On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> > Cool, so Greg was right: you can't get a reference to a method or
> > function. You need magic to simulate it.
>
> Since when did utilizing a method to request a
On Tuesday, March 27, 2018 at 4:47:05 PM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > rb> Object.method("print_name").call("Meathead")
>
> Yes, but the point is that you have to have to use a different
> syntax to call it. This is like having to say
>
> f.__call__(arg)
>
> in Pytho
Rick Johnson wrote:
rb> Object.method("print_name").call("Meathead")
Yes, but the point is that you have to have to use a different
syntax to call it. This is like having to say
f.__call__(arg)
in Python instead of just
f(arg)
--
Greg
--
https://mail.python.org/mailman/listinfo/py
Chris Angelico wrote:
Ahh, that explains it. Great. So how do you build higher-order
functions? Or don't you?
You don't, exactly. You have to pass around objects
with a method to invoke when you want to "call" them.
Ruby has a code-block syntax that helps with this
somewhat, but I don't think
On Tuesday, March 27, 2018 at 11:35:31 AM UTC-5, Chris Angelico wrote:
> Why are you suggesting that this is magic?
_You_ are the one who leveled the accusation that Ruby's
methodology for fetching a function reference (a la):
Object.method(meth-name-here)
is "magic". I'm merely requesting t
On Wed, Mar 28, 2018 at 3:28 AM, Rick Johnson
wrote:
> On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
> [...]
>> Cool, so Greg was right: you can't get a reference to a
>> method or function. You need magic to simulate it.
>
> Since when did utilizing a method to request a s
On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> Cool, so Greg was right: you can't get a reference to a
> method or function. You need magic to simulate it.
Since when did utilizing a method to request a specific
value become some sort of magic?
Do you consider this
On Tue, 27 Mar 2018 19:21:38 +1300, Gregory Ewing wrote:
> The idea that super() is *always* the right way to call inherited
> methods in a multiple inheritance environment seems to have been raised
> by some people to the level of religous dogma.
"Always"?
Well, you could always avoid super() b
On Tue, Mar 27, 2018 at 8:47 AM, Ian Kelly wrote:
> On Tue, Mar 27, 2018 at 12:21 AM, Gregory Ewing
> wrote:
>> The trouble is, those conditions don't always hold.
>> Often when overriding a method, you want to do something
>> *instead* of what the base method does.
>
> As noted above, unless the
On Tue, Mar 27, 2018 at 12:21 AM, Gregory Ewing
wrote:
> The idea that super() is *always* the right way to call
> inherited methods in a multiple inheritance environment
> seems to have been raised by some people to the level
> of religous dogma.
>
> I don't buy it. In order for it to work, the f
On Tue, Mar 27, 2018 at 11:00 PM, Rick Johnson
wrote:
> On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
>> Chris Angelico wrote:
>> > Question: How do you get a reference to a Ruby function? Or are they
>> > not first-class objects?
>>
>> They're not first-class. So, you can't
On Tuesday, March 27, 2018 at 3:24:48 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:
> Printing a string and calling a function is obfuscated code? Deary me.
When the programmer can't be bothered to invent names more
descriptive than `a` and `b`, why ye
On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
> Chris Angelico wrote:
> > Question: How do you get a reference to a Ruby function? Or are they
> > not first-class objects?
>
> They're not first-class. So, you can't.
If Chris means: "how do you get a reference to a Ruby
funct
On 27-03-18 08:21, Gregory Ewing wrote:
> The idea that super() is *always* the right way to call
> inherited methods in a multiple inheritance environment
> seems to have been raised by some people to the level
> of religous dogma.
>
> I don't buy it. In order for it to work, the following
> two c
On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:
> On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
>> Rick, you're supposedly familiar with Ruby. And yet, you didn't notice
>> that your supposed "fix" didn't touch any executable code, all it did
>> was modify the strin
On Mon, Mar 26, 2018, at 2:19 PM, Rick Johnson wrote:
>Sure, the behavior that Steven
> uncovered is odd, but it could be that Maz harbors a strong
> disliking for undisciplined pupils, and thus, he designed
> and placed this little trap in the hopes the pain it induced
> might encourage the petula
On Tue, Mar 27, 2018 at 5:54 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> Question: How do you get a reference to a Ruby function? Or are they
>> not first-class objects?
>
>
> They're not first-class. So, you can't.
>
Ahh, that explains it. Great. So how do you build higher-order
funct
Chris Angelico wrote:
Question: How do you get a reference to a Ruby function? Or are they
not first-class objects?
They're not first-class. So, you can't.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Ned Batchelder wrote:
"Ranting Rick" isn't trying
to enlighten, educate, or learn. He's trying to rile people up, and he
is good at it.
I don't think he's even trying, it just come naturally
to him. Rick rants the way wind blows and water wets.
--
Greg
--
https://mail.python.org/mailman/listi
The idea that super() is *always* the right way to call
inherited methods in a multiple inheritance environment
seems to have been raised by some people to the level
of religous dogma.
I don't buy it. In order for it to work, the following
two conditions must hold:
1) All the methods involved ha
On Monday, March 26, 2018 at 6:11:31 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
[...]
> > Hmm. If "syntax parser rules" could prevent poorly
> > formatted code, then there'd be no need for style guides.
>
> It may be telling that my team has minimal styl
On Tue, Mar 27, 2018 at 10:10 AM, Python wrote:
> Ruby touts itself as being a simple language with elegant syntax.
> This thread is my only exposure to it to date, but what I've seen here
> is, frankly, the exact opposite of that. You should not need a map to
> distinguish function calls from va
On 3/26/18 7:10 PM, Python wrote:
Humans are already good enough at making mistakes that they
require no additional encouragement, such as what is
provided by allowing such syntactical horrors.
Agreed. And that's why we must respect and follow the code
styling wisdom which has been passed down b
On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
> On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> > On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
> [...]
> > > Ruby followed the rules.
> > > But you didn't.
> >
> > Nonsense... Your language's syntax pars
On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
[...]
> > Ruby followed the rules.
> > But you didn't.
>
> Nonsense... Your language's syntax parser is what defines
> the rules. All of the expressions Stephen wrote did not
On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
> > Because of this "fix", the printed strings no longer match
> > the code being executed, but the strange, inconsistent
> > behaviour still occurs.
>
> The supposed "inconsistent behavior" here has absolutely
> nothing to do with Ruby
On Tue, Mar 27, 2018 at 5:37 AM, Rick Johnson
wrote:
> The supposed "inconsistent behavior" here has absolutely
> nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> the one who created a non-sensical function with a single
> char name; and _YOU_ are the one who placed a call to that
> fun
On Mon, Mar 26, 2018 at 10:43:32AM +, Steven D'Aprano wrote:
> The kicker is that out of these four legal, parenthesis-free ways of
> calling function a, *three* of them interpret the expression as:
>
> call a with no arguments
> then add b using the binary plus operator
>
> but the
On Sun, Mar 25, 2018 at 10:33:49AM -0700, Rick Johnson wrote:
> > [steve@ando ruby]$ ruby ws-example.rb
> > a + b => 7
> > a+b => 7
> > a+ b => 7
> > a +b => 3
> >
> > Here's the source code:
> >
> > # --- cut ---
> > def a(x=4)
> > x+2
> > end
> >
> > b = 1
> > print "a + b => ", (a + b),
On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
> Rick, you're supposedly familiar with Ruby. And yet, you
> didn't notice that your supposed "fix" didn't touch any
> executable code, all it did was modify the strings being
> printed.
Because the goal was to *UN-OBFUSCATE* th
On 26-03-18 10:52, Ben Finney wrote:
> Antoon Pardon writes:
>
>> But did they start up cleaning the standard library yet? I'll confess
>> I'm only using 3.5 but when I go through the standard library I see a
>> lot of classes still using the old style of calling the parant method,
>> which makes
On Sun, 25 Mar 2018 19:16:12 -0700, Rick Johnson wrote:
> On Sunday, March 25, 2018 at 5:57:28 PM UTC-5, Steven D'Aprano wrote:
>
>> [supposed "fix" to the sample script snipped]
>>
>> You know Rick, every time I start to think that talking to you like an
>> adult might result in a productive and
On Mon, 26 Mar 2018 10:43:25 +0200, Antoon Pardon wrote:
> But did they start up cleaning the standard library yet? I'll confess
> I'm only using 3.5 but when I go through the standard library I see a
> lot of classes still using the old style of calling the parant method,
> which makes it more di
On Mon, 26 Mar 2018 10:02:23 +0200, Antoon Pardon wrote:
>> The trick is to use new-style classes that inherit from object, and
>> avoid the old-style classes that don't:
>>
>> # Good
>> class Spam(object):
>> ...
>>
>> # Not so good
>> class Spam:
>> ...
>
> How good is that when almost
Antoon Pardon writes:
> But did they start up cleaning the standard library yet? I'll confess
> I'm only using 3.5 but when I go through the standard library I see a
> lot of classes still using the old style of calling the parant method,
> which makes it more difficult to use in a multiple inher
On 25-03-18 06:29, Steven D'Aprano wrote:
> Python 3 is now six point releases in (and very soon to have a seventh,
> 3.7 being in beta as we speak). It is stable, feature-rich, and a joy to
> work in. As well as a heap of great new features, there have been a
> metric tonne of performance improv
Antoon Pardon writes:
> On 25-03-18 00:54, Steven D'Aprano wrote:
> > The trick is to use new-style classes that inherit from object, and
> > avoid the old-style classes that don't:
> >
> > # Good
> > class Spam(object):
> > ...
> >
> > # Not so good
> > class Spam:
> > ...
>
> How good i
On 25-03-18 00:54, Steven D'Aprano wrote:
>
> There's nothing wrong with super() in Python 2. You just have to
> understand what you're doing. It's still the right solution for doing
> inheritance the right way.
>
> ...
>
> The trick is to use new-style classes that inherit from object, and avo
On Sunday, March 25, 2018 at 5:57:28 PM UTC-5, Steven D'Aprano wrote:
> [supposed "fix" to the sample script snipped]
>
> You know Rick, every time I start to think that talking to
> you like an adult might result in a productive and
> intelligent conversation, you pull a stunt like this. Once
>
On Sun, 25 Mar 2018 21:50:27 +0200, Peter J. Holzer wrote:
> On 2018-03-25 14:49:44 +, Steven D'Aprano wrote:
>> The moniker "Python X-thousand" (Python 3000, 4000, 5000...) is usually
>> understood to mean a backwards-compatibility breaking version. Since
>> Python 4 will *not* be such a vers
On Sun, 25 Mar 2018 10:33:49 -0700, Rick Johnson wrote:
> On Sunday, March 25, 2018 at 9:11:35 AM UTC-5, Steven D'Aprano wrote:
>> On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
> [...]
>> I never said anything about not allowing it. But since you've gone on
>> the defence about parens-fr
On Sun, 25 Mar 2018 13:30:14 -0700, Rick Johnson wrote:
[...]
>> Especially since by your own admission, you are *giving up correctness*
>> in order to buy "consistency":
>
> "sacrificing correctness" only in a purely ideological sense.
>
> Explicit inheritance (aka: hard-coding the superclass s
On Mon, Mar 26, 2018 at 7:30 AM, Rick Johnson
wrote:
>> Especially since by your own admission, you are *giving up
>> correctness* in order to buy "consistency":
>
> "sacrificing correctness" only in a purely ideological
> sense.
>
> Explicit inheritance (aka: hard-coding the superclass
> symbol)
On Sunday, March 25, 2018 at 9:52:30 AM UTC-5, Steven D'Aprano wrote:
> On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
[...]
> But refusing to use super in modern, new-style classes that
> don't have anything to do with tkinter is precisely the
> sort of *foolish* consistency that Emerson
On 2018-03-25 14:49:44 +, Steven D'Aprano wrote:
> The moniker "Python X-thousand" (Python 3000, 4000, 5000...) is usually
> understood to mean a backwards-compatibility breaking version. Since
> Python 4 will *not* be such a version, what you are calling 4000 is
> better called "5000".
If
On Sunday, March 25, 2018 at 10:02:20 AM UTC-5, Jugurtha Hadjar wrote:
[...]
> Furthermore, the only case I'd use a positional argument is
> if I were 100% certain the code will not change, which I'm
> not.
And short of you possessing a crystal ball in good working
order (mine's currently in the s
On Sunday, March 25, 2018 at 9:11:35 AM UTC-5, Steven D'Aprano wrote:
> On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
[...]
> I never said anything about not allowing it. But since
> you've gone on the defence about parens-free function
> calls, how is this for "consistency" in Ruby?
>
>
On 03/25/2018 12:07 PM, D'Arcy Cain wrote:
On 03/25/2018 05:10 AM, Jugurtha Hadjar wrote:
print("I am {self.__class__.__name__} foo".format(self=self))
Unrelated to the original issue but why not one of the following?
print("I am {0.__class__.__name__} foo".format(self))
I prefer k
On 03/25/2018 04:31 PM, Ian Kelly wrote:
On Sun, Mar 25, 2018 at 9:01 AM, Jugurtha Hadjar
wrote:
On 03/25/2018 03:25 PM, Terry Reedy wrote:
None.foo will raise AttributeError.
Right.. As I said, I tried to assume as little as possible about OP's code
and namespace. Didn't want to include C
On 3/25/2018 11:01 AM, Jugurtha Hadjar wrote:
On 03/25/2018 03:25 PM, Terry Reedy wrote:
On 3/25/2018 7:42 AM, Jugurtha Hadjar wrote:
class C2(object):
def __init__(self, parent=None):
self.parent = parent
Since parent is required, it should not be optional.
You can still c
On Sun, Mar 25, 2018 at 9:01 AM, Jugurtha Hadjar
wrote:
>
> On 03/25/2018 03:25 PM, Terry Reedy wrote:
>> None.foo will raise AttributeError.
>>
>
> Right.. As I said, I tried to assume as little as possible about OP's code
> and namespace. Didn't want to include C1 in __init__ signature because I
On Sun, Mar 25, 2018 at 9:01 AM, Jugurtha Hadjar
wrote:
>
> On 03/25/2018 03:25 PM, Terry Reedy wrote:
>>
>> On 3/25/2018 7:42 AM, Jugurtha Hadjar wrote:
>>
>>> class C2(object):
>>> def __init__(self, parent=None):
>>> self.parent = parent
>>
>>
>> Since parent is required, it shoul
On 03/25/2018 11:57 AM, D'Arcy Cain wrote:
Something like this:
class C1(object):
...
class C2(object):
def __init__(self, parent=None):
self.parent = parent
Perhaps your email client is collapsing leading spaces but that isn't
what I wrote. The C2 class is supposed to be a m
On 03/25/2018 03:25 PM, Terry Reedy wrote:
On 3/25/2018 7:42 AM, Jugurtha Hadjar wrote:
class C2(object):
def __init__(self, parent=None):
self.parent = parent
Since parent is required, it should not be optional.
You can still call it the way you'd call it if it were a posit
On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
> On Saturday, March 24, 2018 at 11:31:38 PM UTC-5, Steven D'Aprano wrote:
[...]
>> "A foolish consistency is the hobgoblin of little minds, adored by
>> little statesmen and philosophers and divines."
>> >
>> > Thus, i chose to abandon super
On Sun, 25 Mar 2018 08:09:02 -0600, Ian Kelly wrote:
> On Sun, Mar 25, 2018 at 5:46 AM, Steven D'Aprano
> wrote:
>> On Sun, 25 Mar 2018 06:11:53 -0500, D'Arcy Cain wrote:
>>> It accesses the parent class. I want to access the parent object.
>>
>> Ah. Well, no wonder it doesn't work: you're confu
On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
[...]
> Ruby is fundamentally _opposed_ to the idea of multiple inheritance --
> as MI is rife with issues (technical, practical, and intuitive in
> nature) and thus, not a wise solution -- but you would have known that
> Steven
I know that
On 3/25/2018 7:42 AM, Jugurtha Hadjar wrote:
class C2(object):
def __init__(self, parent=None):
self.parent = parent
Since parent is required, it should not be optional.
def foo(self):
print("I am {self.__class__.__name__} foo".format(self=self))
self.par
On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
>> - with no arguments, using the parenthesis-free syntax,
>> Ruby automagically forwards the same arguments to the (single)
>> parent;
>
> Which is merely a natural result of Ruby's function/method call syntax.
> Not allowing a parenthe
On Sun, Mar 25, 2018 at 5:46 AM, Steven D'Aprano
wrote:
> On Sun, 25 Mar 2018 06:11:53 -0500, D'Arcy Cain wrote:
>> It accesses the parent class. I want to access the parent object.
>
> Ah. Well, no wonder it doesn't work: you're confusing the OO inheritance
> concept of "parent" (a superclass) w
On Sun, 25 Mar 2018 05:57:40 -0500, D'Arcy Cain wrote:
> That was my original solution but it seems clumsy.
>
> O2 = O1.C2(O1)
Are you intentionally trying to melt my brain with horribly obfuscated,
meaningless names? If so, you've succeeded admirably millennium hand and
shrimp buggarit.
:-)
On Sun, 25 Mar 2018 06:11:53 -0500, D'Arcy Cain wrote:
> On 03/24/2018 06:54 PM, Steven D'Aprano wrote:
>>> On Saturday, March 24, 2018 at 1:20:24 PM UTC-5, D'Arcy Cain wrote:
I tried various forms of super() but that didn't seem to work.
>>
>> Define "doesn't see to work".
>
> It accesses
On Saturday, March 24, 2018 at 11:31:38 PM UTC-5, Steven D'Aprano wrote:
> On Sat, 24 Mar 2018 20:08:47 -0700, Rick Johnson wrote:
[...]
> >
> > the inconsistency of using super _outside_ of Tkinter code
> > whilst simultaneously using explicit inheritance _inside_
> > Tkinter code was quite frankl
Erratum: "I can select C2, or C3 and I'll have the instance created with
my choice"
--
~ Jugurtha Hadjar,
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, 25 Mar 2018 21:17:59 +1100, Chris Angelico wrote:
> On Sun, Mar 25, 2018 at 8:37 PM, Jugurtha Hadjar
> wrote:
[...]
>> I prefer to *feed* the child to the parent or vice versa.
>
> Congrats, this ranks on my list of "creative people who sound like
> psycho murderers". Digital artists and
On 03/25/2018 11:17 AM, Chris Angelico wrote:
On Sun, Mar 25, 2018 at 8:37 PM, Jugurtha Hadjar
wrote:
On 03/24/2018 07:14 PM, D'Arcy Cain wrote:
class C1(dict):
class C2(object):
def f(self):
return X['field']
O1 = C1()
O1['field'] = 1
O2 = O1.C2()
print(O2.f())
I prefer
On 03/24/2018 06:54 PM, Steven D'Aprano wrote:
>> On Saturday, March 24, 2018 at 1:20:24 PM UTC-5, D'Arcy Cain wrote:
>>> I tried various forms of super() but that didn't seem to work.
>
> Define "doesn't see to work".
It accesses the parent class. I want to access the parent object.
--
D'Arcy
On 03/25/2018 05:10 AM, Jugurtha Hadjar wrote:
> print("I am {self.__class__.__name__} foo".format(self=self))
Unrelated to the original issue but why not one of the following?
print("I am {0.__class__.__name__} foo".format(self))
print(f"I am {self.__class__.__name__} foo")
--
D'Arcy J
On 03/25/2018 04:37 AM, Jugurtha Hadjar wrote:
> On 03/24/2018 07:14 PM, D'Arcy Cain wrote:
>> class C1(dict):
>> class C2(object):
>> def f(self):
>> return X['field']
>>
>> O1 = C1()
>> O1['field'] = 1
>> O2 = O1.C2()
>> print(O2.f())
>
> I prefer to *feed* the child to the parent
On Sun, Mar 25, 2018 at 8:37 PM, Jugurtha Hadjar
wrote:
> On 03/24/2018 07:14 PM, D'Arcy Cain wrote:
>>
>> class C1(dict):
>>class C2(object):
>> def f(self):
>>return X['field']
>>
>> O1 = C1()
>> O1['field'] = 1
>> O2 = O1.C2()
>> print(O2.f())
>
>
> I prefer to *feed* the child
There was a typo in my original reply:
<>
class C1(object):
def __init__(self):
self.child = None
def foo(self):
print("I am {self.__class__.__name__} foo".format(self=self))
def adopt(self, child=N
On 03/24/2018 07:14 PM, D'Arcy Cain wrote:
class C1(dict):
class C2(object):
def f(self):
return X['field']
O1 = C1()
O1['field'] = 1
O2 = O1.C2()
print(O2.f())
I prefer to *feed* the child to the parent or vice versa. Simplifies
things like testing.
Something like this:
<--
On Sat, 24 Mar 2018 20:08:47 -0700, Rick Johnson wrote:
> After sending my response to Steven, i began to ponder why i had
> rejected Python's super (because, after all, it's been a few years now,
> and frankly, i forgot), and i realized it was more a matter of
> consistency.
>
> You see, Tkinter
On Saturday, March 24, 2018 at 9:29:02 PM UTC-5, Chris Angelico wrote:
> So tell me, how do these other (beautifully intuitive)
> languages handle multiple inheritance? I'm sure it's really
> easy to make super() work when there's exactly one
> superclass that you can lock in at compile time.
Afte
On Sun, Mar 25, 2018 at 1:20 PM, Rick Johnson
wrote:
> On Saturday, March 24, 2018 at 6:57:29 PM UTC-5, Steven D'Aprano wrote:
>> There's nothing wrong with super() in Python 2. You just
>> have to understand what you're doing. It's still the right
>> solution for doing inheritance the right way.
On Saturday, March 24, 2018 at 6:57:29 PM UTC-5, Steven D'Aprano wrote:
> There's nothing wrong with super() in Python 2. You just
> have to understand what you're doing. It's still the right
> solution for doing inheritance the right way.
The problem is, Python's super is not intuitive.
And i'd
On Sat, 24 Mar 2018 13:31:13 -0700, Rick Johnson wrote:
> On Saturday, March 24, 2018 at 1:20:24 PM UTC-5, D'Arcy Cain wrote:
[...]
>> I tried various forms of super() but that didn't seem to work.
Define "doesn't see to work".
> Python's super (at least <= 2.x) is notoriously blinkered. I avoi
On Saturday, March 24, 2018 at 1:20:24 PM UTC-5, D'Arcy Cain wrote:
> I'm not even sure how to describe what I am trying to do
> which perhaps indicates that what I am trying to do is the
> wrong solution to my problem in the first place but let me
> give it a shot. Look at the following code.
>
On Sun, Mar 25, 2018 at 5:14 AM, D'Arcy Cain wrote:
> I'm not even sure how to describe what I am trying to do which perhaps
> indicates that what I am trying to do is the wrong solution to my
> problem in the first place but let me give it a shot. Look at the
> following code.
>
> class C1(dict)
D'Arcy Cain wrote:
> I'm not even sure how to describe what I am trying to do which perhaps
> indicates that what I am trying to do is the wrong solution to my
> problem in the first place but let me give it a shot. Look at the
> following code.
>
> class C1(dict):
> class C2(object):
> de
I'm not even sure how to describe what I am trying to do which perhaps
indicates that what I am trying to do is the wrong solution to my
problem in the first place but let me give it a shot. Look at the
following code.
class C1(dict):
class C2(object):
def f(self):
return X['field']
87 matches
Mail list logo
