Re: [Python-ideas] Composition over Inheritance

2017-10-30 Thread Thomas Jollans
On 29/10/17 19:25, Soni L. wrote: > > > On 2017-10-29 02:57 PM, Brendan Barnwell wrote: >> On 2017-10-29 04:44, Soni L. wrote: >>> And this is how you miss the whole point of being able to dynamically >>> add/remove arbitrary components on objects you didn't create, at >>> runtime. >>> >>> Someon

Re: [Python-ideas] Composition over Inheritance

2017-10-30 Thread Wes Turner
On Monday, October 30, 2017, Wes Turner wrote: > ... But interfaces are clunky and traits are lightweight, and this isn't > Go, so we can't just create a class as a namespace full of @staticmethods > which accept the relevant object references. > > * __setattribute__ -> __getitem__, __setitem__ >

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Wes Turner
... But interfaces are clunky and traits are lightweight, and this isn't Go, so we can't just create a class as a namespace full of @staticmethods which accept the relevant object references. * __setattribute__ -> __getitem__, __setitem__ On Monday, October 30, 2017, Wes Turner wrote: > > > On

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Wes Turner
On Sunday, October 29, 2017, Nick Coghlan wrote: > On 29 October 2017 at 12:25, Brendan Barnwell > wrote: > >> On 2017-10-28 19:13, Soni L. wrote: >> >>> And to have all cars have engines, you'd do: >>> >>> class Car: >>> def __init__(self, ???): >>> self[Engine] = GasEngine() >>> >>>

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Nick Coghlan
On 29 October 2017 at 21:44, Soni L. wrote: > ORMs use this kind of descriptor based composition management extensively > in order to reliably model database foreign key relationships in a way > that's mostly transparent to users of the ORM classes. > > > And this is how you miss the whole point

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Soni L.
On 2017-10-29 02:57 PM, Brendan Barnwell wrote: On 2017-10-29 04:44, Soni L. wrote: And this is how you miss the whole point of being able to dynamically add/remove arbitrary components on objects you didn't create, at runtime. Someone gave me this code and told me it explains what I'm tryi

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Brendan Barnwell
On 2017-10-29 04:44, Soni L. wrote: And this is how you miss the whole point of being able to dynamically add/remove arbitrary components on objects you didn't create, at runtime. Someone gave me this code and told me it explains what I'm trying to do: https://repl.it/NYCF/3 class T: pass

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Koos Zevenhoven
(looks like you forgot to reply to the list) On Sun, Oct 29, 2017 at 7:47 AM, Greg Ewing wrote: > Koos Zevenhoven wrote: > >> It looks like you can just as easily drive the car without having the key >> > > That's been found to be a problem in real life, too. > More than one Python-programming c

Re: [Python-ideas] Composition over Inheritance

