Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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:

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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 >

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: To super or not to super (Re: Accessing parent objects)

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()

Re: To super or not to super (Re: Accessing parent objects)

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

Re: To super or not to super (Re: Accessing parent objects)

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.

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: To super or not to super (Re: Accessing parent objects)

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

To super or not to super (Re: Accessing parent objects)

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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 >

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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),

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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*

Re: Accessing parent objects

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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 >

Re: Accessing parent objects

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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:

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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,

Multiple Inheritance [was Re: Accessing parent objects]

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

Re: Accessing parent objects

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

Ruby parens-free function calls [was Re: Accessing parent objects]

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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 =

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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()) > > >

Re: Accessing parent objects

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,

Re: Accessing parent objects

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:

Re: Accessing parent objects

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,

Re: Accessing parent objects

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.

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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

Re: Accessing parent objects

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): >