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

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

Re: [Python-ideas] Composition over Inheritance

2017-10-30 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

Re: [Python-ideas] Composition over Inheritance

2017-10-30 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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

[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