2017-10-29 Thread Soni L.
On 2017-10-29 02:28 AM, Nick Coghlan wrote: On 29 October 2017 at 12:25, Brendan Barnwell > wrote: On 2017-10-28 19:13, Soni L. wrote: And to have all cars have engines, you'd do: class Car:     def __init__(self, ???):      

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Greg Ewing
My take on all this is that it's much simpler just to give the engine an attribute that refers back to the car. The only downside is that it creates a circular reference, but in these days of cyclic gc, that's not much of an issue. -- Greg ___ Python-i

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Nick Coghlan
On 29 October 2017 at 12:25, Brendan Barnwell wrote: > On 2017-10-28 19:13, Soni L. wrote: > >> And to have all cars have engines, you'd do: >> >> class Car: >> def __init__(self, ???): >> self[Engine] = GasEngine() >> >> car = Car() >> car[Engine].kickstart() # kickstart gets the car a

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Brendan Barnwell
On 2017-10-28 19:13, Soni L. wrote: Hmm thinking about it some more, this whole "magic()" thing is still bad. Replace class Car with: class Car: pass # or something like that and use it as: car = Car() car[Engine] = GasEngine() # please use the actual type instead of a stringy type for th

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Chris Angelico
On Sun, Oct 29, 2017 at 1:05 PM, Soni L. wrote: > And how do you make the object creation so cheap to the point where it's > actually practical? (quick question: does Python use a single opcode and an > optimized codepath for method calls, or does it always create a method > wrapper, even for imme

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Soni L.
On 2017-10-29 12:05 AM, Soni L. wrote: On 2017-10-28 11:57 PM, Chris Angelico wrote: On Sun, Oct 29, 2017 at 12:46 PM, Soni L. wrote: But you should be able to do things like car = object() car[Engine] = SimpleEngine() car.[Engine].kickstart() # calls kickstart method with an instance of

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Soni L.
On 2017-10-28 11:57 PM, Chris Angelico wrote: On Sun, Oct 29, 2017 at 12:46 PM, Soni L. wrote: But you should be able to do things like car = object() car[Engine] = SimpleEngine() car.[Engine].kickstart() # calls kickstart method with an instance of SimpleEngine as `self`/first argument and

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Chris Angelico
On Sun, Oct 29, 2017 at 12:46 PM, Soni L. wrote: > But you should be able to do things like > > car = object() > car[Engine] = SimpleEngine() > car.[Engine].kickstart() # calls kickstart method with an instance of > SimpleEngine as `self`/first argument and `car` as second argument. > # etc > > Wh

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Soni L.
On 2017-10-28 11:31 PM, Koos Zevenhoven wrote: On Sat, Oct 28, 2017 at 11:24 PM, Soni L. >wrote: On 2017-10-28 02:51 PM, Steven D'Aprano wrote: You ignored my question: Is that the sort of thing you mean by composition? If not, then what do y

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Koos Zevenhoven
On Sat, Oct 28, 2017 at 11:24 PM, Soni L. wrote: > > On 2017-10-28 02:51 PM, Steven D'Aprano wrote: > >> >> You ignored my question: Is that the sort of thing you mean by >> composition? If not, then what do you mean by it? This is not a >> rhetorical question: I'm having difficulty understanding

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Soni L.
On 2017-10-28 02:51 PM, Steven D'Aprano wrote: On Sat, Oct 28, 2017 at 10:19:09AM -0200, Soni L. wrote: class Car: def __init__(self): self.engine = Engine() self.accelerator = AcceleratorPedal() ... def start(self): # Delegate to the ignition co

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Steven D'Aprano
On Sat, Oct 28, 2017 at 10:19:09AM -0200, Soni L. wrote: > >class Car: > > def __init__(self): > > self.engine = Engine() > > self.accelerator = AcceleratorPedal() > > ... > > > > def start(self): > > # Delegate to the ignition component. > > self.ig

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Thomas Jollans
On 28/10/17 14:19, Soni L. wrote: > > > On 2017-10-28 09:51 AM, Steven D'Aprano wrote: >> On Sat, Oct 28, 2017 at 09:09:30AM -0200, Soni L. wrote: >>> As recent threads indicate, composition may sometimes be better than >>> inheritance. And so I'd like to propose composition as a built-in >>> fea

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Soni L.
On 2017-10-28 09:51 AM, Steven D'Aprano wrote: On Sat, Oct 28, 2017 at 09:09:30AM -0200, Soni L. wrote: As recent threads indicate, composition may sometimes be better than inheritance. And so I'd like to propose composition as a built-in feature. My idea is syntax of the form o.[c].m(), wher

Re: [Python-ideas] Composition over Inheritance

2017-10-28 Thread Steven D'Aprano
On Sat, Oct 28, 2017 at 09:09:30AM -0200, Soni L. wrote: > As recent threads indicate, composition may sometimes be better than > inheritance. And so I'd like to propose composition as a built-in feature. > > My idea is syntax of the form o.[c].m(), where o is an object, c is a > component, m is

[Python-ideas] Composition over Inheritance

2017-10-28 Thread Soni L.
As recent threads indicate, composition may sometimes be better than inheritance. And so I'd like to propose composition as a built-in feature. My idea is syntax of the form o.[c].m(), where o is an object, c is a component, m is a method. I am not sure how you'd set components, or test for c